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.
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.
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
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).
35 POD and Man Page Generation
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.
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.
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).
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:
71 It will generate HTML pages in the html subdirectory of this directory.
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.
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:
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 * S<<<>>> for text with non-breaking spaces (usually in synopsis).
98 Also see the afs(1) man page for general rules about how OpenAFS man
99 pages are formatted and for standard terminology to use when talking
100 about OpenAFS commands.
102 Each man page should have the following sections: NAME, SYNOPSIS (for
103 commands only), DESCRIPTION, CAUTIONS, OPTIONS (for commands only),
104 OUTPUT (where appropriate), EXAMPLES, PRIVILEGE REQUIRED (for commands
105 only), SEE ALSO, and COPYRIGHT, generally in that order. Be sure to
106 include the IBM copyright in all man pages derived from the original IBM
107 documentation. If you wrote the man page yourself, please include your
108 own copyright and a statement that the man page is released under the
109 IBM Public License Version 1.0, or under some other license that is
110 sufficiently compatible that we can use your work. If you use another
111 license and that license isn't "public domain" or one of the ones
112 already listed in our LICENSE file, you have to give the full license
113 text in the man page; please don't use a license so long that this is
116 The SYNOPSIS section should start with the full command name and the
117 full names of all options, and then have a second section showing the
118 most abbreviated form of the command name and its options. If the
119 command has aliases, it should have additional sections showing those.
120 Please be sure to follow all of the formatting requirements for
121 commands, flags, and options. Enclose optional arguments in [] and
122 choices in () separated by |. Command names and options are marked up
123 with B<> as mentioned above; all other literal text that should be
124 entered on the command line gets no markup.
126 References to other OpenAFS man pages should be given as L<afs(1)>.
127 Other man pages should be noted like df(1), without the L<> markup.
128 References to functions should be noted like function() with the
129 trailing parens. The POD converters know how to format these sorts of
130 references appropriately. References to other sections in the same page
131 should be given as L<SECTION>. Man pages for all other AFS commands or
132 file formats referenced in the page should be listed in the SYNOPSIS.
133 List each reference on its own line for easier addition of other
134 references later, but don't put blank lines between them. Don't forget
135 the commas at the end of each line but the last.
137 Command and output examples should be indented three spaces. Commands
138 entered by the user should be given on a line beginning with %. If the
139 command doesn't fit in 80 columns, put in a backslash at a logical break
140 point and continue the line with an additional four spaces of
141 indentation. Output examples may be wrapped with an additional four
142 spaces of indentation but probably shouldn't be; not wrapping makes the
143 man page look somewhat less readable, but is less confusing when
144 converted to other formats such as HTML.
146 POD does not allow markup in verbatim paragraphs (which are indicated by
147 indenting the first line of the paragraph), so metasyntactic variables
148 in examples should be shown like <this> with simple angle brackets
149 surrounding the variable. For consistency in formatting, references to
150 those variables should be formatted the same in following text.
154 The section of a man page is determined by which directory it's in.
155 pod1 will be section 1 man pages, pod5 will be section 5, and pod8 will
158 The breakdown between section 1 and section 8 is fuzzy and it's hard to
159 get right. The current layout balances the following goals:
161 * In general, section 1 is used for commands that can be executed by any
162 user and section 8 is used for commands that can only be meaningfully
163 issued as root. If a command can be run with AFS privileged
164 credentials but still as a regular user on the local system, the
165 preference is for it to be in section 1, although some pages of that
166 type are in section 8.
168 * All the commands for a given suite should be kept together. So, for
169 example, there are fs commands that can only be issued as root, but
170 since most of the suite is available to any user, all of the fs
171 commands are in section 1.
173 * The sections of the man pages should roughly correspond to the
174 installation paths of the binaries. Binaries installed in bin should
175 have man pages in section 1 and binaries installed in sbin should have
176 man pages in section 8.
178 Section 5 should be used for all documentation of configuration files
183 The OpenAFS man page project is just starting, and a lot of work remains
184 to be done. Any and all contributions are greatly appreciated. What
185 follows is a list of the ways that you can help in order of increasing
186 helpfulness. If you only have time to do something near the top of the
187 list, please do; every little bit helps. If you have more time and can
188 do something closer to the bottom of the list, that's even better and
189 your contribution can be included more rapidly.
191 * Point out places OpenAFS behavior has changed since the documentation
192 was written, or point out missing documentation. Please check the
193 "Known Problems" list below to make sure that the item is not already
196 * Point out formatting problems, typos, formatting inconsistency, and
197 other markup or language problems in the man pages.
199 * Provide missing documentation in some form (text, HTML, whatever)
200 that can be incorporated into the man pages, or detailed explanations
201 of how the existing documentation needs to be changed to match what
202 the tools actually do.
204 * Provide missing man pages in POD format suitable for immediate
205 inclusion in the documentation. Please try to follow the formatting
206 standards documented in the "Formatting Standards" section above, and
207 look at the existing man pages for examples.
209 * Provide patches against the POD source that correct formatting
210 problems, typos, formatting inconsistencies, or other markup or
211 language problems with the man pages.
213 * Provide patches against the POD source that add or correct the
214 documentation of commands or file formats for changes in OpenAFS.
216 Please send contributions either to the openafs-doc list or as bugs
217 filed via the bug reporting instructions at <http://www.openafs.org/>.
218 If you do submit a bug, please send me a note at rra@stanford.edu with
219 the bug number so that I'm aware of it, as I don't always notice new
222 You can test your new POD documentation by running the check-pod script
223 in this directory with "prove check-pod". (And check other people's
224 documentation and find any problems that have crept in.) You will need
225 to have Test::Pod installed.
229 The current man pages have the following known deficiencies. Please
230 don't just report the deficiency again, but any contributions towards
231 fixing it are greatly appreciated.
233 * Some of the documentation in fs getserverprefs needs minor updates to
234 reflect what happens in the dynroot case.
236 * bos listkeys and the KeyFile man page assume that you're using the
239 * bos addkey should be marked deprecated in favor of using asetkey with
242 * There are lingering references to AFS Development or AFS Product
243 Support in descriptions of options that one should generally not
244 use. Also, all of the manual references refer to the "IBM" manual.
245 We should decide how to handle this terminology-wise.
247 * The salvager actually creates a bunch of SalvageLog files and then
248 combines them, but the SalvageLog man page doesn't reflect this.
250 * The references to the other OpenAFS manuals, such as the Quick Start
251 guide and the Admin Guide, should be links, probably to the documents
254 * There's no mention of the Kerberos v5 support. At least, we need
255 some disclaimers under klog and friends talking about sites without
256 kaserver (and possibly without fakeka), and deprecation warnings
257 on the .krb varient commands.
259 * Linked cells are currently documented in fs newcell as being only
260 for DCE, which is not correct. That documentation, aklog, and the
261 CellServDB documentation needs to be updated.
263 * We need a way to add links to other man pages (kinit most notably)
264 without creating dangling links in the HTML output. This probably
265 means that the HTML conversion script needs to generate at startup
266 a list of all valid man page link targets and not linkify the ones
267 that don't match a valid target.
269 * Provide a way to substitute the correct paths into the HTML output
270 from Autoconf results.
272 * Currently, the man pages are built by regen.sh, which is somewhat
273 annoying since it takes a long time. Figure out how better to do this
274 during the release process so that end users don't have to have
277 * Review the sections used for all man pages against what directories
278 the commands are installed into. (In some cases, it may be better to
279 change the directory than the section of the man page.)
281 * Consider using M4 or similar to operate on POD text before output.
282 This would allow common options like vos -c,-noa,-l,-v,-e,-nor
283 to be documented once and automatically included in all vos_ reference
284 pages, much like the vos.c source includes those arguments as COMMONPARMS.
286 * Check that suite intro pages mention all subcommands
288 Changes needed to have vos suite commands completely up to date,
289 including the 1.5 branch:
291 * Document vos listaddrs -uuid / -host, and verify docs and example for
294 * Document vos offline -busy / -sleep
296 * Do vos online/offline support -bless/-unbless? By looking at the
297 source they dont, and according to Git log that goes back to 2000
299 According to Derrick, there was a patch to support them that vanished.
300 Either the patch should be found, or bless/unbless removed from
303 * Document vos create -minquota which is available since 1.5.61
305 * Document vos restore -creation/-lastupdate and -nodelete
307 * Document vos delentry -noexecute. Should this option also be renamed
308 to -dryrun like others?
310 Man section 8 suite commands:
312 * Mention bos (un)blockscanner in bos.pod text, not just in See Also
315 * Update fstrace source to include option descriptions (for content,
316 use existing manpage information "condensed" to half line of text)
318 * Update backup source to include option descriptions (for content,
319 use existing manpage information "condensed" to half line of text)
321 * Document backup deletedump -port/-groupid/-dbonly/-force/-noexecute
323 * Replace backup diskrestore/dump -n option with -noexecute or -dryrun?
325 * Document backup help -admin
327 * Document backup volrestore -usedump. Also, s/-n/.../ as above?
329 * Replace backup volsetrestore -n option with -noexecute or -dryrun?
331 If you notice other problems, please send them to the openafs-doc list
332 even if you don't have time to fix them. Someone else might, and we
333 want to track all of the issues.
git://git.openafs.org / openafs.git / blob