doc/man-pages/README

   1                             OpenAFS Man Pages
   2
   3 Overview
   4
   5   This directory contains the POD source and (in releases) the generated
   6   man pages for OpenAFS commands and files.  The man pages are based on
   7   the original IBM AFS Administration Reference manual, released with the
   8   rest of AFS under the IBM Public License 1.0.  They were converted from
   9   HTML to POD, editing, and are currently maintained in POD.
  10
  11   The man pages are very much a work in progress.  The original source
  12   material dated from IBM's public release of AFS, and many changes since
  13   made in OpenAFS are not reflected in the man pages.  Help and
  14   contributions are actively solicited.  Please see "How You Can Help"
  15   below for more information.
  16
  17   The long-term goal is for every command shipped with OpenAFS and every
  18   configuration or data file written or read by OpenAFS to have its own
  19   man page.  Section one is used for commands that don't require special
  20   privileges, section eight for commands for AFS administrators and local
  21   system administrators, and section five for file formats and
  22   configuration files, with the exception that command suites are kept
  23   together (so, for instance, all fs commands are documented in section
  24   one even though some of them are only usable by a local system
  25   administrator).
  26
  27   The OpenAFS man pages are discussed on the openafs-doc mailing list at
  28   openafs.org.  If you plan on contributing to the man page project,
  29   please join that mailing list and send suggestions, patches, and
  30   contributions there.  The coordinator of the OpenAFS man page project is
  31   Russ Allbery <rra@stanford.edu>; feel free to contact me directly with
  32   questions (although using the mailing list is generally better and will
  33   probably result in a faster response).
  34
  35 POD and Man Page Generation
  36
  37   The OpenAFS man pages are maintained in POD (Plain Old Documentation),
  38   the documentation system originally developed for Perl.  This is not an
  39   uncontroversial choice, since POD isn't as rich and full-featured as
  40   other possible alternatives such as Docbook RefEntry.  On the other
  41   hand, POD is very close to plain text, can be easier to edit and
  42   maintain for those not familiar with the documentation format, and has
  43   more mature tools for conversion to formatted man pages, an output
  44   format that is particularly important on Unix/Linux.  There are many
  45   good arguments either way, and fundamentally the decision was made to
  46   use POD because I prefer it and I'm volunteering to write and edit the
  47   pages and maintain them going forward.
  48
  49   To convert the POD source to formatted man pages, you need the pod2man
  50   utility.  This utility has come with Perl for many years, so if you have
  51   Perl installed, you almost certainly have some version of it available.
  52   For the best results, install Pod::Simple 3.03 or later and podlators
  53   2.00 or later from CPAN and use that pod2man, but the results from the
  54   pod2man that comes with Perl 5.8 or later will be very good.  If you are
  55   using earlier versions of Perl, the output should be adequate and
  56   readable but may contain some formatting glitches.
  57
  58   Preformatted man pages will be included in distribution tarballs, but
  59   those man pages may be generated with older versions of the conversion
  60   utilities.  To regenerate the man pages, run regen.sh at the top of the
  61   OpenAFS source tree (this will also regenerate the Autoconf scripts).
  62
  63   Conversion to HTML can be done via any of the POD to HTML converters
  64   available (there are many of them), but for best results (particularly
  65   for crosslinks), use the generate-html script in this directory.  You
  66   will need to have the Pod::Simple Perl module installed.  If your Perl
  67   is not in /usr/bin, run generate-html explicitly with:
  68
  69       perl generate-html
  70
  71   It will generate HTML pages in the html subdirectory of this directory.
  72
  73 Formatting Standards
  74
  75   Each command or configuration file should have a separate man page in a
  76   separate POD file.  Command suites (fs, pts, vos, etc.) should have an
  77   overview man page that lists the available subcommands by category,
  78   documents common options, and discusses the general use of the suite.
  79   Then, each operation code in the suite should have a separate man page,
  80   named after the command with the space between the command suite and the
  81   operation code replaced with an underscore.  The NAME section of the
  82   operation man page must also use an underscore (fs_listacl, not fs
  83   listacl) for compatibility with some man programs.  The SYNOPSIS section
  84   should, of course, use a space, since that's what the user must type.
  85
  86   All man pages must follow the standard layout for man page sections and
  87   formatting.  The best general reference is the pod2man man page,
  88   although the sections used for OpenAFS man pages aren't quite the same
  89   (see below).  In particular, please use the following markup:
  90
  91    * B<> for all commands, command/operation code pairs, and options.
  92    * F<> for file names, directory names, partition names, or paths.
  93    * <I<>> for user-provided arguments (note the surrounding <>).
  94    * I<> for terms being defined or titles of works.
  95    * C<> for command examples, ACL characters, and example arguments.
  96
  97   Also see the afs(1) man page for general rules about how OpenAFS man
  98   pages are formatted and for standard terminology to use when talking
  99   about OpenAFS commands.
 100
 101   Each man page should have the following sections:  NAME, SYNOPSIS (for
 102   commands only), DESCRIPTION, CAUTIONS, OPTIONS (for commands only),
 103   OUTPUT (where appropriate), EXAMPLES, PRIVILEGE REQUIRED (for commands
 104   only), SEE ALSO, and COPYRIGHT, generally in that order.  Be sure to
 105   include the IBM copyright in all man pages derived from the original IBM
 106   documentation.  If you wrote the man page yourself, please include your
 107   own copyright and a statement that the man page is released under the
 108   IBM Public License Version 1.0, or under some other license that is
 109   sufficiently compatible that we can use your work.  If you use another
 110   license and that license isn't "public domain" or one of the ones
 111   already listed in our LICENSE file, you have to give the full license
 112   text in the man page; please don't use a license so long that this is
 113   annoying.
 114
 115   The SYNOPSIS section should start with the full command name and the
 116   full names of all options, and then have a second section showing the
 117   most abbreviated form of the command name and its options.  If the
 118   command has aliases, it should have additional sections showing those.
 119   Please be sure to follow all of the formatting requirements for
 120   commands, flags, and options.  Enclose optional arguments in [] and
 121   choices in () separated by |.  Command names and options are marked up
 122   with B<> as mentioned above; all other literal text that should be
 123   entered on the command line gets no markup.
 124
 125   References to other OpenAFS man pages should be given as L<afs(1)>.
 126   Other man pages should be noted like df(1), without the L<> markup.
 127   References to functions should be noted like function() with the
 128   trailing parens.  The POD converters know how to format these sorts of
 129   references appropriately.  References to other sections in the same page
 130   should be given as L<SECTION>.  Man pages for all other AFS commands or
 131   file formats referenced in the page should be listed in the SYNOPSIS.
 132   List each reference on its own line for easier addition of other
 133   references later, but don't put blank lines between them.  Don't forget
 134   the commas at the end of each line but the last.
 135
 136   Command and output examples should be indented three spaces.  Commands
 137   entered by the user should be given on a line beginning with %.  If the
 138   command doesn't fit in 80 columns, put in a backslash at a logical break
 139   point and continue the line with an additional four spaces of
 140   indentation.  Output examples may be wrapped with an additional four
 141   spaces of indentation but probably shouldn't be; not wrapping makes the
 142   man page look somewhat less readable, but is less confusing when
 143   converted to other formats such as HTML.
 144
 145   POD does not allow markup in verbatim paragraphs (which are indicated by
 146   indenting the first line of the paragraph), so metasyntactic variables
 147   in examples should be shown like <this> with simple angle brackets
 148   surrounding the variable.  For consistency in formatting, references to
 149   those variables should be formatted the same in following text.
 150
 151 Man Page Sections
 152
 153   The section of a man page is determined by which directory it's in.
 154   pod1 will be section 1 man pages, pod5 will be section 5, and pod8 will
 155   be section 8.
 156
 157   The breakdown between section 1 and section 8 is fuzzy and it's hard to
 158   get right.  The current layout balances the following goals:
 159
 160   * In general, section 1 is used for commands that can be executed by any
 161     user and section 8 is used for commands that can only be meaningfully
 162     issued as root.  If a command can be run with AFS privileged
 163     credentials but still as a regular user on the local system, the
 164     preference is for it to be in section 1, although some pages of that
 165     type are in section 8.
 166
 167   * All the commands for a given suite should be kept together.  So, for
 168     example, there are fs commands that can only be issued as root, but
 169     since most of the suite is available to any user, all of the fs
 170     commands are in section 1.
 171
 172   * The sections of the man pages should roughly correspond to the
 173     installation paths of the binaries.  Binaries installed in bin should
 174     have man pages in section 1 and binaries installed in sbin should have
 175     man pages in section 8.
 176
 177   Section 5 should be used for all documentation of configuration files
 178   and file formats.
 179
 180 How You Can Help
 181
 182   The OpenAFS man page project is just starting, and a lot of work remains
 183   to be done.  Any and all contributions are greatly appreciated.  What
 184   follows is a list of the ways that you can help in order of increasing
 185   helpfulness.  If you only have time to do something near the top of the
 186   list, please do; every little bit helps.  If you have more time and can
 187   do something closer to the bottom of the list, that's even better and
 188   your contribution can be included more rapidly.
 189
 190    * Point out places OpenAFS behavior has changed since the documentation
 191      was written, or point out missing documentation.  Please check the
 192      "Known Problems" list below to make sure that the item is not already
 193      noted.
 194
 195    * Point out formatting problems, typos, formatting inconsistency, and
 196      other markup or language problems in the man pages.
 197
 198    * Provide missing documentation in some form (text, HTML, whatever)
 199      that can be incorporated into the man pages, or detailed explanations
 200      of how the existing documentation needs to be changed to match what
 201      the tools actually do.
 202
 203    * Provide missing man pages in POD format suitable for immediate
 204      inclusion in the documentation.  Please try to follow the formatting
 205      standards documented in the "Formatting Standards" section above, and
 206      look at the existing man pages for examples.
 207
 208    * Provide patches against the POD source that correct formatting
 209      problems, typos, formatting inconsistencies, or other markup or
 210      language problems with the man pages.
 211
 212    * Provide patches against the POD source that add or correct the
 213      documentation of commands or file formats for changes in OpenAFS.
 214
 215   Please send contributions either to the openafs-doc list or as bugs
 216   filed via the bug reporting instructions at <http://www.openafs.org/>.
 217   If you do submit a bug, please send me a note at rra@stanford.edu with
 218   the bug number so that I'm aware of it, as I don't always notice new
 219   bugs.
 220
 221   You can test your new POD documentation by running the check-pod script
 222   in this directory with "prove check-pod".  (And check other people's
 223   documentation and find any problems that have crept in.)  You will need
 224   to have Test::Pod installed.
 225
 226 Known Problems
 227
 228   The current man pages have the following known deficiencies.  Please
 229   don't just report the deficiency again, but any contributions towards
 230   fixing it are greatly appreciated.
 231
 232    * The following installed commands have no man pages:
 233
 234        compile_et.afs
 235        copyauth
 236        fs cscpolicy
 237        fs getfid
 238        fs memdump
 239        fs monitor
 240        fs rxstatpeer
 241        fs rxstatproc
 242        fs setcbaddr
 243        fs trace
 244        klog.krb
 245        krb.conf
 246        pagsh.krb
 247        restorevol
 248        rmtsysd
 249        tokens.krb
 250        vsys
 251
 252    * Add -noresolve to the documentation of all the vos commands.
 253
 254    * klog.krb, pagsh.krb, and tokens.krb need to be listed as alternative
 255      names in the NAME line of the non-.krb man pages, links should be
 256      installed on man page installation, and the behavior of pagsh.krb
 257      should be documented in the pagsh man page.
 258
 259    * Some of the documentation in fs getserverprefs needs minor updates to
 260      reflect what happens in the dynroot case.
 261
 262    * bos listkeys and the KeyFile man page assume that you're using the
 263      kaserver.
 264
 265    * bos addkey should be marked deprecated in favor of using asetkey with
 266      a keytab.
 267
 268    * There are lingering references to AFS Development or AFS Product
 269      Support in descriptions of options that one should generally not
 270      use.  Also, all of the manual references refer to the "IBM" manual.
 271      We should decide how to handle this terminology-wise.
 272
 273    * The salvager actually creates a bunch of SalvageLog files and then
 274      combines them, but the SalvageLog man page doesn't reflect this.
 275
 276    * The CellServDB documentation hasn't been updated for -dynroot.
 277
 278    * In the suite introduction pages (pts, vos, etc.), each of the
 279      subcommands in the initial list should be a link to the relevant
 280      page in the HTML output.  This has been done for the fs intro page
 281      and the same transform needs to be applied to the other pages.  See
 282      the fs intro page for the details.
 283
 284    * The references to the other OpenAFS manuals, such as the Quick Start
 285      guide and the Admin Guide, should be links, probably to the documents
 286      on openafs.org.
 287
 288    * There's no mention of the Kerberos v5 support.  At least, we need
 289      some disclaimers under klog and friends talking about sites without
 290      kaserver (and possibly without fakeka), and deprecation warnings
 291      on the .krb varient commands.
 292
 293    * We need a way to add links to other man pages (kinit most notably)
 294      without creating dangling links in the HTML output.  This probably
 295      means that the HTML conversion script needs to generate at startup
 296      a list of all valid man page link targets and not linkify the ones
 297      that don't match a valid target.
 298
 299    * Provide a way to substitute the correct paths into the HTML output
 300      from Autoconf results.
 301
 302    * Currently, the man pages are built by regen.sh, which is somewhat
 303      annoying since it takes a long time.  Figure out how better to do this
 304      during the release process so that end users don't have to have
 305      pod2man.
 306
 307    * Review the sections used for all man pages against what directories
 308      the commands are installed into.  (In some cases, it may be better to
 309      change the directory than the section of the man page.)
 310
 311   If you notice other problems, please send them to the openafs-doc list
 312   even if you don't have time to fix them.  Someone else might, and we
 313   want to track all of the issues.