diff options
Diffstat (limited to 'static/plan9-4e/man4')
40 files changed, 6749 insertions, 0 deletions
diff --git a/static/plan9-4e/man4/0intro.4 b/static/plan9-4e/man4/0intro.4 new file mode 100644 index 00000000..8a3a6a3d --- /dev/null +++ b/static/plan9-4e/man4/0intro.4 @@ -0,0 +1,14 @@ +.TH INTRO 4 +.SH NAME +intro \- introduction to file servers +.SH DESCRIPTION +A Plan 9 +.I "file server" +provides a file tree to processes. +This section of the manual describes servers than can be +mounted in a name space to give a file-like interface to interesting services. +A file server may be a provider of a conventional file system, +with files maintained on permanent storage, +or it may also be a process that synthesizes files in some manner. +.SH SEE ALSO +.IR bind (1) diff --git a/static/plan9-4e/man4/INDEX.4 b/static/plan9-4e/man4/INDEX.4 new file mode 100644 index 00000000..8500fc3d --- /dev/null +++ b/static/plan9-4e/man4/INDEX.4 @@ -0,0 +1,71 @@ +0intro 0intro +intro 0intro +acme acme +archfs archfs +cddb cdfs +cdfs cdfs +cfs cfs +C consolefs +clog consolefs +consolefs consolefs +9660srv dossrv +9fat: dossrv +a: dossrv +b: dossrv +c: dossrv +d: dossrv +dosmnt dossrv +dossrv dossrv +eject dossrv +execnet execnet +exportfs exportfs +srvfs exportfs +factotum factotum +fgui factotum +secretpem factotum +fs fs +ftpfs ftpfs +import import +iostats iostats +keyfs keyfs +warning keyfs +kfs kfs +lnfs lnfs +namespace namespace +nntpfs nntpfs +paqfs paqfs +plumber plumber +ramfs ramfs +ratfs ratfs +rdbfs rdbfs +rio rio +sacfs sacfs +snap snap +snapfs snap +9fs srv +srv srv +srvold9p srv +32vfs tapefs +cpiofs tapefs +tapefs tapefs +tapfs tapefs +tarfs tapefs +tpfs tapefs +v10fs tapefs +v6fs tapefs +fax telco +faxreceive telco +faxsend telco +telco telco +telcodata telco +telcofax telco +u9fs u9fs +usb usb +usbaudio usb +usbmouse usb +usbd usbd +vacfs vacfs +webcookies webcookies +webfs webfs +wikifs wikifs +wikipost wikifs diff --git a/static/plan9-4e/man4/INDEX.html.4 b/static/plan9-4e/man4/INDEX.html.4 new file mode 100644 index 00000000..c191776a --- /dev/null +++ b/static/plan9-4e/man4/INDEX.html.4 @@ -0,0 +1,157 @@ +<HEAD> +<TITLE>plan 9 man section 4</TITLE> +</HEAD> +<BODY> +<B>[<A HREF="/sys/man/index.html">manual index</A>]</B> +<H2>Plan 9 from Bell Labs - Section 4 - File Servers</H2> +<HR> +<DL> +<DT><A HREF="/magic/man2html/4/0intro">0intro</A> +- introduction to file servers +<DD><TT> intro</TT> +</DT> +<DT><A HREF="/magic/man2html/4/acme">acme</A> +- control files for text windows +<DD><TT> acme</TT> +</DT> +<DT><A HREF="/magic/man2html/4/archfs">archfs</A> +- mount mkfs-style archive +<DD><TT> archfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/cdfs">cdfs</A> +- CD reader and writer file system +<DD><TT> cdfs, cddb</TT> +</DT> +<DT><A HREF="/magic/man2html/4/cfs">cfs</A> +- cache file system +<DD><TT> cfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/consolefs">consolefs</A> +- file system for console access +<DD><TT> consolefs, C, clog</TT> +</DT> +<DT><A HREF="/magic/man2html/4/dossrv">dossrv</A> +- DOS and ISO9660 file systems +<DD><TT> dossrv, 9660srv, a:, b:, c:, d:, 9fat:, dosmnt, eject</TT> +</DT> +<DT><A HREF="/magic/man2html/4/execnet">execnet</A> +- network interface to program execution +<DD><TT> execnet</TT> +</DT> +<DT><A HREF="/magic/man2html/4/exportfs">exportfs</A> +- network file server plumbing +<DD><TT> exportfs, srvfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/factotum">factotum</A> +- +<DD><TT> factotum, fgui, secretpem\- authentication agent and its graphics interface</TT> +</DT> +<DT><A HREF="/magic/man2html/4/fs">fs</A> +- file server, dump +<DD><TT> fs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/ftpfs">ftpfs</A> +- file transfer protocol (FTP) file system +<DD><TT> ftpfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/import">import</A> +- import a name space from a remote system +<DD><TT> import</TT> +</DT> +<DT><A HREF="/magic/man2html/4/iostats">iostats</A> +- file system to measure I/O +<DD><TT> iostats</TT> +</DT> +<DT><A HREF="/magic/man2html/4/keyfs">keyfs</A> +- authentication database files +<DD><TT> keyfs, warning</TT> +</DT> +<DT><A HREF="/magic/man2html/4/kfs">kfs</A> +- disk file system +<DD><TT> kfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/lnfs">lnfs</A> +- long name file system +<DD><TT> lnfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/namespace">namespace</A> +- structure of conventional file name space +<DD><TT> namespace</TT> +</DT> +<DT><A HREF="/magic/man2html/4/nntpfs">nntpfs</A> +- network news transport protocol (NNTP) file system +<DD><TT> nntpfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/paqfs">paqfs</A> +- compressed read-only file system +<DD><TT> paqfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/plumber">plumber</A> +- file system for interprocess messaging +<DD><TT> plumber</TT> +</DT> +<DT><A HREF="/magic/man2html/4/ramfs">ramfs</A> +- memory file system +<DD><TT> ramfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/ratfs">ratfs</A> +- mail address ratification file system +<DD><TT> ratfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/rdbfs">rdbfs</A> +- remote kernel debugging file system +<DD><TT> rdbfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/rio">rio</A> +- window system files +<DD><TT> rio</TT> +</DT> +<DT><A HREF="/magic/man2html/4/sacfs">sacfs</A> +- compressed file system +<DD><TT> sacfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/snap">snap</A> +- create and mount process snapshots +<DD><TT> snap, snapfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/srv">srv</A> +- start network file service +<DD><TT> srv, srvold9p, 9fs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/tapefs">tapefs</A> +- mount archival file systems +<DD><TT> 32vfs, cpiofs, tapfs, tarfs, tpfs, v6fs, v10fs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/telco">telco</A> +- telephone dialer network +<DD><TT> telco, faxreceive, faxsend, fax, telcofax, telcodata</TT> +</DT> +<DT><A HREF="/magic/man2html/4/u9fs">u9fs</A> +- serve 9P from Unix +<DD><TT> u9fs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/usb">usb</A> +- Universal Serial Bus user level device drivers +<DD><TT> usbmouse, usbaudio</TT> +</DT> +<DT><A HREF="/magic/man2html/4/usbd">usbd</A> +- Universal Serial Bus daemon +<DD><TT> usbd</TT> +</DT> +<DT><A HREF="/magic/man2html/4/vacfs">vacfs</A> +- a Venti-based file system +<DD><TT> vacfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/webcookies">webcookies</A> +- HTTP cookie manager +<DD><TT> webcookies</TT> +</DT> +<DT><A HREF="/magic/man2html/4/webfs">webfs</A> +- world wide web file system +<DD><TT> webfs</TT> +</DT> +<DT><A HREF="/magic/man2html/4/wikifs">wikifs</A> +- wiki file system +<DD><TT> wikifs, wikipost</TT> +</DT> +</DL> diff --git a/static/plan9-4e/man4/Makefile b/static/plan9-4e/man4/Makefile new file mode 100644 index 00000000..38781aad --- /dev/null +++ b/static/plan9-4e/man4/Makefile @@ -0,0 +1,3 @@ +MAN = $(wildcard *.4) + +include ../../mandoc.mk diff --git a/static/plan9-4e/man4/acme.4 b/static/plan9-4e/man4/acme.4 new file mode 100644 index 00000000..bb20cb0f --- /dev/null +++ b/static/plan9-4e/man4/acme.4 @@ -0,0 +1,408 @@ +.TH ACME 4 +.SH NAME +acme \- control files for text windows +.SH SYNOPSIS +.B acme +[ +.B -f +.I varfont +] [ +.B -F +.I fixfont +] +[ +.I file +\&... ] +.SH DESCRIPTION +The text window system +.IR acme (1) +serves a variety of files for reading, writing, and controlling +windows. +Some of them are virtual versions of system files for dealing +with the virtual console; others control operations +of +.I acme +itself. +When a command is run under +.IR acme , +a directory holding these files is mounted on +.B /mnt/acme +(also bound to +.BR /mnt/wsys ) +and also +.BR /dev ; +the files mentioned here +appear in both those directories. +.PP +Some of these files supply virtual versions of services available from the underlying +environment, in particular the character terminal files +.IR cons (3). +(Unlike in +.IR rio (1), +each command under +.I acme +sees the same set of files; there is not a distinct +.B /dev/cons +for each window.) +Other files are unique to +.IR acme . +.TP +.B acme +is a subdirectory used by +.B win +(see +.IR acme (1)) +as a mount point for the +.I acme +files associated with the window in which +.B win +is running. +It has no specific function under +.I acme +itself. +.TP +.B cons +is the standard and diagnostic output file for all commands +run under +.IR acme . +(Input for commands is redirected to +.BR /dev/null .) +Text written to +.B cons +appears in a window labeled +.IB dir /+Errors\f1, +where +.I dir +is the directory in which the command +was run. +The window is created if necessary, but not until text is actually written. +.TP +.B consctl +Is an empty unwritable file present only for compatibility; there is no way +to turn off `echo', for example, under +.IR acme . +.TP +.B index +holds a sequence of lines of text, one per window. Each line has 5 decimal numbers, +each formatted in 11 characters plus a blank\(emthe window ID; +number of characters (runes) in the tag; +number of characters in the body; +a 1 if the window is a directory, 0 otherwise; +and a 1 if the window is modified, 0 +otherwise\(emfollowed by the tag up to a newline if present. +Thus at character position 5×12 starts the name of the window. +If a file has multiple zeroxed windows open, +only the most recently used will appear in the +.B index +file. +.TP +.B label +is an empty file, writable without effect, present only for compatibility with +.BR rio . +.TP +.B new +A directory analogous to the numbered directories +.RI ( q.v. ). +Accessing any +file in +.B new +creates a new window. Thus to cause text to appear in a new window, +write it to +.BR /dev/new/body . +For more control, open +.BR /dev/new/ctl +and use the interface described below. +.LP +.PP +Each +.I acme +window has associated a directory numbered by its ID. +Window IDs are chosen sequentially and may be discovered by the +.B ID +command, by +reading the +.B ctl +file, or +indirectly through the +.B index +file. The files in the numbered directories are as follows. +.TP +.B addr +may be written with any textual address (line number, regular expression, etc.), +in the format understood by button 3 but without the initial colon, including compound addresses, +to set the address for text accessed through the +.B data +file. +When read, it returns the value of the address that would next be read +or written through the +.B data +file, in the format +.BI # m ,# n +where +.I m +and +.I n +are character (not byte) offsets. If +.I m +and +.I n +are identical, the format is just +.BI # m\f1. +Thus a regular expression may be evaluated by writing it to +.B addr +and reading it back. +The +.B addr +address has no effect on the user's selection of text. +.TP +.B body +holds contents of the window body. It may be read at any byte offset. +Text written to +.B body +is always appended; the file offset is ignored. +.TP +.B ctl +may be read to recover the five numbers as held in the +.B index +file, described above, plus two more fields: the width of the +window in pixels and the name of the font used in the window. +Text messages may be written to +.B ctl +to affect the window. +Each message is terminated by a newline and multiple +messages may be sent in a single write. +.RS .5i +.TF limit=addr +.TP +.B addr=dot +Set the +.B addr +address to that of the user's selected text in the window. +.TP +.B clean +Mark the window clean as though it has just been written. +.TP +.B dirty +Mark the window dirty, the opposite of clean. +.TP +.B cleartag +Remove all text in the tag after the vertical bar. +.TP +.B del +Equivalent to the +.B Del +interactive command. +.TP +.B delete +Equivalent to the +.B Delete +interactive command. +.TP +.B dot=addr +Set the user's selected text in the window to the text addressed by the +.B addr +address. +.TP +.BI dump " command +Set the command string to recreate the window from a dump file. +.TP +.BI dumpdir " directory +Set the directory in which to run the command to recreate the window from a dump file. +.TP +.B get +Equivalent to the +.B Get +interactive command with no arguments; accepts no arguments. +.TP +.B limit=addr +When the +.B ctl +file is first opened, regular expression context searches in +.B addr +addresses examine the whole file; this message restricts subsequent +searches to the current +.B addr +address. +.TP +.B mark +Cancel +.BR nomark , +returning the window to the usual state wherein each modification to the +body must be undone individually. +.TP +.BI name " name +Set the name of the window to +.IR name . +.TP +.B nomark +Turn off automatic `marking' of changes, so a set of related changes +may be undone in a single +.B Undo +interactive command. +.TP +.B noscroll +Turn off automatic `scrolling' of the window to show text written to the body. +.TP +.B put +Equivalent to the +.B Put +interactive command with no arguments; accepts no arguments. +.TP +.B scroll +Cancel a +.B noscroll +message, returning the window to the default state wherein each write +to the +.B body +file causes the window to `scroll' to display the new text. +.TP +.B show +Guarantee at least some of the selected text is visible on the display. +.RE +.PD +.TP +.B data +is used in conjunction with +.B addr +for random access to the contents of the body. +The file offset is ignored when writing the +.B data +file; instead the location of the data to be read or written is determined by the state of the +.B addr +file. +Text, which must contain only whole characters (no `partial runes'), +written to +.B data +replaces the characters addressed by the +.B addr +file and sets the address to the null string at the end of the written text. +A read from +.B data +returns as many whole characters as the read count will permit starting +at the beginning of the +.B addr +address (the end of the address has no effect) +and sets the address to the null string at the end of the returned +characters. +.TP +.B event +When a window's +.B event +file is open, changes to the window occur as always but the +actions are also reported as +messages to the reader of the file. Also, user actions with buttons 2 and 3 +(other than chorded +.B Cut +and +.BR Paste , +which behave normally) have no immediate effect on the window; +it is expected that the program reading the +.B event +file will interpret them. +The messages have a fixed format: +a character indicating the origin or cause of the action, +a character indicating the type of the action, +four free-format blank-terminated decimal numbers, +optional text, and a newline. +The first and second numbers are the character addresses of the action, +the third is a flag, +and the final is a count of the characters in the optional text, which +may itself contain newlines. +The origin characters are +.B E +for writes to the +.B body +or +.B tag +file, +.B F +for actions through the window's other files, +.B K +for the keyboard, and +.B M +for the mouse. +The type characters are +.B D +for text deleted from the body, +.B d +for text deleted from the tag, +.B I +for text inserted to the body, +.B i +for text inserted to the tag, +.B L +for a button 3 action in the body, +.B l +for a button 3 action in the tag, +.B X +for a button 2 action in the body, and +.B x +for a button 2 action in the tag. +.IP +If the relevant text has less than 256 characters, it is included in the message; +otherwise it is elided, the fourth number is 0, and the program must read +it from the +.B data +file if needed. No text is sent on a +.B D +or +.B d +message. +.IP +For +.BR D , +.BR d , +.BR I , +and +.BR i +the flag is always zero. +For +.BR X +and +.BR x , +the flag is a bitwise OR (reported decimally) of the following: +1 if the text indicated is recognized as an +.I acme +built-in command; +2 if the text indicated is a null string that has a non-null expansion; +if so, another complete message will follow describing the expansion +exactly as if it had been indicated explicitly (its flag will always be 0); +8 if the command has an extra (chorded) argument; if so, +two more complete messages will follow reporting the argument (with +all numbers 0 except the character count) and where it originated, in the form of +a fully-qualified button 3 style address. +.IP +For +.B L +and +.BR l , +the flag is the bitwise OR of the following: +1 if +.I acme +can interpret the action without loading a new file; +2 if a second (post-expansion) message follows, analogous to that with +.B X +messages; +4 if the text is a file or window name (perhaps with address) rather than +plain literal text. +.IP +For messages with the 1 bit on in the flag, +writing the message back to the +.B event +file, but with the flag, count, and text omitted, +will cause the action to be applied to the file exactly as it would +have been if the +.B event +file had not been open. +.TP +.B tag +holds contents of the window tag. It may be read at any byte offset. +Text written to +.B tag +is always appended; the file offset is ignored. +.SH SOURCE +.B /sys/src/cmd/acme +.SH SEE ALSO +.IR rio (1), +.IR acme (1), +.IR cons (3). diff --git a/static/plan9-4e/man4/archfs.4 b/static/plan9-4e/man4/archfs.4 new file mode 100644 index 00000000..0ba744c5 --- /dev/null +++ b/static/plan9-4e/man4/archfs.4 @@ -0,0 +1,46 @@ +.TH ARCHFS 4 +.SH NAME +archfs \- mount mkfs-style archive +.SH SYNOPSIS +.B archfs +[ +.B -abcC +] +[ +.B -m +.I mtpt +] +.I archfile +.SH DESCRIPTION +.I Archfs +mounts at +.I mtpt +(default +.BR /mnt/arch ) +a file system presenting the contents of an +archive in the format produced by +the +.B -a +flag to +.IR mkfs (8). +The +.BR -a , +.BR -b , +.BR -c , +and +.B -C +flags control the flag argument +to the +.B mount +system call +(see +.IR bind (2)) +as in the +.B mount +command +(see +.IR bind (1)). +.SH SOURCE +.B /sys/src/cmd/archfs.c +.SH SEE ALSO +.IR mkfs (8) diff --git a/static/plan9-4e/man4/cdfs.4 b/static/plan9-4e/man4/cdfs.4 new file mode 100644 index 00000000..ad8548a2 --- /dev/null +++ b/static/plan9-4e/man4/cdfs.4 @@ -0,0 +1,172 @@ +.TH CDFS 4 +.SH NAME +cdfs, cddb \- CD reader and writer file system +.SH SYNOPSIS +.B cdfs +[ +.B -d +.I sddev +] +[ +.B -m +.I mtpt +] +.br +.B "grep aux/cddb /mnt/cd/ctl | rc +.SH DESCRIPTION +.I Cdfs +serves a one and a half level directory +mounted at +.I mtpt +(default +.BR /mnt/cd ) +that provides access to the tracks +on CDs placed in the CD reader or writer +named by +.I sddev +(default +.BR /dev/sdD0 , +see +.IR sd (3)). +.PP +The top level directory contains one file +per CD track. +The files are named +.IR cNNN , +where +.I c +is a type character +.RB ( a +for audio tracks +and +.B d +for data tracks) +and +.I NNN +is the track number. +.PP +If the device is capable of writing CDs +and contains a writable CD, the top level +directory also contains two empty +directories +.B wa +and +.BR wd . +Files created in these directories +appear in the top level directory +as new audio or data tracks, regardless of name. +.PP +At any time, any number of tracks +may be open for reading or a single track +may be open for writing. +Writing a CD track is a real-time operation: +the CD writer must be kept saturated with +new data to avoid buffer underruns. +To ensure this, copying from a file system +stored on local disk is recommended. +.PP +To fixate a CD (close a writable CD by writing +its permanent table of contents), simply +remove the +.B wa +or +.B wd +directory. +The directory removed selects whether +the CD is fixated as an audio or data CD; +since each track carries its own type information, +very few readers care which fixation type was used. +.PP +The top level directory +also contains a +.B ctl +file, into which control messages +may be echoed. +The current control messages are: +.TF "\fLquickblank " +.TP +.B blank +Blank the entire rewritable CD in the drive. +.TP +.B quickblank +Blank only the table of contents on the rewritable +CD in the drive. +.TP +.B eject +Eject the CD in the drive. +.TP +.B ingest +Ingest a CD into the drive. +.TP +.B speed \fIkpbs\fR +Set the reading and writing speed to use. +Drives may round down the speed to one they support. +To set reading and writing speeds separately, +prefix the speeds with +.B read +or +.BR write , +as in +.B speed +.B write +.B 8192 +or +.B speed +.B read +.B 16384 +.B write +.BR 8192. +Note that most drives reset the reading and writing speed +each time a new CD is inserted. +.PD +.PP +Reading the +.B ctl +file yields information about the drive. +If the drive contains an audio CD, the first line +will be an +.B aux/cddb +command that can be run to query +an internet CD database +to get a table of contents. +Subsequent lines contain the current and maximum +reading and writing speeds. +.PD +.PP +Only MMC-compliant CD readers and writers +are supported, but it would be easy to add +support for early CD writers if desired. +.SH EXAMPLE +Copy the audio tracks from a CD: +.IP +.EX +cdfs -d /dev/sd05 +mkdir /tmp/songs +cp /mnt/cd/a* /tmp/songs +.EE +.PP +Copy the tracks onto a blank CD inserted in the drive, +and then fixate the disk as an audio CD. +.IP +.EX +cp /tmp/songs/* /mnt/cd/wa +rm /mnt/cd/wa +.EE +.PP +Cut your own 9660 CD-ROM, without +spooling the CD image to a temporary file. +.IP +.EX +disk/mk9660 -9cj -n notice cdproto >/mnt/cd/wd/foo +rm /mnt/cd/wd +.EE +.SH SOURCE +.B /sys/src/cmd/cdfs +.SH SEE ALSO +.IR sd (3), +.I 9660srv +(in +.IR dossrv (4)), +.IR mk9660 (8) +.SH BUGS +There should be support for DVDs. diff --git a/static/plan9-4e/man4/cfs.4 b/static/plan9-4e/man4/cfs.4 new file mode 100644 index 00000000..e7f6d378 --- /dev/null +++ b/static/plan9-4e/man4/cfs.4 @@ -0,0 +1,95 @@ +.TH CFS 4 +.SH NAME +cfs \- cache file system +.SH SYNOPSIS +.B cfs +.B -s +.RB [ -rdS ] +.RB [ -f +.IR partition ] +.PP +.B cfs +.B -a +.I netaddr +.RB [ -rdS ] +.RB [ -f +.IR partition ] +.RI [ mtpt ] +.SH DESCRIPTION +.I Cfs +is a user-level file server that caches information about remote +files onto a local disk. +It is normally started by the kernel at boot time, though users may start +it manually. +.I Cfs +is interposed between the kernel and a network connection to a +remote file server to improve the +efficiency of access across slow network connections such as modem +lines. +On each open of a file +.I cfs +checks the consistency of cached information and discards any old +information for that file. +.PP +.I Cfs +mounts onto +.I mtpt +(default +.BR / ) +after connecting to the file server. +.PP +The options are: +.TP +.B s +the connection to the remote file server is on file +descriptors 0 and 1. +.TP +.BI "a " netaddr +dial the destination +.I netaddr +to connect to a remote file server. +.TP +.B r +reformat the cache disk partition. +.TP +.B d +turn on debugging. +.TP +.B S +turn on statistics gathering. A file called +.B cfsctl +at the root of the caching file system can be read to get +statistics concerning number of calls/bytes on client and server +sides and latencies. +.TP +.BI "f " partition +use file +.I partition +as the cache disk partition. +.PP +All 9P messages except +.BR read , +.BR clone , +and +.B walk +(see +.IR intro (5)) +are passed through +.I cfs +unchanged to the remote server. +A +.B clone +followed immediately by a +.B walk +is converted into a +.BR clwalk . +If possible, a +.B read +is satisfied by cached data. +Otherwise, the file server is queried for any missing data. +.SH FILES +.TP +.B /dev/sdC0/cache +Default file used for storing cached data. +.SH SOURCE +.B /sys/src/cmd/cfs diff --git a/static/plan9-4e/man4/consolefs.4 b/static/plan9-4e/man4/consolefs.4 new file mode 100644 index 00000000..ea246bca --- /dev/null +++ b/static/plan9-4e/man4/consolefs.4 @@ -0,0 +1,216 @@ +.TH CONSOLEFS 4 +.SH NAME +consolefs, C, clog \- file system for console access +.SH SYNOPSIS +.B aux/consolefs +[ +.B -m +.I mntpt +] [ +.B -c +.I consoledb +] +.PP +.B C +.I system +.PP +.B aux/clog +console log +.I system +.SH DESCRIPTION +To ease administration of multiple machines one might attach +many serial console lines to a single computer. +.I Consolefs +is a file system that lets multiple users simultaneously access +these console lines. +The consoles and permissions to access them are defined in the +file +.I consoledb +(default +.BR /lib/ndb/consoledb ). +The format of +.I consoledb +is the same as that of other +.B /lib/ndb +files, +.IR ndb (6). +Consoles are defined by entries of the form: +.PP +.EX + console=dirty dev=/dev/eia205 + uid=bignose + gid=support + speed=56200 + cronly= +.EE +.PP +Each +.IR console / dev +pair represents the name of a console and the serial line device +associated with it. +.I Consolefs +presents a single level directory with two files +per console: +.I console +and +.IB console ctl\f1. +Writes of +.I console +are equivalent to writes of +.I dev +and reads and writes of +.IB console ctl +are equivalent to reads and writes of +.IB dev ctl\f1. +.I Consolefs +broadcasts anything it reads from +.I dev +to all readers of +.IR console . +Therefore, many users can +.IR con (1) +to a +.IR console , +see all output, and enter commands. +.PP +The +.I cronly= +attribute causes newlines typed by the user to be sent to +the console as returns. +The +.I speed=x +attribute/value pair specifies a bit rate for the +console. The default is 9600 baud. +.PP +Access to the console is controlled by the +.I uid +and +.I gid +attributes/value pairs. +The uid values are user account names. +The gid values are the names of groups defined in +.I consolefs +by entries of the form: +.PP +.EX + group=support + uid=bob + uid=carol + uid=ted + uid=alice +.EE +.PP +Groups are used to avoid excessive typing. Using +.I gid=x +is equivalent to including a +.I uid=y +for each user +.I y +that is a member of +.IR x . +.PP +To keep users from inadvertently interfering with one another, +notification is broadcast to all readers whenever a user +opens or closes +.IR name . +For example, if user +.B boris +opens a console that users +.B vlad +and +.B barney +have already opened, all will read the message: +.PP +.EX + [+boris, vlad, barney] +.EE +.PP +If +.B vlad +then closes, +.B boris +and +.B barney +will read: +.PP +.EX + [-vlad, boris, barney] +.EE +.PP +.I Consolefs +posts the client end of its 9P channel in +.BR /srv/consolefs +and mounts this locally in +.I mntpt +(default +.BR /mnt/consoles ); +remote clients must +.B mount +(see +.IR bind (1)) +this file to see the consoles. +.PP +The +.IR rc (1) +script +.B C +automates this procedure. +It uses +.IR import (4) +to connect to +.B /mnt/consoles +on the machine connected to all the consoles, then uses +.IR con (1) +to connect to the console of the machine +.IR system. +The script must be edited at installation +by the local administration to identify the +system that holds +.BR /mnt/consoles . +.PP +.I Aux/clog +opens the file +.I console +and writes every line read from it, prefixed +by the ASCII time to the file +.IR log . +.PP +An example of 2 consoles complete with console logging is: +.IP +.EX +% aux/consolefs +% ls -p /mnt/consoles +bootes +bootesctl +fornax +fornaxctl +% clog /mnt/consoles/fornax /sys/log/fornax & +% clog /mnt/consoles/bootes /sys/log/bootes & +.EE +.SH FILES +.TF /lib/ndb/consoledb +.TP +.B /srv/consoles +Client end of pipe to server. +.TP +.B /mnt/consoles +Default mount point. +.TP +.B /lib/ndb/consoledb +Default user database. +.SH SOURCE +.B /sys/src/cmd/aux/consolefs.c +.br +.B /rc/bin/C +.br +.B /sys/src/cmd/aux/clog.c +.SH BUGS +.PP +Changing the gid's or uid's while +.I consoelfs +is running +is detected by +.IR consolefs . +However, to add new consoles +one must restart +.IR consolefs . diff --git a/static/plan9-4e/man4/dossrv.4 b/static/plan9-4e/man4/dossrv.4 new file mode 100644 index 00000000..40749a08 --- /dev/null +++ b/static/plan9-4e/man4/dossrv.4 @@ -0,0 +1,217 @@ +.TH DOSSRV 4 +.SH NAME +dossrv, 9660srv, a:, b:, c:, d:, 9fat:, dosmnt, eject \- DOS and ISO9660 file systems +.SH SYNOPSIS +.B dossrv +[ +.B -v +] [ +.B -r +] [ +.B -s +] [ +.B -f +.I file +] [ +.I service +] +.PP +.B 9660srv +[ +.B -9J +] [ +.B -v +] [ +.B -s +] [ +.B -f +.I file +] [ +.I service +] +.PP +.B a: +.PP +.B b: +.PP +.B c: +.PP +.B 9fat: +.PP +.B dosmnt +.I n +.I mtpt +.PP +.B eject +[ +.I n +] +.SH DESCRIPTION +.I Dossrv +is a file server that interprets DOS file systems. +A single instance of +.I dossrv +can provide access to multiple DOS disks simultaneously. +.PP +.I Dossrv +posts a file descriptor named +.I service +(default +.BR dos ) +in the +.B /srv +directory. +To access the DOS file system on a device, use +.B mount +with the +.I spec +argument +(see +.IR bind (1)) +the name of the file holding raw DOS file system, typically the disk. +If +.I spec +is undefined in the +.BR mount , +.I dossrv +will use +.I file +as the default name for the device holding the DOS system. +.PP +Normally +.I dossrv +creates a pipe to act as the communications channel between +itself and its clients. +The +.B -s +flag instructs +.I dossrv +to use its standard input and output instead. +The kernels use this option if they are booting from a DOS disk. +This flag also prevents the creation of an explicit service file in +.BR /srv . +.PP +The +.B -v +flag causes verbose output for debugging, while +the +.B -r +flag makes the file system read-only. +.PP +The shell script +.I a: +contains +.IP +.EX +unmount /n/a: >[2] /dev/null +mount -c /srv/dos /n/a: /dev/fd0disk +.EE +.LP +and is therefore a shorthand for mounting a floppy disk in drive A. +The scripts +.I b: +and +.I dosmnt +are similar, +mounting the second floppy disk +and the +.IR n th +non-floppy DOS partition, +respectively. +.I C: +and +.I d: +call +.I dosmnt +in an attempt to name the drives in +the same order that Microsoft operating systems do. +.I 9fat: +provides access to the FAT component of the Plan 9 partition (see +.IR prep (8)). +.PP +The file attribute flags used by the DOS file system +do not map directly to those used by Plan 9. +Since there is no concept of user or group, +permission changes via +.B wstat +(see +.IR stat (2)) +will fail unless the same (read, write, execute) permissions +are specified for user, group, and other. +For example, removing write permission in Plan 9 +corresponds to setting the read-only +attribute in the DOS file system. +Most of the other DOS attributes +are not accessible. +.PP +Setting the exclusive use flag (DMEXCL) +in Plan 9 corresponds to setting the +system use attribute in the DOS file system. +Such files are not actually restricted to exclusive use, +but do merit special treatment that +helps in the creation of boot disks: +when +.I dossrv +allocates a new block for such a file +(caused, say, by a write that fills the file's +last allocated block), it succeeds only if it can +arrange for the file to be stored +contiguously on disk. +.PP +Since other operating systems do not +guarantee that system files are laid +out contiguously, the DMAPPEND mode +bit is set in file stat information +only when the file is currently contiguous. +Attempts to set the DMAPPEND mode bit +explicitly will cause +.I dossrv +to try to make the file contiguous, +succeeding only if this is possible. +.PP +.I 9660srv +is similar to +.I dossrv +in specification, except that it interprets ISO9660 CD-ROM +file systems instead of DOS file systems. +Some CDs contain multiple directory trees describing +the same set of files. +.IR 9660srv 's +first choice in such a case is a standard ISO9660 tree +with Plan 9 system use fields; +the second choice is a Microsoft ``Joliet'' tree, which +allows long file names and Unicode characters; +the third choice is a standard ISO9660 or High Sierra tree. +The +.B -9 +flag causes +.I 9660srv +to ignore the Plan 9 system use fields, +while the +.B -J +flag causes it to +ignore the Joliet tree. +.PP +If the floppy drive has an ejection motor, +.I eject +will spit out the floppy from drive +.IR n , +default 0. +.SH EXAMPLE +Mount a floppy disk with a DOS file system on it. +.IP +.EX +a: +.EE +.SH "SEE ALSO" +.IR kfs (4) +.SH SOURCE +.B /sys/src/cmd/dossrv +.br +.B /sys/src/cmd/9660srv +.br +.B /rc/bin/eject +.SH BUGS +The overloading of the semantics of +the DMEXCL and DMAPPEND +bits can be confusing. diff --git a/static/plan9-4e/man4/execnet.4 b/static/plan9-4e/man4/execnet.4 new file mode 100644 index 00000000..9375a14b --- /dev/null +++ b/static/plan9-4e/man4/execnet.4 @@ -0,0 +1,67 @@ +.TH EXECNET 4 +.SH NAME +execnet \- network interface to program execution +.SH SYNOPSIS +.B execnet +[ +.B -n +.I name +] +[ +.B netdir +] +.SH DESCRIPTION +.I Execnet +presents a network protocol directory +(see, for example, +.IR ip (3)) +called +.IB netdir / name +(default +.BR /net/exec ). +.PP +Once the protocol directory exists, dialing +(see +.IR dial (2)) +strings of +the form +.IB name ! cmd +will connect to a newly executed instance of +.IR cmd . +.SH EXAMPLE +.I Execnet +can be used to connect to instances of +.IR u9fs (4) +running on other hosts: +.EX + g% execnet + g% srv -m 'exec!ssh ny start-u9fs' ny /n/ny +.EE +This example assumes that the remote command +.B start-u9fs +executed on +.B ny +will start +.I u9fs +appropriately. +For example, it might be: +.EX + ny% cat start-u9fs + #!/bin/sh + + u9fs -na none -u $USER -l $HOME/tmp/u9fs.log + ny% +.EE +See the +.IR u9fs (4) +man page for more information. +.SH SOURCE +.B /sys/src/cmd/execnet +.SH "SEE ALSO +.IR dial (2), +.IR ip (3), +.IR u9fs (4) +.SH BUGS +Almost certainly: +.IR execnet +has only been tested as in the example shown. diff --git a/static/plan9-4e/man4/exportfs.4 b/static/plan9-4e/man4/exportfs.4 new file mode 100644 index 00000000..9f867d85 --- /dev/null +++ b/static/plan9-4e/man4/exportfs.4 @@ -0,0 +1,205 @@ +.TH EXPORTFS 4 +.SH NAME +exportfs, srvfs \- network file server plumbing +.SH SYNOPSIS +.B exportfs +[ +.B -ads +] [ +.B -f +.I dbgfile +] [ +.B -m +.I msize +] [ +.B -r +.I root +] [ +.B -S +.I service +] [ +.B -A announce +] +.PP +.B srvfs +[ +.B -d +] +[ +.B -e +.I "'enc auth'" +] +[ +.B -p +.I filter +] +.I name +.I path +.SH DESCRIPTION +.I Exportfs +is a user level file server that allows Plan 9 compute servers, rather +than file servers, to export portions of a name space across networks. +The service is started either by the +.IR cpu (1) +command or by a network listener process. An initial protocol +establishes a root directory for the exported name space. +The +connection to +.I exportfs +is then mounted, typically on +.BR /mnt/term . +.I Exportfs +then acts as a relay file server: operations in the imported file +tree are executed on the remote server and the results returned. This +gives the appearance of exporting a name space from a remote machine +into a local file tree. +.PP +The +.B -r +option bypasses the initial protocol, instead immediately +serving the name space rooted at +.IR root . +The +.B -s +option is equivalent to +.B -r +.BR / , +but predates +.B -r +and remains for compatibility. +.PP +The +.B -S +option also bypasses the initial protocol but +serves the result of mounting +.IR service . +A separate mount is used for each +.IR attach (5) +message, +to correctly handle servers in which each mount +corresponds to a different client +.IR e.g. , ( +.IR rio (4)). +.PP +The +.B -m +option sets the maximum message size that +exportfs should offer to send (see +.IR version (5)); +this helps tunneled +9P connections to avoid unnecessary fragmentation. +.PP +The +.B -a +option instructs +.I exportfs +to authenticate the user, usually because it is +being invoked from a remote machine. +.PP +The +.B -d +option instructs +.I exportfs +to log all 9P traffic to +.I dbgfile +(default +.BR /tmp/exportdb ). +.PP +The +.B -e +option specifies the encryption and authentication algorithms to use for +encrypting the wire traffic. The defaults are +.B rc4_256 +and +.BR sha1 . +The full list of supported protocols in in +.IR ssl (3). +.PP +The +.B cpu +command uses +.I exportfs +to serve device files in the terminal. The +.IR import (4) +command calls +.I exportfs +on a remote machine, permitting users to access arbitrary pieces of +name space on other systems. +Because the kernel disallows reads and writes on mounted pipes +(as might be found in +.BR /srv ), +.I exportfs +calls itself (with appropriate +.B -m +and +.B -S +options) to simulate reads and writes on such files. +.PP +.I Srvfs +invokes +.I exportprog +(default +.BR /bin/exportfs ) +to create a mountable file system from a name space +and posts it at +.BI /srv/ name , +which is created with mode +.I perm +(default 0600). +By default, the name space is the directory tree rooted at +.IR path . +If the +.B -S +option is given, the name space is obtained by +mounting +.B path +(typically a file in +.BR /srv ). +If the +.B -d +option is given, +.I srvfs +passes it to +.I exportprog +to enable debugging. +.PP +The +.B -A +filter specifies an announce string when exportfs is used in combination +with aan. The announce string identifies the network and network +protocol to use for aan connections. +.SH EXAMPLES +Use +.I srvfs +to enable mounting of an FTP file system (see +.IR ftpfs (4)) +in several windows, +or to publish a +.B /proc +(see +.IR proc (3)) +with a broken process so a remote person may debug the program: +.IP +.EX +srvfs ftp /n/ftp +srvfs broke /mnt/term/proc +.EE +.LP +Use +.I srvfs +to obtain a copy of a service to be manipulated directly +by a user program like +.IR nfsserver (8): +.IP +.EX +srvfs nfs.boot /srv/boot +aux/nfsserver -f /srv/nfs.boot +.EE +.SH SOURCE +.B /sys/src/cmd/exportfs +.br +.B /sys/src/cmd/srvfs.c +.SH SEE ALSO +.IR aan (1), +.IR import (4), +.IR exportfs (4) diff --git a/static/plan9-4e/man4/factotum.4 b/static/plan9-4e/man4/factotum.4 new file mode 100644 index 00000000..38d8dfc4 --- /dev/null +++ b/static/plan9-4e/man4/factotum.4 @@ -0,0 +1,679 @@ +.TH FACTOTUM 4 +.SH NAME +factotum, fgui, secretpem\- authentication agent and its graphics interface +.SH SYNOPSIS +.B auth/factotum +[ +.B -DdkSun +] [ +.B -a asaddr +] [ +.B -s +.I srvname +] [ +.B -m +.I mtpt +] +.PP +.B auth/factotum +.B -g +.IB attribute = value +.B ... +.IB attribute ? +.B ... +.PP +.B auth/fgui +.PP +.B auth/secretpem +.I key.pem +.SH DESCRIPTION +.I Factotum +is a user-level file system that +acts as the authentication agent for a user. +It does so by managing a set of +.IR keys . +A key is a collection of information used to authenticate a particular action. +Stored as a list of +.IB attribute = value +pairs, a key typically contains a user, an authentication domain, a protocol, and +some secret data. +.PP +.I Factotum +presents a two level directory. The first +level contains a single directory +.BR factotum , +which in turn contains: +.TF needkey +.TP +.B rpc +each open represents a new private channel to +.I factotum +.TP +.B proto +when read lists the protocols available +.TP +.B confirm +for confiming the use of key +.TP +.B needkey +allows external programs to control the addition of new keys +.TP +.B log +a log of actions +.TP +.B ctl +for maintaining keys; when read, it returns a list of keys (without the secret data) +.PD +.PP +In any authentication, the caller typically acts as a client +and the callee as a server. The server determines +the authentication domain, sometimes after a negotiation with +the client. Authentication always requires the client to +prove its identity to the server. Under some protocols, the +authentication is mutual. +Proof is accomplished using secret information kept by factotum +in conjunction with a cryptographic protocol. +.PP +.I Factotum +can act in the role of client for any process possessing the +same user id as it. For select protocols such as +.B p9sk1 +it can also act as a client for other processes provided +its user id may speak for the other process' user id (see +.IR authsrv (6)). +.I Factotum +can act in the role of server for any process. +.PP +.IR Factotum 's +structure is independent of +any particular authentication protocol. +.I Factotum +supports the following protocols: +.TF sshrsa +.TP +.B p9any +a metaprotocol used to negotiate which actual protocol to use. +.TP +.B p9sk1 +a Plan 9 shared key protocol described in +.IR authsrv (6)'s +``File Service'' section. +.TP +.B p9sk2 +a variant of +.B p9sk1 +described in +.IR authsrv (6)'s +``Remote Execution'' section. +.TP +.B p9cr +a Plan 9 protocol that can use either +.B p9sk1 +keys or SecureID tokens. +.TP +.B apop +the challenge/response protocol used by POP3 mail servers. +.TP +.B cram +the challenge/response protocol also used by POP3 mail servers. +.TP +.B chap +the challenge/response protocols used by PPP and PPTP. +.TP +.B mschap +a proprietary Microsoft protocol also used by PPP and PPTP. +.TP +.B sshrsa +an public key protocol used by ssh. +.TP +.B pass +passwords in the clear. +.TP +.B vnc +.IR vnc (1)'s +challenge/response. +.PD +.PP +The options are: +.TP +.B \-a +supplies the address of the authentication server to use. +Without this option, it will attempt to find an authentication server by +querying the connection server, the file +.BR <mtpt>/ndb , +and finally the network database in +.BR /lib/ndb . +.TP +.B \-m +specifies the mount point to use, by default +.BR /mnt . +.TP +.B \-s +specifies the service name to use. +Without this option, +.I factotum +does not create a service file in +.BR /srv . +.TP +.B \-D +turns on 9P tracing, written to standard error. +.TP +.B \-d +turns on debugging, written to standard error. +.TP +.B \-g +causes the agent to prompt for the key, write it +to the +.B ctl +file, and exit. +The agent will prompt for values for any of the +attributes ending with a question mark +.RB ( ? ) +and will append all the supplied +.I attribute = value +pairs. See the section on key templates below. +.TP +.B \-n +don't look for a secstore. +.TP +.B \-S +indicates that the agent is running on a +cpu server. On starting, it will attempt to get a +.B 9psk1 +key from NVRAM using +.B readnvram +(see +.IR authsrv (2)), +prompting for anything it needs. +It will never subsequently prompt for a +key that it doesn't have. +This option is typically used by +the kernel at boot time. +.TP +.B \-k +causes the NVRAM to be written. +It is only valid with the +.B \-S +option. +This option is typically used by +the kernel at boot time. +.TP +.B \-u +causes the agent to prompt for user +id and writes it to +.BR /dev/hostowner . +It is mutually exclusive with +.B \-k +and +.BR \-S . +This option is typically used by +the kernel at boot time. +.PD +.PP +.I Fgui +is a graphic user interface for confirming key usage and +entering new keys. It hides the window in which it starts +and waits reading requests from +.B confirm +and +.BR needkey . +For each requests, it unhides itself and waits for +user input. +See the sections on key confirmation and key prompting below. +.SS "Key Tuples +.PP +A +.I "key tuple +is a space delimited list of +.IB attribute = value +pairs. An attribute whose name begins with an exclamation point +.RB ( ! ) +does not appear when reading the +.B ctl +file. +The required attributes depend on the authentication protocol. +.PP +.BR P9sk1 , +.BR p9sk2 , +and +.BR p9cr +all require a key with +.BR proto = p9sk1 , +a +.B dom +attribute identifying the authentication domain, a +.B user +name valid in that domain, and either a +.B !password +or +.B !hex +attribute specifying the password or hexadecimal secret +to be used. Here is an example: +.PP +.EX + proto=p9sk1 dom=avayalabs.com user=presotto !password=lucent +.EE +.PP +.BR Apop , +.BR cram , +.BR chap , +.BR mschap , +and +.B vnc +require a key with a +.B proto +attribute whose value matches the protocol, +in addition to +.BR dom , +.BR user , +and +.B !password +attributes; +e.g. +.PP +.EX + proto=apop dom=mit.edu user=rsc !password=nerdsRus +.EE +.PP +.B Pass +requires a key with +.B proto=pass +in addition to +.B user +and +.B !password +attributes; e.g. +.PP +.EX + proto=pass user=tb !password=does.it.matter +.EE +.PP +.B Sshrsa +requires a key with +.B proto=sshrsa +in addition to all the hex attributes defining an RSA key: +.BR ek , +.BR n , +.BR !p , +.BR !q , +.BR !kp , +.BR !kq , +.BR !c2 , +and +.BR !dk . +.PP +All keys can have additional attibutes that act either as comments +or as selectors to distinguish them in the +.IR auth (2) +library calls. +.PP +Any key may have a +.B role +attribute for restricting how it can be used. +If this attribute is missing, the key can be used in any role. +The possible values are: +.TP +.B client +for authenticating outbound calls +.TP +.B server +for authenticating inbound calls +.TP +.B speaksfor +for authenticating processes whose +user id does not match +.IR factotum 's. +.PD +.PP +Whenever +.I factotum +runs as a server, it must have a +.B p9sk1 +key in order to communicate with the authentication +server for validating passwords and challenge/responses of +other users. +.SS "Key Templates +Key templates are used by routines that interface to +.I factotum +such as +.B auth_proxy +and +.B auth_challenge +(see +.IR auth (2)) +to specify which key and protocol to use for an authentication. +Like a key tuple, a key template is also a list of +.IB attribute = value +pairs. +It must specify at least the protocol and enough +other attributes to uniquely identify a key, or set of keys, to use. +The keys chosen are those that match all the attributes specified +in the template. The possible attribute/value formats are: +.TP 1i +.IB attr = val +The attribute +.I attr +must exist in the key and its value must exactly +match +.I val +.TP 1i +.IB attr ? +The attribute +.I attr +must exist in the key but its value doesn't matter. +.TP 1i +.I attr +The attribute +.I attr +must exist in the key with a null value +.PD +.PP +Key templates are also used by factotum to request a key either via +an RPC error or via the +.B needkey +interface. +The possible attribute/value formats are: +.TP 1i +.IB attr = val +This pair must remain unchanged +.TP 1i +.IB attr ? +This attribute needs a value +.TP 1i +.I attr +The pair must remain unchanged +.PD +.SS "Control and Key Management +.PP +A number of messages can be written to the control file. +The mesages are: +.TP +.B "key \fIattribute-value-list\fP +add a new key. This will replace any old key whose +public, i.e. non ! attributes, match. +.TP +.B "delkey \fIattribute-value-list\fP +delete a key whose attributes match those given. +.TP +.B debug +toggle debugging on and off, i.e., the debugging also +turned on by the +.B \-d +option. +.PP +By default when factotum starts it looks for a +.IR secstore (1) +account on $auth for the user and, if one exists, +prompts for a secstore password in order to fetch +the file +.IR factotum , +which should contain control file commands. +An example would be +.EX + key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229 + key proto=sshrsa size=1024 ek=3B !dk=... +.EE +where the first line sets a password for +challenge / response authentication, strong against dictionary +attack by being a long random string, and the second line +sets a public / private keypair for ssh authentication, +generated by +.B ssh_genkey +(see +.IR ssh (1)). +.PD +.SS "Confirming key use +.PP +The +.B confirm +file provides a connection from +.I factotum +to a confirmation server, normally the program +.IR auth/fgui . +Whenever a key with the +.B confirm +attribute is used, +.I factotum +requires confirmation of its use. If no process has +.B confirm +opened, use of the key will be denied. +However, if the file is opened a request can be read from it +with the following format: +.PP +.B confirm +.BI tag= tagno +.I "<key template> +.PP +The reply, written back to +.BR confirm , +consists of string: +.PP +.BI tag= tagno +.BI answer= xxx +.PP +If +.I xxx +is the string +.B yes +then the use is confirmed and the authentication will proceed. +Otherwise, it fails. +.PP +.B Confirm +is exclusive open and can only be opened by a process with +the same user id as +.IR factotum . +.SS "Prompting for keys +.PP +The +.B needkey +file provides a connection from +.I factotum +to a key server, normally the program +.IR auth/fgui . +Whenever +.I factotum +needs a new key, it first checks to see if +.B needkey +is opened. If it isn't, it returns a error to its client. +If the file is opened a request can be read from it +with the following format: +.PP +.B needkey +.BI tag= tagno +.I "<key template> +.PP +It is up to the reader to then query the user for any missing fields, +write the key tuple into the +.B ctl +file, and then reply by writing into the +.B needkey +file the string: +.PP +.BI tag= tagno +.PP +.B Needkey +is exclusive open and can only be opened by a process with +the same user id as +.IR factotum . +.SS "The RPC Protocol +Authentication is performed by +.IP 1) +opening +.BR rpc +.IP 2) +setting up the protocol and key to be used (see the +.B start +RPC below), +.IP 3) +shuttling messages back and forth between +.IR factotum +and the other party (see the +.B read +and +.B write +RPC's) until done +.IP 4) +if successful, reading back an +.I AuthInfo +structure (see +.IR authsrv (2)). +.PP +The RPC protocol is normally embodied by one of the +routines in +.IR auth (2). +We describe it here should anyone want to extend +the library. +.PP +An RPC consists of writing a request message to +.B rpc +followed by reading a reply message back. +RPC's are strictly ordered; requests and replies of +different RPC's cannot be interleaved. +Messages consist of of a verb, a singe space, and data. +The data format depends on the verb. The request verbs are: +.TP +.B "start \fIattribute-value-list\fP +start a new authentication. +.I Attribute-value-pair-list +must include a +.B proto +attribute, a +.B role +attribute with value +.B client +or +.BR server , +and enough other attibutes to uniquely identify a key to use. +A +.B start +RPC is required before any others. The possible replies are: +.RS +.TP +.B ok +start succeeded. +.TP +.B "error \fIstring\fP +where +.I string +is the reason. +.RE +.PD +.TP +.B read +get data from +.I factotum +to send to the other party. The possible replies are: +.RS +.TP +.B ok +read succeeded, this is zero length message. +.TP +.B "ok \fIdata\fP +read succeeded, the data follows the space and is +unformatted. +.TP +.B "done +authentication has succeeded, no further RPC's are +necessary +.TP +.B "done haveai +authentication has succeeded, an +.B AuthInfo +structure (see +.IR auth (2)) +can be retrieved with an +.B authinfo +RPC +.TP +.B "phase \fIstring\fP +its not your turn to read, get some data from +the other party and return it with a write RPC. +.TP +.B "error \fIstring\fP +authentication failed, +.I string +is the reason. +.TP +.B "protocol not started +a +.B start +RPC needs to be preceed reads and writes +.TP +.B "needkey \fIattribute-value-list\fP +a key matching the argument is needed. This argument +may be passed as an argument to +.I factotum +.B -g +in order to prompt for a key. After that, the +authentication may proceed, i.e., the read restarted. +.PD +.RE +.TP +.B "write \fIdata\fP +send data from the other party to +.IR factotum . +The possible replies are: +.RS +.TP +.B "ok +the write succeeded +.TP +.B "needkey \fIattribute-value-list\fP +see above +.TP +.B "toosmall \fIn\fP +the write is too short, get more data from the +other party and retry the write. +.I n +specifies the maximun total number of bytes. +.TP +.B "phase \fIstring\fP +its not your turn to write, get some data from +.I factotum +first. +.TP +.B "done +see above +.TP +.B "done haveai +see above +.RE +.TP +.B authinfo +retrieve the AuthInfo structure. +The possible replies are: +.RS +.TP +.B "ok \fIdata\fP +.I data +is a marshaled form of the AuthInfo structure. +.TP +.B "error \fIstring\fP +where +.I string +is the reason for the error. +.PD +.RE +.TP +.B attr +retrieve the attributes used in the +.B start +RPC. +The possible replies are: +.RS +.TP +.B "ok \fIattribute-value-list\fP +.TP +.B "error \fIstring\fP +where +.I string +is the reason for the error. +.PD +.RE +.PP +.I Secretpem +copies a PEM-format RSA private key onto standard output in sshrsa key syntax, +suitable for sending to +.IR /mnt/factotum/ctl . +.SH SOURCE +.B /sys/src/cmd/auth/factotum/ diff --git a/static/plan9-4e/man4/fs.4 b/static/plan9-4e/man4/fs.4 new file mode 100644 index 00000000..20a60653 --- /dev/null +++ b/static/plan9-4e/man4/fs.4 @@ -0,0 +1,148 @@ +.TH FS 4 +.SH NAME +fs \- file server, dump +.SH SYNOPSIS +.I none +.SH DESCRIPTION +The file server is the main file system for +Plan 9. +It is a stand-alone system that runs on +a separate computer. +It serves the Plan 9 protocol via the IL/IP +protocols on Ethernets. +The name of the main file server at Murray Hill is +.BR emelie . +.PP +The file server normally requires all users except +.L none +to provide authentication tickets on each +.IR attach (5). +This can be disabled using the +.B noauth +configuration command (see +.IR fsconfig (8)). +.PP +The group numbered 9999, normally called +.BR noworld , +is special +on the file server. Any user belonging to that group has +attenuated access privileges. Specifically, when checking such +a user's access to files, the file's permission bits are first ANDed +with 0770 for normal files or 0771 for directories. The effect is +to deny world access permissions to +.B noworld +users, except +when walking directories. +.PP +The user +.B none +is always allowed to attach to +.B emelie +without authentication but has minimal permissions. +.PP +.B Emelie +maintains three file systems +on a combination of disks and +write-once-read-many (WORM) magneto-optical disks. +.TP +.B other +is a simple disk-based file system similar to +.IR kfs (4) . +.TP +.B main +is a worm-based file system with a disk-based +look-aside cache. +The disk cache holds +modified worm blocks +to overcome the write-once property of the worm. +The cache also holds recently accessed +non-modified blocks to +speed up the effective access time of the worm. +Occasionally +(usually daily at 5AM) the modified blocks in the +disk cache are +.IR dumped . +At this time, +traffic to the file system is halted and the +modified blocks are relabeled to the unwritten +portion of the worm. +After the dump, +the file system traffic is continued and +the relabeled blocks are copied to the worm by +a background process. +.TP +.B dump +Each time the main file system is dumped, +its root is appended to a subdirectory of the dump file system. +Since the dump file system is not mirrored with a disk +cache, +it is read-only. +The name of the newly added root is created from the date +of the dump: +.BI / yyyy / mmdds\f1. +Here +.I yyyy +is the full year, +.I mm +is the month number, +.I dd +is the day number and +.I s +is a sequence number if more than +one dump is done in a day. +For the first dump, +.I s +is null. +For the subsequent dumps +.I s +is 1, 2, 3, etc. +.sp +The root of the main file system +that is frozen on the first dump +of March 1, 1992 +will be named +.B /1992/0301/ +in the dump file system. +.SH EXAMPLES +Place the root of the +.B dump +file system on +.B /n/dump +and show the modified times of the MIPS C compiler +over all dumps in February, 1992: +.IP +.EX +9fs dump +ls -l /n/dump/1992/02??/mips/bin/vc +.EE +.PP +To get only one line of output for each version of the compiler: +.IP +.EX +ls -lp /n/dump/1992/02??/mips/bin/vc | uniq +.EE +.PP +Make the +.B other +file system available in directory +.BR /n/emelieother : +.IP +.EX +mount -c /srv/boot /n/emelieother other +.EE +.SH SOURCE +.B /sys/src/fs +.SH SEE ALSO +.IR yesterday (1), +.IR srv (4), +.IR fs (8) +.br +Sean Quinlan, +``A Cached WORM File System'', +.I +Software \- Practice and Experience, +December, 1991 +.SH BUGS +For the moment, the file server serves both the old (third edition) and new (fourth +edition) versions of 9P, deciding which to serve by sniffing the first packet on each +connection. diff --git a/static/plan9-4e/man4/ftpfs.4 b/static/plan9-4e/man4/ftpfs.4 new file mode 100644 index 00000000..5486746f --- /dev/null +++ b/static/plan9-4e/man4/ftpfs.4 @@ -0,0 +1,173 @@ +.TH FTPFS 4 +.SH NAME +ftpfs \- file transfer protocol (FTP) file system +.SH SYNOPSIS +.B ftpfs +[ +.B -/dqn +] +[ +.B -m +.I mountpoint +] +[ +.B -a +.I password +] +[ +.B -e +.I ext +] +[ +.B -o +.I os +] +[ +.B -r +remoteroot +] +.I system +.SH DESCRIPTION +.I Ftpfs +dials the TCP file transfer protocol (FTP) port, 21, on +.I system +and mounts itself (see +.IR bind (2)) +on +.I mountpoint +(default +.BR /n/ftp ) +to provide access to files on the remote machine. +If required by the remote machine, +.I ftpfs +will prompt for a user name and password. +The user names +.B ftp +and +.B anonymous +conventionally offer guest/read-only access to +machines. +Anonymous FTP may be called without user interaction +by using the +.B -a +option and specifying the +.IR password . +.PP +By default the file seen at the mount point is the user's +remote home directory if he has one. +The option +.B -/ +forces the mount point to correspond to the +remote root. +The option +.B -r +forces the mount point to correspond to the +remote directory +.IR remoteroot . +.PP +To avoid seeing startup messages from the server use option +.BR -q . +To see all messages from the server use option +.BR -d . +.PP +Some systems will hangup an ftp connection that has no activity +for a given period. The +.BR -k +option causes ftp to send a NOP command every 15 seconds to attempt +to keep the connection open. This command can cause some servers to +hangup, so you'll have to feel your way. +.PP +To terminate the connection, +.B unmount +(see +.IR bind (1)) +the mount point. +.PP +Since there is no specified format for metadata retrieved +in response to an FTP directory request, +.I ftpfs +has to apply heuristics to steer the interpretation. Sometimes, +though rarely, these heuristics fail. The following options are +meant as last resorts to try to steer interpretation. +.PP +A major clue to the heuristics is the operating system at the other +end. Normally this can be determined automatically using the +FTP SYST command. However, in some cases the server doesn't implement +the SYST command. The +.B -o +option will force the case by specifying the name of the operating +system. Known system types are are: +.BR Unix , +.BR Sun , +.BR Tops , +.BR Plan9 +.BR VM , +.BR VMS , +.BR MVS , +.BR NetWare , +.BR OS/2 , +.BR TSO , +and +.BR WINDOWS_NT . +.PP +Some systems and/or FTP servers return directory listings that don't +include the file extension. The +.B -e +option allows the user to specify an extension to append to all +remote files (other than directories). +.PP +Finally, there are two FTP commands to retrieve the contents of a +directory, LIST and NLST. LIST is approximately equivalent to +.L ls -l +and NLST to +.LR ls . +.I Ftpfs +normally uses LIST. However, some FTP servers interpret LIST +to mean, give a wordy description of the file. +.I Ftpfs +normally notices this and switches to using NLST. However, in +some rare cases, the user must force the use of NLST with the +.B -n +option. +.SH EXAMPLE +You want anonymous FTP access to the system +.BR export.lcs.mit.edu . +The first +.IR import (4) +command is only necessary if your machine does not have access to the +desired system, but another, called +.B gateway +in this example, does. +.IP +.EX +import gateway /net +ftpfs -a yourname@yourmachine export.lcs.mit.edu +.EE +.SH SOURCE +.B /sys/src/cmd/ip/ftpfs +.SH "SEE ALSO" +.IR bind (2) +.SH BUGS +.PP +Symbolic links on remote Unix systems will always have mode 0777 +and a length of 8. +.PP +After connecting to a TOPS-20 system, the mount point will contain +only one directory, usually +.BR /n/ftp/PS:<ANONYMOUS> . +However, walking to any valid directory on that machine will succeed +and cause that directory entry to appear under the mount point. +.PP +.I Ftpfs +caches files and directories. A directory will fall from the cache +after 5 quiescent minutes or if the local user changes the +directory by writing or removing a file. +Otherwise, remote +changes to the directory that occur after the directory has +been cached might not be immediately visible. +.PP +There is no way to issue the appropriate commands to handle special synthetic +FTP file types such as directories +that automatically return a +.B tar +of their contents. diff --git a/static/plan9-4e/man4/import.4 b/static/plan9-4e/man4/import.4 new file mode 100644 index 00000000..c3c3b49c --- /dev/null +++ b/static/plan9-4e/man4/import.4 @@ -0,0 +1,121 @@ +.TH IMPORT 4 +.SH NAME +import \- import a name space from a remote system +.SH SYNOPSIS +.B import +[ +.B -abcC +] [ +.B "-E clear | ssl" +.\" .B "| tls" .\" Not yet implemented +] [ +.B "-e 'enc auth'" +] [ +.B -p +] [ +.B "-s \f2srvname\fP +] +.I system +.I file +[ +.I mountpoint +] +.SH DESCRIPTION +.I Import +allows an arbitrary +.I file +on a remote +.I system +to be imported into the local name space. +Usually +.I file +is a directory, so the complete +file tree under the directory is made available. +.PP +A process is started on the +remote machine, with authority of the user of +.IR import , +to perform work for the local machine using the +.IR exportfs (4) +service. +If +.I mountpoint +is omitted +.I import +uses the name of the remote +.I file +as the local mount point. +.PP +If +.I file +is a directory, +.I import +allows options exactly as in +.I mount +and +.IR bind (1) +to control the construction of union directories. +.PP +The +.B -E +option causes +.I import +to push an authentication protocol on its network connection. +Currently, the protocols supported are +.B clear +(the default) which pushes no protocol, +and +.BR ssl . +There are plans to make +.B tls +available too. +.PP +The +.B -e +option specifies the encryption and authentication algorithms to use for +encrypting the wire traffic. The defaults are +.B rc4_256 +and +.BR sha1 . +The full list of supported protocols in in +.IR ssl (3). +.PP +The +.B -p +option pushes the +.B aan +filter onto the connection. This filter will protect the connection from +temporary network outages; see +.IR aan (1). +.PP +The +.B -s +option posts the connection's mountable file descriptor in +.B /srv +under the given name. +.SH EXAMPLE +Assume a machine +.B kremvax +that has IP interfaces for the company intranet and the global +internet mounted on +.I /net +and +.I /net.alt +respectively. +Any machine inside the company can get telnet out to the global +internet using: +.IP +.EX +import -a kremvax /net.alt +telnet /net.alt/tcp!ucbvax +.EE +.SH SOURCE +.B /sys/src/cmd/import.c +.SH SEE ALSO +.IR bind (1), +.IR aan (1), +.IR exportfs (4), +.IR ssl (3), +.B cs +in +.IR ndb (8) diff --git a/static/plan9-4e/man4/iostats.4 b/static/plan9-4e/man4/iostats.4 new file mode 100644 index 00000000..15371444 --- /dev/null +++ b/static/plan9-4e/man4/iostats.4 @@ -0,0 +1,64 @@ +.TH IOSTATS 4 +.SH NAME +iostats \- file system to measure I/O +.SH SYNOPSIS +.B iostats +[ +.B -d +] +[ +.B -f +.I dbfile +] +.I cmd +[ +.I args... +] +.SH DESCRIPTION +.I Iostats +is a user-level file server that interposes itself between a program +and the regular file server, which +allows it to gather statistics of file system +use at the level of the Plan 9 file system protocol, 9P. +After a program +exits a report is printed on standard error. +.PP +The report consists of three sections. +The first section reports the amount +of user data in +.B read +and +.B write +messages sent by the program and the average rate at +which the data was transferred. +The +.B protocol +line reports the amount +of data sent as message headers, that is, +protocol overhead. +The +.B rpc +line reports the +total number of file system transactions. +.PP +The second section gives +the number of messages, the fastest, slowest, and average turn around +time and the amount of data involved with each 9P +message type. +The final section gives an I/O summary for each file used +by the program in terms of opens, reads and writes. +.PP +If the +.B -d +flag is present, a debugging log including all traffic +is written to +.I dbfile +(default +.BR iostats.out ). +.SH SOURCE +.B /sys/src/cmd/iostats +.SH BUGS +Poor clock resolution means that large amounts of I/O must be done to +get accurate rate figures. +.PP +Can be fooled by programs that do fresh mounts outside its purview. diff --git a/static/plan9-4e/man4/keyfs.4 b/static/plan9-4e/man4/keyfs.4 new file mode 100644 index 00000000..b88b0330 --- /dev/null +++ b/static/plan9-4e/man4/keyfs.4 @@ -0,0 +1,248 @@ +.TH KEYFS 4 +.SH NAME +keyfs, warning \- authentication database files +.SH SYNOPSIS +.B auth/keyfs +[ +.B -p +] +[ +.B -w +.RB [ np ] +] +[ +.BI -m mntpt +] +[ +.I keyfile +] +.PP +.B auth/warning +[ +.B -n +] +[ +.B -p +] +.SH DESCRIPTION +.I Keyfs +serves a two-level file tree for manipulating authentication information. +It runs on the machine providing authentication service for the local +Plan 9 network, which may be a dedicated authentication server or +a CPU server. +The programs described in +.IR auth (8) +use +.I keyfs +as their interface to the authentication database. +.PP +.I Keyfs +reads and decrypts file +.I keyfile +(default +.BR /adm/keys ) +using the DES key, +which is by default read from +.B #r/nvram +(see +.IR rtc (3)). +With option +.BR -p , +.I keyfs +prompts for a password from which the key is derived. +.I Keyfile +holds a 41-byte record for each user in the database. +Each record is encrypted separately +and contains the user's name, +DES key, +status, +host status, +and expiration date. +The name is a +null-terminated +.SM UTF +string +.B NAMELEN +bytes long. +The status is a byte containing +binary 0 if the account is enabled, +1 if it is disabled. +Host status is a byte containing +binary 1 if the user is a host, +0 otherwise. +The expiration date is four-byte little-endian integer +which represents the time in seconds since the epoch +(see +.IR date (1)) +at which the account will expire. +If any changes are made to the database that affect the information stored in +.IR keyfile , +a new version of the file is written. +.PP +There are two authentication databases, +one for Plan 9 user information, +and one for SecureNet user information. +A user need not be installed in both databases +but must be installed in the Plan 9 database to connect to a Plan 9 server. +.PP +.I Keyfs +serves an interpretation of the +.I keyfile +in the file tree rooted at +.I mntpt +(default +.BR /mnt/keys ). +Each user +.I user +in +.I keyfile +is represented as the directory +.IR mntpt / user . +.PP +Making a new directory in +.I mntpt +creates a new user entry in the database. +Removing a directory removes the user entry, +and renaming it changes the name in the entry. +Such changes are reflected immediately in +.IR keyfile . +.I Keyfs +does not allow duplicate names when creating or renaming user entries. +.PP +All files in the user directories except for +.B key +contain +.SM UTF +strings with a trailing newline when read, +and should be written as +.SM UTF +strings with or without a trailing newline. +.B Key +contains the +.BR DESKEYLEN -byte +encryption key for the user. +.PP +The following files appear in the user directories. +.TF expire +.TP +.B key +The authentication key for the user. +If the user's account is disabled or expired, +reading this file returns an error. +Writing +.I key +changes the key in the database. +.TP +.B log +The number of consecutive failed authentication attempts for the user. +Writing the string +.B bad +increments this number; writing +.B good +resets it to 0. +If the number reaches fifty, +.I keyfs +disables the account. +Once the account is disabled, +the only way to enable it is to write the string +.B ok +to +.BR status . +This number is not stored in +.IR keyfile , +and is initialized to 0 when +.I keyfs +starts. +.TP +.B status +The current status of the account, either +.B ok +or +.BR disabled . +Writing +.B ok +enables the account; +writing +.B disabled +disables it. +.TP +.B expire +The expiration time for the account. +When read, it contains either the string +.B never +or the time in seconds since the epoch +that the account will expire. +When written with strings of the same form, +it sets the expiration date for the user. +If the expiration date is reached, +the account is not disabled, +but +.I key +cannot be read without an error. +.PD +.PP +If the +.B -w +option is on, +.I keyfs +runs the command +.I warning +once every 24 hours to mail people about expiring keys. +Warnings are sent 14 days and 7 days prior to expiration. +The argument to +.BR -w , +either +.B p +or +.BR n , +is passed to +.I warning +to restrict the warnings to +the Plan 9 or SecureNet database. +The default for +.I keyfs +is not to call +.I warning +at all; +.I warning's +own default is to warn about both. +The files +.B /adm/netkeys.who +and +.B /adm/keys.who +are used to find the mail addresses to send to. +The first word on each line identifies +a user. +Any subsequent strings on the line delimited '<' and '>' are considered mail +addresses to send warnings to. +If multiple lines match a user, the last in the file is used. +.B Changeuser +(see +.IR auth (8)) +adds lines to these files. +.SH FILES +.TF /adm/netkeys.who +.TP +.B /adm/keys +Encrypted key file for the Plan 9 database. +.TP +.B /adm/netkeys +Encrypted key file for the SecureNet database. +.TP +.B /adm/keys.who +List of users in the Plan 9 database. +.TP +.B /adm/netkeys.who +List of users in the SecureNet database. +.TP +.B #r/nvram +The non-volatile RAM on the server, which holds the key used +to decrypt key files. +.SH SOURCE +.B /sys/src/cmd/auth/keyfs.c +.br +.B /sys/src/cmd/auth/warning.c +.SH "SEE ALSO" +.IR authsrv (6), +.IR namespace (6), +.IR auth (8) diff --git a/static/plan9-4e/man4/kfs.4 b/static/plan9-4e/man4/kfs.4 new file mode 100644 index 00000000..9ea00b5f --- /dev/null +++ b/static/plan9-4e/man4/kfs.4 @@ -0,0 +1,132 @@ +.TH KFS 4 +.SH NAME +kfs \- disk file system +.SH SYNOPSIS +.B disk/kfs +[ +.B -rc +] [ +.B -b +.I n +] [ +.B -f +.I file +] [ +.B -n +.I name +] [ +.B -p +.I perm +] [ +.B -s +] [ +.B -B +.I nbuf +] +.SH DESCRIPTION +.I Kfs +is a local user-level file server for a Plan 9 terminal with a disk. +It maintains a hierarchical Plan 9 file system on the disk +and offers +9P (see +.IR intro (5)) +access to it. +.I Kfs +begins by +checking the file system for consistency, +rebuilding the free list, and placing a file descriptor in +.BI /srv/ name\f1, +where +.I name +is the service name (default +.BR kfs ). +If the file system is inconsistent, +the user is asked for permission to ream +.RI ( q.v. ) +the disk. +The file system is not checked if it is reamed. +.PP +The options are +.TF "n name" +.TP +.BI "b " n +If the file system is reamed, use +.I n +byte blocks. +Larger blocks make the file system faster +and less space efficient. +.B 1024 +and +.B 4096 +are good choices. +.I N +must be a multiple of 512. +.TP +.B c +Do not check the file system. +.TP +.BI "f " file +Use +.I file +as the disk. +The default is +.BR /dev/sdC0/fs . +.TP +.BI "n " name +Use +.RI kfs. name +as the name of the service. +.TP +.BI "p " perm +Use +.I perm +as the initial permissions for the +command channel +.BI /srv/ service .cmd\fR; +the default is 660. +.TP +.B r +Ream the file system, erasing all of the old data +and adding all blocks to the free list. +.TP +.B s +Post file descriptor zero in +.BI /srv/ service +and read and write protocol messages on file descriptor one. +.TP +.B B +Allocate +.I nbuf +in-memory file system blocks. +The default is as many as will fit in 10% of memory +or two megabytes, whichever is smaller. +.PD +.SH EXAMPLES +Create a file system with service name +.I kfs.local +and mount it on +.BR /n/kfs . +.IP +.EX +% kfs -rb4096 -nlocal +% mount -c /srv/kfs.local /n/kfs +.EE +.PP +.SH FILES +.TF /dev/sdC0/fs +.TP +.B /dev/sdC0/fs +Default file holding blocks. +.SH SOURCE +.B /sys/src/cmd/disk/kfs +.SH "SEE ALSO" +.IR kfscmd (8), +.IR mkfs (8), +.IR prep (8), +.IR sd (3) +.SH BUGS +For the moment, +.I kfs +serves both the old (third edition) and new (fourth +edition) versions of 9P, deciding which to serve by sniffing the first packet on each +connection. diff --git a/static/plan9-4e/man4/lnfs.4 b/static/plan9-4e/man4/lnfs.4 new file mode 100644 index 00000000..528001ed --- /dev/null +++ b/static/plan9-4e/man4/lnfs.4 @@ -0,0 +1,55 @@ +.TH LNFS 4 +.SH NAME +lnfs \- long name file system +.SH SYNOPSIS +.B lnfs +[ +.B -r +] +[ +.B -s +.I srvname +] +.I mountpoint +.SH DESCRIPTION +.I Lnfs +starts a process that mounts itself (see +.IR bind (2)) +on +.IR mountpoint . +It presents a filtered view of the files under the mount +point, allowing users to use long file names +on file servers that do not support file names +longer than 27 bytes. +.PP +The names used in the underlying file system are +the base32 encoding of the md5 hash of the longer +file name. The user need not know the mapping +since +.I lnfs +does all the work. +.I Lnfs +maintains a file +.B .longnames +in the directory +.I mountpoint +to record the long file names. +.PP +The options are: +.TP +.B -r +allow only read access to the file system +.TP +.B -s +provide a service name, +.IR srvname , +to post in +.BR /srv . +Without this option, no posting is performed. +.SH FILES +.B .longnames +.SH SOURCE +.B /sys/src/cmd/lnfs.c +.SH BUGS +This exists only to shame us into getting a real long +name file server working. diff --git a/static/plan9-4e/man4/namespace.4 b/static/plan9-4e/man4/namespace.4 new file mode 100644 index 00000000..68963d35 --- /dev/null +++ b/static/plan9-4e/man4/namespace.4 @@ -0,0 +1,384 @@ +.TH NAMESPACE 4 +.SH NAME +namespace \- structure of conventional file name space +.SH SYNOPSIS +none +.SH DESCRIPTION +After a user's profile has run, the file name space should adhere +to a number of conventions if the system is to behave normally. +This manual page documents those conventions by traversing the +file hierarchy and describing the points of interest. +It also serves as a guide to where things reside in the file system proper. +The traversal is far from exhaustive. +.PP +First, here is the appearance of the file server as it appears before +any mounts or bindings. +.TF /sys/src/cmd +.TP +.B / +The root directory. +.TP +.B /adm +The administration directory for the file server. +.TP +.B /adm/users +List of users known to the file server; see +.IR users (6). +.TP +.B /adm/keys +Authentication keys for users. +.TP +.B /adm/netkeys +SecureNet keys for users; see +.IR securenet (8). +.TP +.B /adm/timezone +Directory of timezone files; see +.IR ctime (2). +.TP +.B /adm/timezone/EST.EDT +Time zone description for Eastern Time. Other such files are in this directory too. +.TP +.B /adm/timezone/timezone +Time zone description for the local time zone; a copy of one of the other files in this directory. +.TP +.B /bin +.TP +.B /dev +.TP +.B /env +.TP +.B /fd +.TP +.B /net +.TP +.B /proc +.TP +.B /srv +.TP +.B /tmp +All empty unwritable directories, place holders for mounted services and directories. +.TP +.B /mnt +A directory containing mount points for applications. +.B /mnt/factotum +Mount point for +.IR factotum (4). +.TP +.B /n +A directory containing mount points for file trees imported from +remote systems. +.TP +.B /29000 +.TP +.B /386 +.TP +.B /68000 +.TP +.B /68020 +.TP +.B /960 +.TP +.B /alpha +.TP +.B /arm +.TP +.B /mips +.TP +.B /sparc +Each CPU architecture supported by Plan 9 has a directory in the root containing +architecture-specific files, to be selected according to +.B $objtype +or +.B $cputype +(see +.IR 2c (1) +and +.IR init (8)). +Here we list only those for +.BR /386 . +.TP +.B /386/init +The initialization program used during bootstrapping; see +.IR init (8). +.TP +.B /386/bin +Directory containing binaries for the Intel x86 architecture. +.TP +.B "/386/bin/aux +.TP +.B /386/bin/ip +.TP +etc. +Subdirectories of +.B /386/bin +containing auxiliary tools and collecting related programs. +.TP +.B /386/lib +Directory of object code libraries as used by +.B 8l +(see +.IR 2l (1)). +.TP +.B /386/include +Directory of x86-specific C include files. +.TP +.B /386/9* +The files in +.B /386 +beginning with a +.B 9 +are binaries of the operating system. +.TP +.B /386/mkfile +Selected by +.IR mk (1) +when +.B $objtype +is +.BR 386 , +this file configures +.B mk +to compile for the Intel x86 architecture. +.TP +.B /rc +Isomorphic to the architecture-dependent directories, this holds executables +and libraries for the shell, +.IR rc (1). +.TP +.B /rc/bin +Directory of shell executable files. +.TP +.B /rc/lib +Directory of shell libraries. +.TP +.B /rc/lib/rcmain +Startup code for +.IR rc (1). +.TP +.B /lib +Collections of data, generally not parts of programs. +.TP +.B /lib/mammals +.TP +.B /lib/sky +.TP +etc. +Databases. +.TP +.B /lib/ndb +The network database used by the networking software; see +.IR ndb (6) +and +.IR ndb (8). +.TP +.B /lib/namespace +The file used by +.B newns +(see +.IR auth (2)) +to establish the default name space; see +.IR namespace (6). +.TP +.B /lib/font/bit +Bitmap font files. +.TP +.B /lib/font/hershey +Vector font files. +.TP +.B /sys +System software. +.TP +.B /sys/include +Directory of machine-independent C include files. +.TP +.B /sys/lib +Pieces of programs not easily held in the various +.BR bins . +.TP +.B /sys/lib/acid +Directory of +.IR acid (1) +load modules. +.TP +.B /sys/lib/dist +Software used to assemble the distribution's installation floppy. +.TP +.B /sys/lib/troff +Directory of +.IR troff (1) +font tables and macros. +.TP +.B /sys/lib/yaccpar +The +.IR yacc (1) +parser. +.TP +.B /sys/man +The manual. +.TP +.B /sys/doc +Other system documentation. +.TP +.B /sys/log +Log files created by various system services. +.TP +.B /sys/src +Top-level directory of system sources. +.TP +.B /sys/src/cmd +Source to the commands in the +.B bin +directories. +.TP +.B /sys/src/9 +Source to the operating system for terminals and CPU servers. +.TP +.B /sys/src/fs +Source to the operating system for file servers. +.TP +.B /sys/src/lib* +Source to the libraries. +.TP +.B /mail +Directory of electronic mail; see +.IR mail (1). +.TP +.B /mail/box +Directory of users' mail box files. +.TP +.B /mail/lib +Directory of alias files, etc. +.TP +.B /acme +Directory of tools for +.IR acme (1). +.TP +.B /cron +Directory of files for +.IR cron (8). +.PD +.PP +The following files and directories are modified in the standard +name space, as defined by +.B /lib/namespace +(see +.IR namespace (6)). +.TF /sys/src/cmd +.TP +.B / +The root of the name space. It is a kernel device, +.IR root (3), +serving a number of local mount points such as +.B /bin +and +.B /dev +as well as the bootstrap program +.BR /boot . +Unioned with +.B / +is the root of the main file server. +.TP +.B /boot +Compiled into the operating system kernel, this file establishes +the connection to the main file server and starts +.BR init ; +see +.IR boot (8) +and +.IR init (8). +.TP +.B /bin +Mounted here is a union directory composed of +.BR /$objtype/bin , +.BR /rc/bin , +.BR $home/$objtype/bin , +etc., so +.B /bin +is always the directory containing the appropriate executables +for the current architecture. +.TP +.B /dev +Mounted here is a union directory containing I/O devices such as the +console +.RI ( cons (3)), +the interface to the raster display +.RI ( draw (3)), +etc. +The window system, +.IR rio (1), +prefixes +this directory with its own version, +overriding many device +files with its own, multiplexed simulations of them. +.TP +.B /env +Mounted here is the environment device, +.IR env (3), +which holds environment variables such as +.BR $cputype . +.TP +.B /net +Mounted here is a union directory formed of all the network devices +available. +.TP +.B /net/cs +The communications point for the connection server, +.B ndb/cs +(see +.IR ndb (8)). +.TP +.B /net/dns +The communications point for the Domain Name Server, +.B ndb/dns +(see +.IR ndb (8)). +.TP +.B /net/il +.TP +.B /net/tcp +.TP +.B /net/udp +Directories holding the IP protocol devices +(see +.IR ip (3)). +.TP +.B /proc +Mounted here is the process device, +.IR proc (3), +which provides debugging access to active processes. +.TP +.B /fd +Mounted here is the dup device, +.IR dup (3), +which holds pseudonyms for open file descriptors. +.TP +.B /srv +Mounted here is the service registry, +.IR srv (3), +which holds connections to file servers. +.TP +.B /srv/boot +The communication channel to the main file server for the machine. +.TP +.B /mnt/wsys +Mount point for the window system. +.TP +.B /mnt/term +Mount point for the terminal's name space as seen by the CPU server +after a +.IR cpu (1) +command. +.TP +.B /n/kremvax +A place where machine +.BR kremvax 's +name space may be mounted. +.TP +.B /tmp +Mounted here is each user's private +.B tmp, +.BR $home/tmp . +.SH SEE ALSO +.IR intro (1), +.IR namespace (6) diff --git a/static/plan9-4e/man4/nntpfs.4 b/static/plan9-4e/man4/nntpfs.4 new file mode 100644 index 00000000..d752f8bf --- /dev/null +++ b/static/plan9-4e/man4/nntpfs.4 @@ -0,0 +1,107 @@ +.TH NNTPFS 4 +.SH NAME +nntpfs \- network news transport protocol (NNTP) file system +.SH SYNOPSIS +.B nntpfs +[ +.B -s +.I service +] +[ +.B -m +.I mountpoint +] +.I system +.SH DESCRIPTION +.I Nntpfs +dials the TCP network news transport protocol (NNTP) +port, 119, on +.I system +(default +.BR '$nntp' ) +and presents at +.I mountpoint +(default +.BR /mnt/news ) +a file system corresponding to the +news articles stored on +.IR system . +.PP +The file system contains a directory per newsgroup, +with dots turned into slashes, e.g., +.B comp/os/plan9 +for +.BR comp.os.plan9 . +Each newsgroup directory contains one +numbered directory per article. +The directories follow the numbering used by +the server. +Each article directory contains three files: +.BR article , +.BR header , +and +.BR body . +The +.B article +file contains the full text of the article, +while +.B header +and +.B body +contain only the header or body. +.PP +Each newsgroup directory contains a +write-only +.B post +file that may be used to post news articles. +RFC1036-compliant articles should be written to it. +The +.B post +file will only exist in a given newsgroup directory +if articles are allowed to be posted to it. +Other than that, the +.B post +file is +.I not +tied to its directory's newsgroup. +The groups to which articles are eventually posted +are determined by the +.B newsgroups: +header lines in the posted article, +not by the location of the +.B post +file in the file system. +.PP +The qid version of a newsgroup directory +is the largest numbered article directory it +contains (~0, if there are no articles). +.PP +The modification time on a newsgroup +directory is the last time a new article was recorded +during this +.I nntpfs +session. +To force a check for new articles, +.IR stat (2) +the newsgroup directory. +.PP +To force a check for new newsgroups, +.IR stat (2) +the root directory. +Note that this causes the entire list of groups, +which can be about a megabyte, +to be transferred. +.PP +To terminate the connection, +.B unmount +the mount point. +.PP +.I Nntpfs +makes no effort to send ``keepalives'' so that +servers do not hang up on it. +Instead, it redials as necessary when hangups are detected. +.SH SOURCE +.B /sys/src/cmd/nntpfs.c +.SH BUGS +Directories are presented for deleted articles; +the files in them cannot be opened. diff --git a/static/plan9-4e/man4/paqfs.4 b/static/plan9-4e/man4/paqfs.4 new file mode 100644 index 00000000..0a200694 --- /dev/null +++ b/static/plan9-4e/man4/paqfs.4 @@ -0,0 +1,76 @@ +.TH PAQFS 4 +.SH NAME +paqfs \- compressed read-only file system +.SH SYNOPSIS +.B paqfs +[ +.B -disv +] +[ +.B -c +.I cachesize +] +[ +.B -m +.I mtpt +] +[ +.B -M +.I mesgsize +] +.I paqfile +.SH DESCRIPTION +.I Paqfs +interprets the compressed read-only file system created by +.IR mkpaqfs (8) +and stored in +.I paqfile +so that it can be mounted into a Plan 9 file system. +.I Paqfs +is typically used to create a stand alone file system for +a small persistent storage device, such as a flash ROM. +It does not authenticate its clients and assumes each group +has a single member with the same name. +.PP +Option to +.I paqfs +are: +.TP +.BI -c " cachesize +The number of file system blocks to cache in memory. The default is 20 blocks. +.TP +.B -d +Output various debugging information to +.IR stderr . +.TP +.B -i +Use file descriptors 0 and 1 as the 9P communication channel rather than create a pipe. +.TP +.BI -m " mtpt +The location to mount the file system. The default is +.BR /n/paq . +.TP +.BI -M " mesgsize +The maximum 9P message size. The default is sufficient for 8K byte read message. +.TP +.B -s +Post the 9P channel on #s/paqfs rather than +mounting it on +.IR mtpt . +.TP +.B -v +Verify the integrity of the +.IR paqfile . +Before mounting the file system, the +entire file is parsed and the +.I sha1 +checksum of the file system data is compared to the checksum embedded in the file. +This option enables the use of +.I paqfs +with files that consist of a +.I paq +file system concatenated with additional data. +.SH SOURCE +.B /sys/src/cmd/paqfs/paqfs.c +.SH "SEE ALSO" +.IR mkpaqfs (8) diff --git a/static/plan9-4e/man4/plumber.4 b/static/plan9-4e/man4/plumber.4 new file mode 100644 index 00000000..fbaebe41 --- /dev/null +++ b/static/plan9-4e/man4/plumber.4 @@ -0,0 +1,126 @@ +.TH PLUMBER 4 +.SH NAME +plumber \- file system for interprocess messaging +.SH SYNOPSIS +.B plumber +[ +.B -p +.I plumbing +] +.SH DESCRIPTION +The +.I plumber +is a user-level file server that receives, examines, rewrites, and dispatches +.IR plumb (6) +messages between programs. +Its behavior is programmed by a +.I plumbing +file (default +.BR /usr/$user/lib/plumbing ) +in the format of +.IR plumb (6). +.PP +Its services are mounted on the directory +.B /mnt/plumb +.RB ( /mnt/term/mnt/plumb +on the CPU server) and consist of two +pre-defined files, +.B send +and +.BR rules , +and a set of output +.I ports +for dispatching messages to applications. +The service is also published as a +.IR srv (4) +file, named in +.BR $plumbsrv , +for mounting elsewhere. +.PP +Programs use +.B write +(see +.IR read (2)) +to deliver messages to the +.B send +file, and +.IR read (2) +to receive them from the corresponding port. +For example, +.IR sam (1)'s +.B plumb +menu item or the +.B B +command cause a message to be sent to +.BR /mnt/plumb/send ; +.B sam +in turn reads from, by convention, +.B /mnt/plumb/edit +to receive messages about files to open. +.PP +A copy of each message is sent to each client that has the corresponding port open. +If none has it open, and the rule has a +.B plumb +.B client +or +.B plumb +.B start +rule, that rule is applied. +A +.B plumb +.B client +rule causes the specified command to be run +and the message to be held for delivery when the port is opened. +A +.B plumb +.B start +rule runs the command but discards the message. +If neither +.B start +or +.B client +is specified and the port is not open, +the message is discarded and a write error is returned to the sender. +.PP +The set of output ports is determined dynamically by the +specification in the plumbing rules file: a port is created for each unique +destination of a +.B plumb +.B to +rule. +.PP +The set of rules currently active may be examined by reading the file +.BR /mnt/plumb/rules ; +appending to this file adds new rules to the set, while +creating it (opening it with +.BR OTRUNC ) +clears the rule set. +Thus the rule set may be edited dynamically with a traditional text editor. +However, ports are never deleted dynamically; if a new set of rules does not +include a port that was defined in earlier rules, that port will still exist (although +no new messages will be delivered there). +.SH FILES +.TF /usr/$user/lib/plumbing +.TP +.B /usr/$user/lib/plumbing +default rules file +.TP +.B /sys/lib/plumb +directory to search for files in +.B include +statements +.TP +.B /mnt/plumb +mount point for +.IR plumber (4). +.SH SOURCE +.B /sys/src/cmd/plumb +.SH "SEE ALSO" +.IR plumb (1), +.IR plumb (2), +.IR plumb (6) +.SH BUGS +.IR Plumber 's +file name space is fixed, so it is difficult to plumb +messages that involve files in newly mounted services. + diff --git a/static/plan9-4e/man4/ramfs.4 b/static/plan9-4e/man4/ramfs.4 new file mode 100644 index 00000000..af2dece0 --- /dev/null +++ b/static/plan9-4e/man4/ramfs.4 @@ -0,0 +1,74 @@ +.TH RAMFS 4 +.SH NAME +ramfs \- memory file system +.SH SYNOPSIS +.B ramfs +[ +.B -i +] +[ +.B -s +] +[ +.B -p +] +[ +.B -m +.I mountpoint +] +.SH DESCRIPTION +.I Ramfs +starts a process that mounts itself (see +.IR bind (2)) +on +.I mountpoint +(default +.BR /tmp ). +The +.I ramfs +process implements a file tree rooted at +.IR dir , +keeping all files in memory. +Initially the file tree is empty. +.PP +The +.B -i +flag tells +.I ramfs +to use file descriptors 0 and 1 for its communication channel +rather than create a pipe. +This makes it possible to use +.I ramfs +as a file server on a remote machine: the file descriptors 0 +and 1 will be the network channel from +.I ramfs +to the client machine. +The +.B -s +flag causes +.I ramfs +to post its channel on +.B /srv/ramfs +rather than mounting it on +.IR mountpoint , +enabling multiple clients to access its files. +However, it does not authenticate its clients and its +implementation of groups is simplistic, so +it should not be used for precious data. +.PP +The +.B -p +flag causes +.I ramfs +to make its memory `private' +(see +.IR proc (3)) +so that its files are not accessible through the debugging interface. +.PP +This program is useful mainly as an example of how +to write a user-level file server. +It can also be used to provide high-performance temporary files. +.SH SOURCE +.B /sys/src/cmd/ramfs.c +.SH "SEE ALSO" +.IR bind (2) diff --git a/static/plan9-4e/man4/ratfs.4 b/static/plan9-4e/man4/ratfs.4 new file mode 100644 index 00000000..2d396f74 --- /dev/null +++ b/static/plan9-4e/man4/ratfs.4 @@ -0,0 +1,174 @@ +.TH RATFS 4 +.SH NAME +ratfs \- mail address ratification file system +.SH SYNOPSIS +.B ratfs +[ +.B -d +] [ +.B -c +.I configuration +] [ +.B -f +.I classification +] [ +.B -m +.I mountpoint +] +.SH DESCRIPTION +.I Ratfs +starts a process that mounts itself (see +.IR bind (2)) +on +.I mountpoint +(default +.BR /mail/ratify ). +.I Ratfs +is a persistent representation of the local network +configuration and spam blocking list. Without it +each instance of +.IR smtpd (6) +would need to reread and parse a multimegabyte list +of addresses and accounts. +.PP +.I Ratfs +serves a control file, +.BR ctl , +and several top level directories: +.BR trusted , +.BR deny , +.BR dial , +.BR block , +.BR delay , +and +.BR allow . +.PP +The control file is write only and accepts three +possible commands: +.TF "debug file +.TP +.B reload +rereads +.I classification +and +.I configuration +.TP +.B debug \fIfile\fP +creates +.I file +and sends debugging output to it. +.TP +.B nodebug +closes the debug file and turns off debugging +.PD +.PP +The directory +.B trusted +serves a file for each IP range from which all mail +is trusted. The names of the files are CIDR blocks; +an IP address or an IP address followed by +.BR #\fIn\fP , +where +.I n +is the number of bits to match. +To check if any IP address falls in a trusted +range, it is sufficient to open the file whose +name is the IP address. +For example, if +.B trusted +contains only the file +.BR 135.104.0.0#16 , +an attempt to open the file 135.104.9.1 will +succeed while opening 10.1.1.1 will fail. +To determine the particular range matched, +.B dirfstat +(see stat (2)) +the open file and the +.B name +field will be the matching CIDR range. +.PP +The trusted ranges come both from the +.B ournet +entries in the file +.I configuration +(default +.BR /mail/lib/blocked ) +and from creates, typically done by +.B imap4d +(see +.IR ipserv (8)) +and +.B pop3 +(see +.IR mail (1)) +whenever they are used to read someone's mail. +.PP +The remaining directories, +.BR allow , +.BR block , +.BR delay , +.BR deny , +and +.BR dial , +represent the contents of the +.I classification +(default +.BR /mail/lib/smtpd.conf ). +Each contains two directories; +.B ip +and +.BR account . +The +.B ip +directory has the same open semantics as the +.B trusted +directory, i.e., to check if an IP address falls +in that category, try to open a file whose +name is the IP address. +The +.B account +directory is similar but is used for matching +strings. Each file in the directory represents +a regular expression. To see if one of the +strings matches one of the regular expressions, +try to open the file whose name is the string. +If it succeeds, then there is a regular expression +that matches. To determine the regular expression, +.B fstat +the open file. The +.B name +field will be the regular expression. +.PP +There is a direct mapping from entries in +.I classification +and files under +.BR allow , +.BR block , +.BR delay , +.BR deny , +and +.BR dial. +A configuration file entry of the form: +.EX + dial 135.104.9.0/24 +.EE +corresponds to the file +.BR dial/ip/135.104.9.0#24 . +An entry of the form +.EX + *block .*!gre +.EE +corresponds to the file +.BR block/account/.*!gre . +.PP +Both the configuration file and control file formats +are described in +.IR smtpd (6). +.SH SOURCE +.B /sys/src/cmd/ratfs +.SH "SEE ALSO" +.IR mail (1) +.IR smtpd (6) +.IR scanmail (8) + + diff --git a/static/plan9-4e/man4/rdbfs.4 b/static/plan9-4e/man4/rdbfs.4 new file mode 100644 index 00000000..383dd26c --- /dev/null +++ b/static/plan9-4e/man4/rdbfs.4 @@ -0,0 +1,67 @@ +.TH RDBFS 4 +.SH NAME +rdbfs \- remote kernel debugging file system +.SH SYNOPSIS +.B rdbfs +[ +.B -d +] +[ +.B -p +.I pid +] +[ +.B -t +.I text +] +[ +.I device +] +.SH DESCRIPTION +.I Rdbfs +presents in +.BI /proc/ pid +(default +.BR /proc/1 ) +a set of process files for debugging +a kernel over the serial line +.I device +(default +.BR /dev/eia0 ). +.PP +The +.B text +file presented is just a copy of +.I text +(default +.BR /386/9pc ). +It can usually be ignored, since +the debuggers open kernel +files directly rather than +using +.BI /proc/ n /text\fR. +.PP +Kernels can be remotely debugged only when they are +suspended and serving +a textual debugging protocol over their serial lines. +Typing +.RB `` ^t^td '' +.RB (control- t ", control-" t ", d)" +at the console will cause the kernel to enter +this mode when it `panics'. +Typing +.RB `` ^t^tD '' +causes the kernel to enter this mode immediately. +.PP +Because the debugging protocol is textual, a console +provided by +.IR consolefs (4) +may be substituted for the serial device. +.SH SOURCE +.B /sys/src/cmd/rdbfs.c +.br +.B /sys/src/9/port/rdb.c +.SH "SEE ALSO" +.IR acid (1), +.IR db (1), +.IR consolefs (4) diff --git a/static/plan9-4e/man4/rio.4 b/static/plan9-4e/man4/rio.4 new file mode 100644 index 00000000..90e3cbe3 --- /dev/null +++ b/static/plan9-4e/man4/rio.4 @@ -0,0 +1,403 @@ +.TH RIO 4 +.SH NAME +rio \- window system files +.SH SYNOPSIS +.B rio +[ +.B -i +.BI ' cmd ' +] +[ +.B -s +] +[ +.B -f +.I font +] +.SH DESCRIPTION +The window system +.I rio +serves a variety of files for reading, writing, and controlling +windows. +Some of them are virtual versions of system files for dealing +with the display, keyboard, and mouse; others control operations +of the window system itself. +.I Rio +posts its service in the +.B /srv +directory, using a +name constructed from a catenation of the user ID +and a process id; the environment variable +.BR $wsys +is set to this service name within processes running under the control +of each invocation of +.IR rio . +Similarly, +.I rio +posts a named pipe to access the window creation features +(see +.B window +in +.IR rio (1)) +from outside +its name space; this is named in +.BR $wctl . +.PP +A +.I mount +(see +.IR bind (1)) +of +.B $wsys +causes +.I rio +to create a new window; the attach specifier in the +.I mount +gives the coordinates of the created window. +The syntax of the specifier is the same as the arguments to +.B window +(see +.IR rio (1)). +By default, the window is sized and placed automatically. +It is always necessary, however, to provide the process id of the +process to whom to deliver notes generated by DEL characters and hangups +in that window. +That pid is specified by including the string +.B -pid +.I pid +in the attach specifier. (See the Examples section +.IR q.v. ) +.PP +When a window is created either by +the +.I window +command +(see +.IR rio (1)) +or by using the menu supplied by +.IR rio , +this server is mounted on +.BR /mnt/wsys +and also +.BR /dev ; +the files mentioned here +appear in both those directories. +.PP +Some of these files supply virtual versions of services available from the underlying +environment, in particular the character terminal files +.IR cons (3), +and the mouse files +.IR mouse (3) +and +.IR cursor , +each specific to the window. +Note that the +.IR draw (3) +device multiplexes itself; +.IR rio +places windows but does not mediate programs' access to the display device. +.PP +Other files are unique to +.IR rio . +.TF window +.TP +.B cons +is a virtual version of the standard terminal file +.IR cons (3). +.I Rio +supplies extra editing features and a scroll bar +(see +.IR rio (1)). +.TP +.B consctl +controls interpretation of keyboard input. +Writing strings to it sets these modes: +.B rawon +turns on raw mode; +.B rawoff +turns off raw mode; +.B holdon +turns on hold mode; +.B holdoff +turns off hold mode. +Closing the file makes the window revert to default state +(raw off, hold off). +.TP +.B cursor +Like +.B mouse +.RI ( q.v. ), +a multiplexed version of the underlying device file, in this case representing the +appearance of the mouse cursor when the mouse is within the corresponding window. +.TP +.B label +initially contains a string with the process ID of the lead process +in the window and the command being executed there. +It may be written and is used as a tag when the window is hidden. +.TP +.B mouse +is a virtual version of the standard mouse file (see +.IR mouse (3)). +Opening it turns off scrolling, editing, and +.IR rio -supplied +menus in the associated +window. +In a standard mouse message, the first character is +.BR m , +but +.I rio +will send an otherwise normal message with the first character +.B r +if the corresponding window has been resized. +The application must then call +.B getwindow +(see +.IR graphics (2)) +to re-establish its state in the newly moved or changed window. +Reading the +.B mouse +file blocks until the mouse moves or a button changes. +Mouse movements or button changes are invisible when the mouse cursor +is located outside the window, except that if the mouse leaves the window +while a button is pressed, it will continue receiving mouse data until the button is released. +.TP +.B screen +is a read-only file reporting the depth, coordinates, and raster image corresponding to the entire +underlying display, +in the uncompressed format defined in +.IR image (6). +.TP +.B snarf +returns the string currently in the snarf buffer. +Writing this file sets the contents of the snarf buffer. +When +.I rio +is run recursively, the inner instance uses the snarf buffer of the parent, rather than +managing its own. +.TP +.B text +returns the full contents of the window. +It may not be written. +.TP +.B wctl +may be read or written. +When read, it returns the location of the window as four decimal integers formatted +in the usual 12-character style: upper left +.I x +and +.IR y , +lower right +.I x +and +.IR y . +Following these numbers are strings describing the window's state: +.B hidden +or +.BR visible ; +.B current +or +.BR notcurrent . +A subsequent read will block until the window changes size, location, or state. +When written to, +.B wctl +accepts messages to change the size or placement of the associated window, +and to create new windows. +The messages are in a command-line like format, with a command name, +possibly followed by options introduced by a minus sign. +The options must be separated by blanks, for example +.B -dx 100 +rather than +.BR -dx100 . +.IP +The commands are +.B resize +(change the size and position of the window), +.B move +(move the window), +.B scroll +(enable scrolling in the window), +.B noscroll +(disable scrolling), +.B set +(change selected properties of the window), +.B top +(move the window to the `top', making it fully visible), +.B bottom +(move the window to the `bottom', perhaps partially or totally obscuring it), +.B hide +(hide the window), +.B unhide +(restore a hidden window), +.B current +(make the window the recipient of keyboard and mouse input), +and +.B new +(make a new window). +The +.B top +and +.B bottom +commands do not change whether the window is current or not; +the others always make the affected window current. +.IP +Neither +.B top +nor +.B bottom +has any options. +The +.BR resize , +.BR move , +and +.B new +commands accept +.B -minx +.IR n , +.B -miny +.IR n , +.B -maxx +.IR n , +and +.BR -maxy +.I n +options to set the position of the corresponding edge of the window. +They also accept an option +.B -r +.I minx miny maxx maxy +to set all four at once. +The +.B resize +and +.B new +commands accept +.B -dx +.I n +and +.B -dy +.I n +to set the width and height of the window. +By default, +.I rio +will choose a convenient geometry automatically. +.IP +Finally, the +.B new +command accepts an optional shell command and argument string, +given as plain strings after any standard options, to run in the window +instead of the default +.B rc +.B -i +(see +.IR rc (1)). +The +.B -pid +.I pid +option to +.B new +identifies the +.I pid +of the process whose `note group' should receive interrupt +and hangup notes generated in the window. +The initial working directory of the new window may be set by a +.B -cd +.I directory +option. +The +.B -hide +option causes the window to be created off-screen, in the hidden state. +.IP +The +.B set +command accepts a set of parameters in the same style; only +.B -pid +.I pid +is implemented. +.IP +So programs outside name spaces controlled by +.I rio +may create windows, +.B wctl +.B new +messages may also be written to the named pipe identified by +.BR $wctl . +.TP +.B wdir +is a read/write text file containing +.IR rio 's +idea of the current working directory of the process running in the window. +It is used to fill in the +.B wdir +field of +.IR plumb (6) +messages +.I rio +generates from the +.B plumb +menu item on button 2. +The file is writable so the program may update it; +.I rio +is otherwise unaware of +.IR chdir (2) +calls its clients make. +In particular, +.IR rc (1) +maintains +.B /dev/wdir +in default +.IR rio (1) +windows. +.TP +.B winid +returns the unique and unchangeable ID for the window; +it is a string of digits. +.TP +.B window +is the virtual version of +.BR /dev/screen . +It contains the depth, coordinates, and +uncompressed raster image corresponding to the associated +window. +.TP +.B wsys +is a directory containing a subdirectory for each window, named +by the unique ID for that window. Within each subdirectory +are entries corresponding to several of the special files associated +with that window: +.BR cons , +.BR consctl , +.BR label , +.BR mouse , +etc. +.SH EXAMPLES +Cause a window to be created in the upper left corner, +and the word +.L hi +to be printed there. +.IP +.EX +mount $riosrv /tmp 'new -r 0 0 128 64 -pid '$pid +echo hi > /tmp/cons +.EE +.PP +Start +.IR sam (1) +in a large horizontal window. +.IP +.EX +echo new -dx 800 -dy 200 -cd /sys/src/cmd sam > /dev/wctl +.EE +.PP +Print the screen image of window with id 123. +.IP +.EX +lp /dev/wsys/123/window +.EE +.SH SOURCE +.B /sys/src/cmd/rio +.SH SEE ALSO +.IR rio (1), +.IR draw (3), +.IR mouse (3), +.IR cons (3), +.IR event (2), +.IR graphics (2). diff --git a/static/plan9-4e/man4/sacfs.4 b/static/plan9-4e/man4/sacfs.4 new file mode 100644 index 00000000..9b966281 --- /dev/null +++ b/static/plan9-4e/man4/sacfs.4 @@ -0,0 +1,59 @@ +.TH SACFS 4 +.SH NAME +sacfs \- compressed file system +.SH SYNOPSIS +.B disk/sacfs +[ +.B -i +.I infd +.I outfd +] +[ +.B -s +] +[ +.B -m +.I mountpoint +] +.I file +.SH DESCRIPTION +Sacfs interprets the compressed, block based file system created by +.IR mksacfs (8) +and stored in +.I file +so that it can be mounted into a Plan 9 file system. +.I Sacfs +is typically used to create a stand alone file system from +a small persistent storage device, such as a flash rom. +It does not authenticate its clients and assumes each group +has a single member with the same name. +.PP +The +.B -s +flag causes +.I sacfs +to post its channel on +.BR #s/sacfs . +The +.B -i +flag causes +.I sacfs +to use file descriptors +.I infd +and +.I outfd +for its communication channel. +If neither +.B -s +nor +.B -i +are given, +.I sacfs +mounts itself on +.IR mountpoint +(default +.BR /n/c: ). +.SH SOURCE +.B /sys/src/cmd/disk/sacfs/sacfs.c +.SH "SEE ALSO" +.IR mksacfs (8) diff --git a/static/plan9-4e/man4/snap.4 b/static/plan9-4e/man4/snap.4 new file mode 100644 index 00000000..d56706c7 --- /dev/null +++ b/static/plan9-4e/man4/snap.4 @@ -0,0 +1,103 @@ +.TH SNAP 4 +.SH NAME +snap, snapfs \- create and mount process snapshots +.SH SYNOPSIS +.B snap +[ +.B -o +.I file +] +.I pid... +.PP +.B snapfs +[ +.B -a +] +[ +.B -m +.I mtpt +] +[ +.B -s +.I service +] +.I file... +.SH DESCRIPTION +.I Snap +and +.I snapfs +allow one to save and restore (static) process images, +usually for debugging +on a different machine or at a different time. +.PP +.I Snap +writes a snapshot +(see +.IR snap (6)) +of the named processes to +.I file +(default standard output). +If +.I proc +is a text string +rather than a process id, +.I snap +will save all processes with +that name that +are owned by the current user. +Both memory and text images are saved. +.PP +.I Snapfs +is a file server that +recreates the +.B /proc +directories for the processes in the snapshot. +By default, it mounts the new directories +into +.B /proc +before the current entries. +The +.B -m +option can be used to specify +an alternate mountpoint, +while +.B -a +will cause it to mount the new directories +after the current entries. +The +.B -s +option causes it to serve requests via +.BI /srv/ service. +.SH EXAMPLE +Suppose +.I page +has hung viewing Postscript on your terminal, but the author is gone for the rest of +the month and you want to make sure the process +is still around for debugging on his return. +You can save the errant processes with +.IP +.EX +snap -o page.snap `{psu | awk '$NF ~ /page|gs/ {print $2}'} +.EE +.PP +When the author returns, he can add the process images to his name space +by running +.IP +.EX +snapfs page.snap +.EE +.PP +and then use a conventional +debugger to debug them. +.SH SOURCE +.B /sys/src/cmd/snap +.SH SEE ALSO +.IR acid (1), +.IR db (1), +.IR proc (3), +.IR snap (6) +.SH BUGS +The snapshots take up about as much disk space +as the processes they contain did memory. +Compressing them when not in use is recommended, +as is storing them on a rewritable disk. diff --git a/static/plan9-4e/man4/srv.4 b/static/plan9-4e/man4/srv.4 new file mode 100644 index 00000000..ab38204e --- /dev/null +++ b/static/plan9-4e/man4/srv.4 @@ -0,0 +1,237 @@ +.TH SRV 4 +.SH NAME +srv, srvold9p, 9fs \- start network file service +.SH SYNOPSIS +.B srv +[ +.B -abcCmq +] +.RI [ net !] system\c +.RI [! service ] +[ +.I srvname +[ +.I mtpt +] ] +.PP +.B 9fs +.RI [ net !] system +.RI [ mountpoint ] +.PP +.B srvold9p +[ +.B -abcCd +] [ +.B -u +.I user +] [ +.B -s +| [ +.B -m +.I mountpoint +] ] [ +.B -x +.I command +| +.B -n +.I network-addr +| +.B -f +.I file +] [ +.B -F +] [ +.B -p +.I servicename +] +.SH DESCRIPTION +.I Srv +dials the given machine and initializes the connection to serve the +9P protocol. +It then creates in +.B /srv +a file named +.IR srvname . +Users can then +.B mount +(see +.IR bind (1)) +the service, typically on a name in +.BR /n , +to access the files provided by the remote machine. +If +.I srvname +is omitted, the first argument to +.B srv +is used. +Option +.B m +directs +.I srv +to mount the service on +.BI /n/ system +or onto +.I mtpt +if it is given. +Option +.B q +suppresses complaints if the +.B /srv +file already exists. +The +.BR a , +.BR b , +.BR c , +and +.B C +flags are used to control the mount flag as in +.IR bind (1). +.PP +The specified +.I service +must serve 9P. Usually +.I service +can be omitted; when calling some +non-Plan 9 systems, a +.I service +such as +.B u9fs +must be mentioned explicitly. +.PP +The +.I 9fs +command does the +.I srv +and the +.I mount +necessary to make available the files of +.I system +on network +.IR net . +The files are mounted on +.IR mountpoint , +if given; +otherwise they are mounted on +.BI /n/ system\f1. +If +.I system +contains +.L / +characters, only the last element of +.I system +is used in the +.B /n +name. +.PP +.I 9fs +recognizes some special names, such as +.B dump +to make the dump file system available on +.BR /n/dump . +.I 9fs +is an +.IR rc (1) +script; examine it to see what local conventions apply. +.PP +.I Srvold9p +is a compatibilty hack to allow Fourth Edition Plan 9 systems +to connect to older 9P servers. +It functions as a variant of +.I srv +that performs a version translation on the 9P messages on the underlying connection. +Some of its options are the same as those of +.IR srv ; +the special ones are: +.TP +.B -d +Enable debuggging +.TP +.BI -u\ user +When connecting to the remote server, log in as +.IR user . +Since +.I srvold9p +does no authentication, and since new kernels cannot authenticate to +old services, the likeliest value of +.I user +is +.BR none . +.TP +.BI -x\ command +Run +.I command +and use its standard input and output as the 9P service connection. +If the +.I command +string contains blanks, it should be quoted. +.TP +.BI -n\ network-addr +Dial +.I network-addr +to establish the connection. +.TP +.BI -f\ file +Use +.I file +(typically an existing +.IR srv (3) +file) as the connection. +.TP +.B -F +Insert a special (internal) filter process to the connection to maintain +message boundaries; usually only needed on TCP connections. +.TP +.BI -p\ servicename +Post the service under +.IR srv (3) +as +.BI /srv/ servicename\f1. +.PP +.I Srvold9p +is run automatically when a +.IR cpu (1) +call is received on the service port for the old protocol. +.SH EXAMPLES +To see kremvax's and deepthought's files in +.B /n/kremvax +and +.BR /n/deepthought : +.IP +.EX +9fs kremvax +9fs hhgttg /n/deepthought +.EE +.PP +To mount as user +.B none +a connection to an older server kgbsun: +.IP +.EX +srvold9p -u none -m /n/kgbsun -p kgbsun -n il!kgbsun +.EE +.PP +Other windows may then mount the connection directly: +.IP +.EX +mount /srv/kgbsun /n/kgbsun +.EE +.SH NOTE +The TCP port used for 9P is 564. +.SH FILES +.TF /srv/* +.TP +.B /srv/* +ports to file systems and servers posted by +.I srv +and +.I 9fs +.SH SOURCE +.B /sys/src/cmd/srv.c +.br +.B /rc/bin/9fs +.br +.SH "SEE ALSO" +.IR bind (1), +.IR dial (2), +.IR srv (3), +.IR ftpfs (4) diff --git a/static/plan9-4e/man4/tapefs.4 b/static/plan9-4e/man4/tapefs.4 new file mode 100644 index 00000000..e6ca73ed --- /dev/null +++ b/static/plan9-4e/man4/tapefs.4 @@ -0,0 +1,100 @@ +.TH TAPEFS 4 +.SH NAME +32vfs, cpiofs, tapfs, tarfs, tpfs, v6fs, v10fs \- mount archival file systems +.SH SYNOPSIS +.B fs/32vfs +[ +.B -m +.I mountpoint +] +[ +.B -p +.I passwd +] +[ +.B -g +.I group +] +.I file +.br +.B fs/cpiofs +.br +.B fs/tapfs +.br +.B fs/tarfs +.br +.B fs/tpfs +.br +.B fs/v6fs +.br +.B fs/v10fs +.br +.SH DESCRIPTION +These commands interpret data from traditional tape or file system formats +stored in +.IR file , +and mount their contents (read-only) into a Plan 9 file system. +The optional +.B -p +and +.B -g +flags specify Unix-format password (respectively group) files +that give the mapping between the numeric user- and group-ID +numbers on the media and the strings reported by Plan 9 status +inquiries. +The +.B -m +flag introduces the name at which the new file system should be +attached; the default is +.BR /n/tapefs . +.PP +.I 32vfs +interprets raw disk images of 32V systems, which are ca. 1978 research Unix systems for +the VAX, and also pre-FFS Berkeley VAX systems (1KB block size). +.PP +.I Cpiofs +interprets +.B cpio +tape images (constructed with +.BI cpio 's +.B c +flag). +.PP +.I Tarfs +interprets +.I tar +tape images. +.PP +.I Tpfs +interprets +.I tp +tapes from the Fifth through Seventh Edition research Unix systems. +.PP +.I Tapfs +interprets +.I tap +tapes from the pre-Fifth Edition era. +.PP +.I V6fs +interprets disk images from the +Fifth and Sixth edition research Unix systems (512B block size). +.PP +.I V10fs +interprets disk images from the +Tenth Edition research Unix systems (4KB block size). +.SH SOURCE +.PP +These commands are constructed in a highly stereotyped +way using the files +.I fs.c +and +.I util.c +in +.BR /sys/src/cmd/tapefs , +which in +turn derive substantially from +.IR ramfs (4). +.SH "SEE ALSO +Section 5 +.IR passim , +.IR ramfs (4). diff --git a/static/plan9-4e/man4/telco.4 b/static/plan9-4e/man4/telco.4 new file mode 100644 index 00000000..f78a9086 --- /dev/null +++ b/static/plan9-4e/man4/telco.4 @@ -0,0 +1,226 @@ +.TH TELCO 4 +.SH NAME +telco, faxreceive, faxsend, fax, telcofax, telcodata \- telephone dialer network +.SH SYNOPSIS +.B telco +[ +.B -p +] [ +.B -i +.I source-id +] [ +.B -v +] +.I dialer-devs +.PP +.B aux/faxsend +.I address +.I page1 +\&... +.PP +.B aux/faxreceive +[ +.B -s +.I spool-dir +] [ +.B -v +] +.PP +.B fax +.I telno +.I recipient +[ +.I files +] +.PP +.B service/telcofax +.PP +.B service/telcodata +.SH DESCRIPTION +.I Telco +is a file server that provides a network interface to +Hayes telephone dialers. +The interface is the same as that provided by +.IR ip (3) +and can be used by any program that makes network connections using +.IR dial (2). +The network addresses used by +.I telco +are telephone +numbers. +.PP +The options are +.TP +.B -p +use pulse dialing +.TP +.B -v +verbose: write to the log file all communications with +the dialer. +.TP +.B -i +specify a +.I source-id +to be used during FAX transfers +.PP +Some control of outgoing calls can be encoded +in the address. +Normally, addresses are of the form +.IB telco ! number\f1, +where +.I number +is a decimal telephone number. +However, commas in the telephone number can be used to insert +pauses in the dialing process. +Dialing options can be added to the end of the address, separated +by +.BR ! 's. +The dialing options are +.TF baudrate +.TP +.B compress +turn on compression (default off) +.TP +.I baudrate +a decimal number representing the highest baud +rate with which to make the call +.TP +.B fax +to make a Class 2 facsimile call (used by programs such as +.IR faxsend ) +.PD +.PP +.I Telco +also answers incoming calls. +Upon receiving a facsimile call, +.I telco +starts the script +.BR /rc/bin/service/telcofax . +For data calls it starts +.BR /rc/bin/service/telcodata . +Each is started with the network connection as both standard +input and standard output and with two arguments, +the file name of the network connection, e.g., +.BR /net/telco/0/data , +and the type of modem. +Currently, the only modem types supported are: +.TF ATT14400 +.TP +.B MT1432 +Multitech's 14400 baud modem +.TP +.B MT2834 +Multitech's 28800 baud modem +.TP +.B ATT14400 +the 14400 baud modem in Safaris +.TP +.B VOCAL +the 14400 baud Vocal modem +.PD +.PP +All other modems are assumed to be compatible with the standard +Hayes command subset. +.PP +.I Faxreceive +is normally started by +.BR /rc/bin/service/telcofax . +It inputs and spools a CCITT Group 3 (G3) encoded FAX, and then starts the +script +.BR /sys/lib/fax/receiverc , +passing it four arguments: the spool file name, +.B Y +(for success) or +.BR N , +the number of pages, and the id string passed by the caller. +This script sends by +.IR mail (1) +notification to a list of recipients kept in the file +.BR /mail/faxqueue/faxrecipients ; +the script and the list +should be edited to match local needs. +.I Faxreceive's +options are: +.TP +.B -s +specify a different spool directory; the default is +.BR /mail/faxqueue . +.TP +.B -v +verbose: write to the log file all communications with +the modem. +.PP +.I Faxsend +transmits a FAX to +.IR address . +.I Page1 +and all arguments that follow +are names of files containing G3 encoded +FAX images, one per page. +.PP +.I Fax +is a shell script that queues +PostScript, G3, or text files to be transmitted to a +FAX machine. +A standard cover sheet, derived from +.BR /sys/lib/fax/h.ps , +is sent before the message. +.I Telno +is the destination telephone number. +.I Recipient +is the name of the recipient to be placed +on the cover sheet. +If no +.I files +are specified, standard input is sent. +.SH EXAMPLE +Start the dialer on a PC, then use +.I con +to phone out. +.IP +.EX +telco /dev/eia1 +con -l telco!18005551212 +.EE +.PP +The connection will be made at the highest +negotiable baud rate. To use the +best negotiable compression scheme as well: +.IP +.EX +con -l telco!18005551212!compress +.EE +.SH FILES +.B /mail/faxqueue/* +.br +.B /rc/bin/service/telcodata +.br +.B /rc/bin/service/telcofax +.br +.B /sys/log/telco +.br +.B /sys/lib/fax/receiverc +.br +.B /mail/faxqueue/faxrecipients +.br +.B /sys/lib/fax/h.ps +.br +.B /sys/log/fax +.SH SOURCE +.B /sys/src/cmd/telco/* +.br +.B /sys/src/cmd/fax/* +.SH "SEE ALSO" +.IR con (1), +.IR ip (3) +.SH BUGS +.PP +These programs require the Class 2 facsimile interface. This means that +.I faxsend +and +.I faxreceive +will not work on most portable computers since they have Class 1 +interfaces. +.PP +The modem specific information is currently built into the source. +This should be in a user modifiable file. diff --git a/static/plan9-4e/man4/u9fs.4 b/static/plan9-4e/man4/u9fs.4 new file mode 100644 index 00000000..6d4d475c --- /dev/null +++ b/static/plan9-4e/man4/u9fs.4 @@ -0,0 +1,250 @@ +.TH U9FS 4 +.SH NAME +u9fs \- serve 9P from Unix +.SH SYNOPSIS +.B u9fs +[ +.B -Dnz +] +[ +.B -a +.I authtype +] +[ +.B -A +.I autharg +] +[ +.B -l +.I logfile +] +[ +.B -m +.I msize +] +[ +.B -u +.I onlyuser +] +.SH DESCRIPTION +.I U9fs +is +.I not +a Plan 9 program. Instead it is a program that +serves Unix files to Plan 9 machines using the 9P protocol +(see +.IR intro (5)). +It is typically invoked on a +Unix machine by +.B inetd +with its standard input and output connected to a +network connection, typically TCP on an Ethernet. +It typically runs as user +.B root +and multiplexes access to multiple Plan 9 clients over the single wire. +It assumes Plan 9 uids match Unix login names, +and changes to the corresponding Unix effective uid when processing requests. +.I U9fs +serves both 9P1 (the 9P protocol as used by +the second and third editions of Plan 9) and 9P2000. +.PP +The options are: +.TP +.B -D +Write very chatty debugging output to the log file (see +.B -l +option below). +.TP +.B -n +Signals that +.I u9fs +is +.I not +being invoked with a network connection +on standard input and output, and thus should +not try to determine the remote address of the connection. +This is useful when +.I u9fs +is not invoked from +.I inetd +(see examples below). +.TP +.B -z +Truncate the log file on startup. This is useful mainly when debugging +with +.BR -D . +.TP +.BI -a " authtype +Sets the authentication method to be used. +.I Authtype +should be +.BR rhosts , +.BR none , +or +.BR 9p1 . +The default is +.BR rhosts , +which uses the +.I ruserok +library call to authenticate users by entries in +.B /etc/hosts.equiv +or +.BR $HOME/.rhosts . +This default is discouraged for all but the most controlled networks. +Specifying +.B none +turns off authentication altogether. +This is useful when +.I u9fs +is not invoked from +.I inetd +(see examples below). +Specifying +.B 9p1 +uses the second and third edition Plan 9 authentication mechanisms. +The file +.BR /etc/u9fs.key , +or +.I autharg +if specified +(see the +.B -A +option), +is consulted for the authentication data. +The file must contain exactly three lines: +the plaintext password, the user id, and +the authentication domain. +.TP +.BI -A " autharg +Used to specify an argument to the authentication method. +See the authentication descriptions above. +.TP +.BI -l " logfile +Specifies the file which should contain debugging output +and other messages. +The out-of-the-box compile-time default is +.BR /tmp/u9fs.log . +.TP +.BI -m " msize +Set +.I msize +for 9P2000 +(see +.IR open (5)). +.TP +.BI -u " user +Treat all attaches as coming from +.IR user . +This is useful in some cases when running without +.IR inetd ; +see the examples. +.SH +EXAMPLES +.PP +Plan 9 calls 9P file service +.B 9fs +with TCP port number 564. +Set up this way on a machine called, say, +.BR kremvax , +.I u9fs +may be connected to the name space of a Plan 9 process by +.IP +.EX +9fs kremvax +.EE +.PP +For more information on this procedure, see +.IR srv (4) +and +.IR bind (1). +.PP +.I U9fs +serves the entire file system of the Unix machine. +It forbids access to devices +because the program is single-threaded and may block unpredictably. +Using the +.B attach +specifier +.B device +connects to a file system identical to the usual system except +it only permits device access (and may block unpredictably): +.IP +.EX +srv tcp!kremvax!9fs +mount -c /srv/tcp!kremvax!9fs /n/kremvax device +.EE +.PP +(The +.B 9fs +command +does not accept an attach specifier.) +Even so, +device access may produce unpredictable +results if the block size of the device is greater than 8192, +the maximum data size of a 9P message. +.PP +The source to +.I u9fs +is in the Plan 9 directory +.BR /sys/src/cmd/unix/u9fs . +To install +.I u9fs +on a Unix system with an ANSI C compiler, copy the source to a directory on that system +and run +.BR make . +Then install the binary in +.BR /usr/etc/u9fs . +Add this line to +.BR inetd.conf : +.IP +.EX +9fs stream tcp nowait root /usr/etc/u9fs u9fs +.EE +.PP +and this to +.BR services : +.IP +.EX +9fs 564/tcp 9fs # Plan 9 fs +.EE +.LP +Due to a bug in their +IP software, some systems will not accept the service name +.BR 9fs , +thinking it +a service number because of the initial digit. +If so, run the service as +.B u9fs +or +.BR 564 . +.PP +On systems where listeners cannot be started, +.IR execnet (4) +is useful for running +.I u9fs +via mechanisms like +.IR ssh . +.SH SOURCE +.B /sys/src/cmd/unix/u9fs +.SH DIAGNOSTICS +Problems are reported to the +log file specified with the +.B -l +option (default +.BR /tmp/u9fs.log ). +The +.B -D +flag enables chatty debugging. +.SH SEE ALSO +.IR bind (1), +.IR execnet (4), +.IR srv (4), +.IR ip (3), +.IR nfsserver (8) +.SH BUGS +The implementation of devices is unsatisfactory. +.LP +Semantics like remove-on-close or the +atomicity of +.B wstat +are hard to provide exactly. diff --git a/static/plan9-4e/man4/usb.4 b/static/plan9-4e/man4/usb.4 new file mode 100644 index 00000000..2f01063b --- /dev/null +++ b/static/plan9-4e/man4/usb.4 @@ -0,0 +1,154 @@ +.TH USB 4 +.SH NAME +usbmouse, +usbaudio +\- Universal Serial Bus user level device drivers +.SH SYNOPSIS +.B usb/usbmouse +[ +.B -f +] [ +.I ctrlno +.I n +] +.PP +.B usb/usbaudio +[ +.B -d +] [ +.B -v +.I volume +] [ +.B -m +.I mountpoint +] [ +.I ctrlno +.I n +] +.PP +.B usbstart +.SH DESCRIPTION +These programs implement support for specific USB device classes. +They should be run after +.IR usbd (4) +has had a chance to locate the devices in question and provide +them with device addresses and minimal configuration. +Dynamic handling of device insertion and removal is currently not supported. +.PP +The script +.B usbstart +checks whether a USB driver is present, and if so, starts usbd +followed by the support programs listed below. +.SS USB MICE +.B Usbmouse +sends mouse events from a USB mouse to +.B #m/mousein +where the Plan 9 kernel processes them like other mice. +.PP +Without arguments, it scans the USB status files to find a mouse +and uses the first one it finds. A pair of numeric arguments overrides this search +with a specific USB controller and device. +.PP +The +.B -f +flag runs +.B usbmouse +in the foreground. +.SS USB AUDIO DEVICES +.B Usbaudio +configures and manages a usb audio device. It implements a file system, +normally mounted in +.BI /dev , +but this can be changed with the +.B \-m +flag, with files +.IR /volume , +.IR /audioctl , +.IR /audio , +and +.IR /audioin . +The names +.I /volume +and +.I /audio +maintain backward compatibility with the soundblaster driver. +.PP +Reading +.I /volume +or +.I /audioctl +yields the device's settings. The data format of +.I /volume +is compatible with the soundblaster and +produces something like +.PP +.EX +audio out 65 +treb out 0 +bass out 0 +speed out 44100 +.EE +.PP +This file can be written using the same syntax. The keyword +.I out +may be omitted. Settings are given as percentages of the range. +.PP +The file +.I /audioctl +provides more information, using up to 6 columns of 12 characters each. +From left to right, the fields are: +.IR "control name" , +.I in +or +.IR out , +.IR "current value" , +.IR "minimum value" , +.IR maximum , +and +.IR resolution . +There are 3, 5, or 6 columns present. +Maxima and resolution are omitted when they are not available or not applicable. +The resolution for +.I speed +is reported as 1 (one) if the sampling frequency is continuously variable. It is absent +if it is settable at a fixed number of discrete values only. +.PP +When all values from +.I /audioctl +have been read, a zero-sized buffer is returned (the usual end-of-file indication). +A new read will then block until one of the settings changes and then report its new value. +.PP +The file +.I /audioctl +can be written like +.IR /volume . +.PP +Audio data is written to +.I /audio +and read from +.IR /audioin . +The data format is little endian, samples ordered primarily by time and +secondarily by channel. Samples occupy the minimum integral number +of bytes. Read and write operations of arbitrary size are allowed. +.SH EXAMPLE +.LP +To use a USB mouse and audio device, put the following in your profile +(replace x by your favorite initial volume setting): +.PP +.EX +.ta 6n +if (test -r '#U'/usb0) { + usb/usbd + usb/usbmouse -a 2 + usb/usbaudio -v x +} +.EE +.PP +Alternatively, just put +.B usbstart +in your profile. +.SH SOURCE +.B /sys/src/cmd/usb +.SH "SEE ALSO" +.IR usb (3), +.IR usbd (4) diff --git a/static/plan9-4e/man4/usbd.4 b/static/plan9-4e/man4/usbd.4 new file mode 100644 index 00000000..154d49c9 --- /dev/null +++ b/static/plan9-4e/man4/usbd.4 @@ -0,0 +1,35 @@ +.TH USBD 4 +.SH NAME +usbd \- Universal Serial Bus daemon +.SH SYNOPSIS +.B usbd +[ +.B -v +] [ +.B -d +] +.SH DESCRIPTION +.I Usbd +manages the USB infrastructure, polls all ports, configures hubs and +provides access to USB devices through a file system in +.BR #U . +It monitors all ports, active or inactive and acts on state changes +by configuring devices when they are plugged in or turned on and +unconfiguring them when they are pulled out or switched off. +.PP +.B Usbd +recognizes the following flags: +.I +.TP +.B v +Verbose; print configuration information and device status as they change. +.TP +.B d +Debug; print the bytes in each message sent or received. +.LP +.sp +.SH SOURCE +.B /sys/src/cmd/usb/usbd +.SH "SEE ALSO" +.IR usb (3), +.IR usb (4) diff --git a/static/plan9-4e/man4/vacfs.4 b/static/plan9-4e/man4/vacfs.4 new file mode 100644 index 00000000..db9c79a6 --- /dev/null +++ b/static/plan9-4e/man4/vacfs.4 @@ -0,0 +1,72 @@ +.TH VACFS 4 +.SH NAME +vacfs \- a Venti-based file system +.SH SYNOPSIS +.B vacfs +[ +.B -dis +] +[ +.B -c +.I cachesize +] +[ +.B -h +.I host +] +[ +.B -m +.I mtpt +] +.I vacfile +.SH DESCRIPTION +.I Vacfs +interprets the file system created by +.IR vac (1) +so that it can be mounted into a Plan 9 file hierarchy. +The data for the file system is stored on +.IR venti (8) +with a root fingerprint specified in +.IR vacfile . +.I Vacfs +is currently rather limited: access is read-only, +clients are not authenticated, and groups are assumed to +contain a single member with the same name. +These restrictions should eventually be removed. +.PP +Options to +.I vacfs +are: +.TP +.BI -c " cachesize +The number of file system blocks to cache in memory. The default is 1000 blocks. +.TP +.B -d +Print debugging information to standard error. +.TP +.BI -h " host +The network address of the Venti server. +The default is taken from the environment variable +.BR venti . +If this variable does not exist, then the default is the +metaname +.BR $venti , +which can be configured via +.IR ndb (6). +.TP +.B -i +Use file descriptors 0 and 1 as the 9P communication channel rather than create a pipe. +.TP +.BI -m " mtpt +The location to mount the file system. The default is +.BR /n/vac . +.TP +.B -s +Post the 9P channel on #s/vacfs rather than +mounting it on +.IR mtpt . +.SH SOURCE +.B /sys/src/cmd/vac +.SH "SEE ALSO" +.IR vac (1), +.IR venti (8) diff --git a/static/plan9-4e/man4/webcookies.4 b/static/plan9-4e/man4/webcookies.4 new file mode 100644 index 00000000..63842e90 --- /dev/null +++ b/static/plan9-4e/man4/webcookies.4 @@ -0,0 +1,166 @@ +.TH WEBCOOKIES 4 +.SH NAME +webcookies \- HTTP cookie manager +.SH SYNOPSIS +.B webcookies +[ +.B -f +.I cookiefile +] +[ +.B -m +.I mtpt +] +[ +.B -s +.I service +] +.SH DESCRIPTION +.I Webcookies +manages a set of HTTP cookies, which are +used to associate HTTP requests with persistent state +(such as user profiles) on many web servers. +.PP +.I Webcookies +reads +.I cookiefile +(default +.BR $home/lib/webcookies ) +and mounts itself at +.I mtpt +(default +.BR /mnt/webcookies ). +If +.I service +is specified, +.I cookiefs +will post a service file descriptor +in +.BR /srv/\fIservice . +.PP +The cookie file contains one cookie per line; +each cookie comprises some number of +.IB attr = value +pairs. +Cookie attributes are: +.TF \fBnetscapestyle=flag +.TP +.BI name= name +The name of the cookie on the remote server. +.TP +.BI value= value +The value associated with that name on the remote server. +The actual data included when a cookie is sent back +to the server is +.IB \fR``\fIname = value\fR'' +(where, confusingly, +.I name +and +.I value +are the values associated with the +.B name +and +.B value +attributes. +.TP +.BI domain= domain +The domain within which the cookie can be used. +If +.I domain +is an IP address, the cookie can only be used when +connecting to a web server at that IP address. +If +.I domain +is a pattern beginning with a dot, +the cookie can only be used for servers whose name +has +.I domain +as a suffix. +For example, a cookie with +.B domain=.bell-labs.com +may be used on the web sites +.I www.bell-labs.com +and +.IR www.research.bell-labs.com . +.TP +.BI path= path +The cookie can only be used for URLs with a path (the part after +.BI http:// hostname\fR) +beginning with +.IR path . +.TP +.BI version= version +The version of the HTTP cookie specification, specified by the server. +.TP +.BI comment= comment +A comment, specified by the server. +.TP +.BI expire= expire +The cookie expires at time +.IR expire , +which is a decimal number of seconds since the epoch. +.TP +.B secure=1 +The cookie may only be used over secure +.RB ( https ) +connections. +.TP +.B explicitdomain=1 +The domain associated with this cookie was set by +the server (rather than inferred from a URL). +.TP +.B explicitpath=1 +The path associated with this cookie was set by the +server (rather than inferred from a URL). +.TP +.B netscapestyle=1 +The server presented the cookie in ``Netscape style,'' which +does not conform to the cookie standard, RFC2109. +It is assumed that when presenting the cookie to the server, +it must be sent back in Netscape style as well. +.PD +.PP +.I Webcookies +serves a directory containing two files. +The first, +.BR cookies , +is a textual representation of the cookie file, +which can be edited to change the set of cookies +currently held. +The second, +.BR http , +is intended to be used by HTTP clients +to access cookies. +Upon opening +.BR http , +the client must write a full URL to it. +After writing the URL, reading from the file will yield any +HTTP +.B Cookie: +headers that should be included in the +request for this particular URL. +Once the request has been made, any +.B Set-Cookie: +lines in the HTTP response header should +be written to the file to save them for next time. +If +.B cookiefs +decides not to accept the cookie (as outlined in +RFC2109, section 4.3.4), no indication is given. +.PP +.IR Hget (1) +uses +.BR /mnt/webcookies/http , +when it exists, to manage cookie state. +.I Webfs +does not (yet). +.SH SOURCE +.B /sys/src/cmd/webcookies.c +.SH SEE ALSO +.IR hget (1) +.SH BUGS +It's not clear what the relationship between +.I cookiefs +and something like +.I webfs +should be. diff --git a/static/plan9-4e/man4/webfs.4 b/static/plan9-4e/man4/webfs.4 new file mode 100644 index 00000000..e6d57bfa --- /dev/null +++ b/static/plan9-4e/man4/webfs.4 @@ -0,0 +1,307 @@ +.TH WEBFS 4 +.SH NAME +webfs \- world wide web file system +.SH SYNOPSIS +.B webfs +[ +.B -c +.I cookiefile +] +[ +.B -m +.I mtpt +] +[ +.B -s +.I service +] +\&... +.SH DESCRIPTION +.I Webfs +presents a file system interface to the parsing and retrieving +of URLs. +.I Webfs +mounts itself at +.I mtpt +(default +.BR /mnt/web ), +and, if +.I service +is specified, will post a service file descriptor +in +.BR /srv/\fIservice . +.PP +.I Webfs +presents a three-level file system suggestive +of the network protocol hierarchies +.IR ip (3) +and +.IR ether (3). +.PP +The top level contains three files: +.BR ctl , +.BR cookies , +and +.BR clone . +.PP +The +.B ctl +file is used to maintain parameters global to the instance of +.IR webfs . +Reading the +.B ctl +file yields the current values of the parameters. +Writing strings of the form +.RB `` attr " " value '' +sets a particular attribute. +Attributes are: +.TP +.B chatty9p +The +.B chatty9p +flag used by the 9P library, discussed in +.IR 9p (2). +.B 0 +is no debugging, +.B 1 +prints 9P message traces on standard error, +and values above +.B 1 +present more debugging, at the whim of the library. +The default for this and the following debug flags is +.BR 0 . +.TP +.B fsdebug +This variable is the level of debugging output about the file system module. +.TP +.B cookiedebug +This variable is the level of debugging output about the cookie module. +.TP +.B urldebug +This variable is the level of debugging output about URL parsing. +.TP +.B acceptcookies +This flag controls whether to accept cookies presented by remote web servers. +(Cookies are described below, in the discussion of the +.B cookies +file.) +The values +.B on +and +.B off +are synonymous with +.B 1 +and +.BR 0 . +The default is +.BR on . +.TP +.B sendcookies +This flag controls whether to present stored cookies to remote web servers. +The default is +.BR on . +.TP +.B redirectlimit +Web servers can respond to a request with a message +redirecting to another page. +.I Webfs +makes no effort to determine whether it is in an infinite +redirect loop. +Instead, it gives up after this many redirects. +The default is +.BR 10 . +.TP +.B useragent +.I Webfs +sends the value of this attribute in its +.B User-Agent: +header in its HTTP requests. +The default is +.RB `` "webfs/2.0 (plan 9)" .'' +.PD +.PP +The top-level directory also contains +numbered directories corresponding to connections, which +may be used to fetch a single URL. +To allocated a connection, open the +.B clone +file and read a number +.I n +from it. +After opening, the +.B clone +file is equivalent to the file +.IB n /ctl \fR. +A connection is assumed closed once all files in its directory +have been closed, and is then will be reallocated. +.PP +Each connection has its own private set of +.BR acceptcookies , +.BR sendcookies , +.BR redirectlimit , +and +.B useragent +variables, initialized to the defaults set in the +root's +.B ctl +file. The per-connection +.B ctl +file allows editing the variables for this particular connection. +.PP +Each connection also has a URL string variable +.B url +associated with it. +This URL may be an absolute URL such as +.I http://www.lucent.com/index.html +or a relative URL such as +.IR ../index.html . +The +.B baseurl +string variable sets the URL against which relative URLs +are based. +Once the URL has been set, +its pieces can be retrieved via individual files in the +.B parsed +directory. +.I Webfs +parses the following URL syntaxes; names in italics are +the names of files in the +.B parsed +directory. +.IP +\fIscheme\f5:\fIschemedata +.br +\f5http://\fIhost\f5/\fIpath\fR[\f5?\fIquery\fR][\f5#\fIfragment\fR] +.br +\f5ftp://\fR[\fIuser\fR[\f5:\fIpassword\fR]\f5@\fR]\fP\f5\fIhost\f5/\fIpath\fR[\f5;type=\fIftptype\fR] +.br +\f5file:\fIpath +.LP +If there is associated data to be +posted with the request, it can be written to +.BR postbody . +Finally, opening +.B body +initiates the request. +The resulting data may be read from +.B body +as it arrives. +After the request has been executed, the MIME content type +may be read from the +.B contenttype +file. +.PP +The top-level +.B cookies +file contains the internal set of HTTP cookies, which +are used by HTTP servers to associate requests with persistent +state such as user profiles. +It may be edited as an ordinary text file. +Multiple instances of +.I webfs +and +.IR webcookies (4) +share cookies by keeping their internal set +consistent with the +.I cookiefile +(default +.BR $home/lib/webcookies ), +which has the same format. +.PP +These files contain one line per cookie; +each cookie comprises some number of +.IB attr = value +pairs. +Cookie attributes are: +.TP +.BI name= name +The name of the cookie on the remote server. +.TP +.BI value= value +The value associated with that name on the remote server. +The actual data included when a cookie is sent back +to the server is +.IB \fR``\fIname = value\fR'' +(where, confusingly, +.I name +and +.I value +are the values associated with the +.B name +and +.B value +attributes. +.TP +.BI domain= domain +If +.I domain +is an IP address, the cookie can only be used for URLs +with +.I host +equal to that IP address. +Otherwise, +.I domain +must be a pattern beginning with a dot, and +the cookie can only be used for URLs with a +.I host +having +.I domain +as a suffix. +For example, a cookie with +.B domain=.bell-labs.com +may be used on hosts +.I www.bell-labs.com +and +.IR www.research.bell-labs.com +(but not +.IR www.not-bell-labs.com ). +.TP +.BI path= path +The cookie can only be used for URLs with a path +beginning with +.IR path . +.TP +.BI version= version +The version of the HTTP cookie specification, specified by the server. +.TP +.BI comment= comment +A comment, specified by the server. +.TP +.BI expire= expire +The cookie expires at time +.IR expire , +which is a decimal number of seconds since the epoch. +.TP +.B secure=1 +The cookie may only be used over secure +.RB ( https ) +connections. +Secure connections are currently unimplemented. +.TP +.B explicitdomain=1 +The domain associated with this cookie was set by +the server (rather than inferred from a URL). +.TP +.B explicitpath=1 +The path associated with this cookie was set by the +server (rather than inferred from a URL). +.TP +.B netscapestyle=1 +The server presented the cookie in ``Netscape style,'' which +does not conform to the cookie standard, RFC2109. +It is assumed that when presenting the cookie to the server, +it must be sent back in Netscape style as well. +.PD +.PP +.SH SOURCE +.B /sys/src/cmd/webfs +.SH SEE ALSO +.IR hget (1), +.IR webcookies (4). +.SH BUGS +It's not clear what the relationship between +.IR hget , +.I webcookies +and +.I webfs +should be. diff --git a/static/plan9-4e/man4/wikifs.4 b/static/plan9-4e/man4/wikifs.4 new file mode 100644 index 00000000..e99ba361 --- /dev/null +++ b/static/plan9-4e/man4/wikifs.4 @@ -0,0 +1,338 @@ +.TH WIKIFS 4 +.SH NAME +wikifs, wikipost \- wiki file system +.SH SYNOPSIS +.B wikifs +[ +.B -DM +] +[ +.B -a +.I announce +]... +[ +.B -m +.I mtpt +] +[ +.B -p +.I perm +] +[ +.B -s +.I service +] +.I dir +.PP +.B ip/httpd/wikipost +.RB [ -b +.IR inbuf ] +.RB [ -d +.IR domain ] +.RB [ -r +.IR remoteip ] +.RB [ -w +.IR webroot ] +.RB [ -N +.IR netdir ] +.I method version uri +.RI [ search ] +.SH DESCRIPTION +A +.I wiki +is a web server that facilitates easy editing of the pages it contains. +.I Wikifs +presents a wiki in two forms: as web pages to be served +via +.IR httpd (8) +and as text files to be viewed via the +.IR acme (1) +wiki client +(see +.BR /acme/wiki/guide ). +.PP +.I Wikifs +presents a file system interface to the wiki data stored +in +.IR dir . +By default, +.I wikifs +mounts itself at +.BR /mnt/wiki ; +the +.B -m +flag specifies a different mount point, +and the +.B -M +flag causes +.I wikifs +not to mount at all. +.I Wikifs +also announces 9P network services on the addresses +given as arguments to +.B -a +options. +If the +.B -s +option is given, +.I wikifs +will post a service file descriptor in +.BI /srv/ service +with permission +.I perm +(default 600). +The +.B -D +flag causes a transcript of the 9P conversation +to be written to standard error. +.PP +The wiki holds both the current pages and also +all versions of all pages that have ever existed. +All pages have time stamps associated with them. +When a user wants to edit a page, he reads the +current page from the wiki, noting the time stamp +on the page. +When a user writes changes to a page, he includes the time stamp +of the page he started with. If the page has been updated +by someone else while he was editing, the write will fail. +This is called a ``conflicting write.'' +The submission is still saved in the history, so that +the user can compare the page he submitted with the changes +that were made while he was editing. +.PP +Each version of each page is described by a text file containing +one or more metadata lines followed by the page contents. +The metadata lines begin with a capital letter specifying the type of data. +Currently the metadata types are: +.TP +.B D +The date this page was written, in decimal seconds since the epoch. +.TP +.B A +The author of this version of the page. Typically the rest of the line +takes the form +.I name +.IR ip-address . +.TP +.B X +This page's contents were submitted but rejected due to a +conflicting write. +.PD +After the metadata comes the actual page contents; each line of +page contents is prefixed with a +.B # +character. +.PP +The directory +.IB dir /d +contains all the wiki data. Typically it is world-writable +so that +.I wikifs +can run as none. +Each page on the wiki has a unique sequence number +.IR n ; +for each page, the +.B d +directory contains three files +.IR n , +.IB n .hist \fR, +and +.BI L .n \fR. +The file +.I n +holds the current version of the page: the first line of +.I n +is the page title, followed by page metadata and contents as described above. +The append-only file +.IB n .hist +holds the history of the page. +The first line of +.IB n .hist +is the title of the page. +The rest of the file is the metadata and contents of every +version of the page that has been submitted to the wiki. +.BI L .n +is a lock file for the page: it must be +held while reading or writing +.I n +and +.IB n .hist \fR. +The lock files allow multiple instances of +.I wikifs +to coexist peacefully. +Finally, the +.B map +file (with associated lock +.BR L.map ) +provides a mapping from +sequence numbers to +to page titles. +Each map line is a decimal +.IR n , +a single space, +and then the title. +Since titles are presented as names by +.IR wikifs , +they cannot contain slashes. +.PP +.I Wikifs +presents a three-level file system. +The top level contains per-page directories +named by the page titles with spaces turned +into underscores. +Each page also has a number associated with it +(see the discussion of the wiki data files below). +The number corresponding to a page may +also be used to access it, although directory +listings will always present the title. +The +.B new +file is used to add new or revised pages to the wiki: +writes to the file should be in the usual textual format: +a title line, metadata lines, and page contents. +Once all the contents have been written, a final zero-length +message should be written to mark the end of the page. +This last write will return an error if a conflicting +write has occurred. +After writing the file, the client may read from +.B new +to obtain the canonical title for the page, as presented +by the file system. +.PP +The page directories contain subdirectories representing +the history of the page, named +by the decimal time stamp corresponding to each version. +In addition to these history directories, +the page directories contain the following files: +.TP +.B current +The current raw data file for the page. +.TP +.B diff.html +A web page listing the contents of every version of +the page that has ever appeared on the wiki. +The text is grey by default: +differences between versions appear in black. +.TP +.B edit.html +A web form for editing the the current version of the page. +.TP +.B history.html +A web page listing the time stamps of the historical versions of the page. +Each time stamp links to a page showing just +that version. +.TP +.B history.txt +A textual formatting of the history. Each time stamp is prefixed with +the name of the directory corresponding to that version. +.TP +.B index.html +An HTML formatting of the current version of the page. +.TP +.B index.txt +A textual formatting of the current version of the page. +.TP +.B werror.html +An HTML error page to be returned by +.I wikipost +on conflicting writes. +.PD +.LP +The HTML files are generated from the templates with the same names +in +.IR dir , +except that +.B index.html +and +.B index.txt +are generated from the templates +.B page.html +and +.BR page.txt . +.PP +The history directories +are similar to the page directories but only contain +.BR current , +.BR index.html , +and +.BR index.txt . +This +.B index.html +and +.B index.txt +are generated from the templates +.B oldpage.html +and +.BR oldpage.txt . +.PP +The +.IR httpd (8) +helper program +.I wikipost +is used to process editing requests posted +to the web server by users. +It expects the posted form to contain these +(usually hidden) fields: +.BR TITLE , +the title of the page; +.BR VERSION , +the time stamp of the page that is being edited; +.BR service , +the service name associated with this wiki +.RI ( wikipost +looks for +.BI /srv/wiki. service \fR); +and +.BR base , +the base for wiki URLs in the response. +.PP +After mounting the wiki, +.I wikipost +writes a page update request to +.B /mnt/wiki/new +and then returns the contents of one HTML +file in +.BR /mnt/wiki/ title \fR. +If the write succeeds, +.I wikipost +returns +.BR index.html . +if the write fails due to a conflicting write, +.I wikipost +returns +.BR werror.html . +.SH EXAMPLE +The Plan 9 wiki at Bell Labs is started by running: +.EX +.ta +4n + wikifs -p 666 -s wiki.plan9 -a tcp!*!wiki /sys/lib/wiki +.EE +.PP +The wiki is mounted for +.IR httpd (8) +by an entry in +.BR /lib/namespace.httpd : +.EX +.ta +4n + # wiki + mount -b #s/wiki.plan9 /usr/web/wiki/plan9 +.EE +Notice that the wiki service was explicitly posted with +mode 666 so that +.I httpd +(running as none) +would be able to mount it. +.PP +In the Plan 9 distribution, the directory +.B /sys/lib/wiki +contains sample files similar to those used +to start the current Plan 9 wiki. +.SH SOURCE +.B /sys/src/cmd/wikifs +.br +.B /sys/src/cmd/ip/httpd/wikipost.c +.SH SEE ALSO +The original wiki, +.B http://c2.com/cgi/wiki?WikiWikiWeb +.br +.B /acme/wiki/guide |