2caed700602df8d22ee44c4d65d71552bc238163
[openafs.git] / 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.
82
83   All man pages must follow the standard layout for man page sections and
84   formatting.  The best general reference is the pod2man man page,
85   although the sections used for OpenAFS man pages aren't quite the same
86   (see below).  In particular, please use the following markup:
87
88    * B<> for all commands, command/operation code pairs, and options.
89    * F<> for file names, directory names, partition names, or paths.
90    * <I<>> for user-provided arguments (note the surrounding <>).
91    * I<> for terms being defined or titles of works.
92    * C<> for command examples, ACL characters, and example arguments.
93
94   Also see the afs(1) man page for general rules about how OpenAFS man
95   pages are formatted and for standard terminology to use when talking
96   about OpenAFS commands.
97
98   Each man page should have the following sections:  NAME, SYNOPSIS (for
99   commands only), DESCRIPTION, CAUTIONS, OPTIONS (for commands only),
100   OUTPUT (where appropriate), EXAMPLES, PRIVILEGE REQUIRED (for commands
101   only), SEE ALSO, and COPYRIGHT, generally in that order.  Be sure to
102   include the IBM copyright in all man pages derived from the original IBM
103   documentation.  If you wrote the man page yourself, please include your
104   own copyright and a statement that the man page is released under the
105   IBM Public License Version 1.0, or under some other license that is
106   sufficiently compatible that we can use your work.  If you use another
107   license and that license isn't "public domain," you have to give the
108   full license text in the man page; please don't use a license so long
109   that this is annoying.
110
111   The SYNOPSIS section should start with the full command name and the
112   full names of all options, and then have a second section showing the
113   most abbreviated form of the command name and its options.  If the
114   command has aliases, it should have additional sections showing those.
115   Please be sure to follow all of the formatting requirements for
116   commands, flags, and options.  Enclose optional arguments in [] and
117   choices in () separated by |.  Command names and options are marked up
118   with B<> as mentioned above; all other literal text that should be
119   entered on the command line gets no markup.
120
121   References to other OpenAFS man pages should be given as L<afs(1)>.
122   Other man pages should be noted like df(1), without the L<> markup.
123   References to functions should be noted like function() with the
124   trailing parens.  The POD converters know how to format these sorts of
125   references appropriately.  References to other sections in the same page
126   should be given as L<SECTION>.
127
128   Command and output examples should be indented three spaces.  Commands
129   entered by the user should be given on a line beginning with %.  If the
130   command doesn't fit in 80 columns, put in a backslash at a logical break
131   point and continue the line with an additional four spaces of
132   indentation.  Output examples may be wrapped with an additional four
133   spaces of indentation but probably shouldn't be; not wrapping makes the
134   man page look somewhat less readable, but is less confusing when
135   converted to other formats such as HTML.
136
137   POD does not allow markup in verbatim paragraphs (which are indicated by
138   indenting the first line of the paragraph), so metasyntactic variables
139   in examples should be shown like <this> with simple angle brackets
140   surrounding the variable.  For consistency in formatting, references to
141   those variables should be formatted the same in following text.
142
143 How You Can Help
144
145   The OpenAFS man page project is just starting, and a lot of work remains
146   to be done.  Any and all contributions are greatly appreciated.  What
147   follows is a list of the ways that you can help in order of increasing
148   helpfulness.  If you only have time to do something near the top of the
149   list, please do; every little bit helps.  If you have more time and can
150   do something closer to the bottom of the list, that's even better and
151   your contribution can be included more rapidly.
152
153    * Point out places OpenAFS behavior has changed since the documentation
154      was written, or point out missing documentation.  Please check the
155      "Known Problems" list below to make sure that the item is not already
156      noted.
157
158    * Point out formatting problems, typos, formatting inconsistency, and
159      other markup or language problems in the man pages.
160
161    * Provide missing documentation in some form (text, HTML, whatever)
162      that can be incorporated into the man pages, or detailed explanations
163      of how the existing documentation needs to be changed to match what
164      the tools actually do.
165
166    * Provide missing man pages in POD format suitable for immediate
167      inclusion in the documentation.  Please try to follow the formatting
168      standards documented in the "Formatting Standards" section above, and
169      look at the existing man pages for examples.
170
171    * Provide patches against the POD source that correct formatting
172      problems, typos, formatting inconsistencies, or other markup or
173      language problems with the man pages.
174
175    * Provide patches against the POD source that add or correct the
176      documentation of commands or file formats for changes in OpenAFS.
177
178   Please send contributions either to the openafs-doc list or as bugs
179   filed via the bug reporting instructions at <http://www.openafs.org/>.
180   If you do submit a bug, please send me a note at rra@stanford.edu with
181   the bug number so that I'm aware of it, as I don't always notice new
182   bugs.
183
184 Known Problems
185
186   The current man pages have the following known deficiencies.  Please
187   don't just report the deficiency again, but any contributions towards
188   fixing it are greatly appreciated.
189
190    * The following installed commands have no man pages:
191
192        bos_util
193        copyauth
194        fs getcalleraccess
195        fs listaliases
196        fs newalias
197        fs rxstatpeer
198        fs rxstatproc
199        fs setcbaddr
200        kseal
201        pts interactive
202        pts quit
203        pts sleep
204        pts source
205        read_tape
206        restorevol
207        rmtsysd
208        vldb_convert
209        vos changeloc
210        vos clone
211        vos convertROtoRW
212        vos copy
213        vos shadow
214        vos size
215        vsys
216
217    * The following configuration files have no man pages:
218
219        CellAlias
220
221    * klog.krb, pagsh.krb, and tokens.krb need to be listed as alternative
222      names in the NAME line of the non-.krb man pages, links should be
223      installed on man page installation, and the behavior of pagsh.krb
224      should be documented in the pagsh man page.
225
226    * Some of the documentation in fs getserverprefs needs minor updates to
227      reflect what happens in the dynroot case.
228
229    * fs sysname documentation needs to include the possibility of setting
230      multiple sysnames and the resulting behavior.
231
232    * bos listkeys and the KeyFile man page assume that you're using the
233      kaserver.
234
235    * I'm fairly sure that the fileserver man page no longer documents all
236      of the fileserver options.
237
238    * The package man page should probably mention the (pointless) package
239      apropos and package help commands, or they could be removed.  There
240      used to be separate man pages for them, but that seemed rather
241      pointless.
242
243    * There are lingering references to AFS Development or AFS Product
244      Support in descriptions of options that one should generally not
245      use.  Also, all of the manual references refer to the "IBM" manual.
246      We should decide how to handle this terminology-wise.
247
248    * The salvager actually creates a bunch of SalvageLog files and then
249      combines them, but the SalvageLog man page doesn't reflect this.
250
251    * The CellServDB documentation hasn't been updated for -dynroot.
252
253    * The aklog man page isn't in POD.  (Neither is the mpp man page, but
254      I don't think we care about it and it's not currently installed.)
255
256    * In the suite introduction pages (pts, vos, etc.), each of the
257      subcommands in the initial list should be a link to the relevant
258      page in the HTML output.  This has been done for the fs intro page
259      and the same transform needs to be applied to the other pages.  See
260      the fs intro page for the details.
261
262    * The references to the other OpenAFS manuals, such as the Quick Start
263      guide and the Admin Guide, should be links, probably to the documents
264      on openafs.org.
265
266    * There's no mention of the Kerberos v5 support.  At least, we need
267      some disclaimers under klog and friends talking about sites without
268      kaserver (and possibly without fakeka), and deprecation warnings
269      on the .krb varient commands.
270
271    * We need a way to add links to other man pages (kinit most notably)
272      without creating dangling links in the HTML output.  This probably
273      means that the HTML conversion script needs to generate at startup
274      a list of all valid man page link targets and not linkify the ones
275      that don't match a valid target.
276
277    * Provide a way to substitute the correct paths into the HTML output
278      from Autoconf results.
279
280    * Currently, the man pages are built by regen.sh, which is somewhat
281      annoying since it takes a long time.  Figure out how better to do this
282      during the release process so that end users don't have to have
283      pod2man.
284
285    * Review the sections used for all man pages against what directories
286      the commands are installed into.  (In some cases, it may be better to
287      change the directory than the section of the man page.)
288
289   If you notice other problems, please send them to the openafs-doc list
290   even if you don't have time to fix them.  Someone else might, and we
291   want to track all of the issues.