unmount_on_exit Parameter
-------------------------

   (type=boolean), default=`no').  If `yes', then Amd will attempt to
unmount all file systems which it knows about.  Normally it leaves all
(esp. NFS) mounted file systems intact.  Note that Amd does not know
about file systems mounted before it starts up, unless the
`restart_mounts' option is used (see restart_mounts Parameter).

vendor Parameter
----------------

   (type=string, default to compiled in value).  The name of the vendor
of the operating system.  Overrides the compiled-in vendor name.  Useful
when the compiled-in name is not desired.  For example, most Intel based
systems set the vendor name to `unknown', but you can set it to
`redhat'.

Regular Map Parameters
======================

   The following parameters are applicable only to regular map sections.

map_name Parameter
------------------

   (type=string, must be specified).  Name of the map where the keys are
located.

tag Parameter
-------------

   (type=string, default no tag).  Each map entry in the configuration
file can be tagged.  If no tag is specified, that map section will
always be processed by Amd.  If it is specified, then Amd will process
the map if the `-T' option was given to Amd, and the value given to that
command-line option matches that in the map section.

amd.conf Examples
=================

   The following is the actual `amd.conf' file I use at the Computer
Science Department of Columbia University.

     # GLOBAL OPTIONS SECTION
     [ global ]
     normalize_hostnames =    no
     print_pid =              no
     #pid_file =              /var/run/amd.pid
     restart_mounts =         yes
     #unmount_on_exit =       yes
     auto_dir =               /n
     log_file =               /var/log/amd
     log_options =            all
     #debug_options =         all
     plock =                  no
     selectors_in_defaults =  yes
     # config.guess picks up "sunos5" and I don't want to edit my maps yet
     os =                     sos5
     # if you print_version after setting up "os", it will show it.
     print_version =          no
     map_type =               file
     search_path =            /etc/amdmaps:/usr/lib/amd:/usr/local/AMD/lib
     browsable_dirs =         yes
     fully_qualified_hosts =  no

     # DEFINE AN AMD MOUNT POINT
     [ /u ]
     map_name =               amd.u

     [ /proj ]
     map_name =               amd.proj

     [ /src ]
     map_name =               amd.src

     [ /misc ]
     map_name =               amd.misc

     [ /import ]
     map_name =               amd.import

     [ /tftpboot/.amd ]
     tag =                    tftpboot
     map_name =               amd.tftpboot

Run-time Administration
***********************

Starting Amd
============

   Amd is best started from `/etc/rc.local' on BSD systems, or from the
appropriate start-level script in `/etc/init.d' on System V systems.

     if [ -f /usr/local/sbin/ctl-amd ]; then
         /usr/local/sbin/ctl-amd start; (echo -n ' amd') > /dev/console
     fi

The shell script, `ctl-amd' is used to start, stop, or restart Amd.  It
is a relatively generic script.  All options you want to set should not
be made in this script, but rather updated in the `amd.conf' file.
See Amd Configuration File.

   If you do not wish to use an Amd configuration file, you may start
Amd manually.  For example, getting the map entries via NIS:

     amd -r -l /var/log/amd `ypcat -k auto.master`

Stopping Amd
============

   Amd stops in response to two signals.

`SIGTERM'
     causes the top-level automount points to be unmounted and then Amd
     to exit.  Any automounted filesystems are left mounted.  They can
     be recovered by restarting Amd with the `-r' command line option.

`SIGINT'
     causes Amd to attempt to unmount any filesystems which it has
     automounted, in addition to the actions of `SIGTERM'.  This signal
     is primarily used for debugging.

   Actions taken for other signals are undefined.

   The easiest and safest way to stop Amd, without having to find its
process ID by hand, is to use the `ctl-amd' script, as with:

     ctl-amd stop

Restarting Amd
==============

   Before Amd can be started, it is vital to ensure that no other Amd
processes are managing any of the mount points, and that the previous
process(es) have terminated cleanly.  When a terminating signal is set
to Amd, the automounter does _not_ terminate right then.  Rather, it
starts by unmounting all of its managed mount mounts in the background,
and then terminates.  It usually takes a few seconds for this process
to happen, but it can take an arbitrarily longer time.  If two or more
Amd processes attempt to manage the same mount point, it usually will
result in a system lockup.

   The easiest and safest way to restart Amd, without having to find
its process ID by hand, sending it the `SIGTERM' signal, waiting for Amd
to die cleanly, and verifying so, is to use the `ctl-amd' script, as
with:

     ctl-amd restart

   The script will locate the process ID of Amd, kill it, and wait for
it to die cleanly before starting a new instance of the automounter.
`ctl-amd' will wait for a total of 30 seconds for Amd to die, and will
check once every 5 seconds if it had.

Controlling Amd
===============

   It is sometimes desirable or necessary to exercise external control
over some of Amd's internal state.  To support this requirement, Amd
implements an RPC interface which is used by the "Amq" program.  A
variety of information is available.

   Amq generally applies an operation, specified by a single letter
option, to a list of mount points.  The default operation is to obtain
statistics about each mount point.  This is similar to the output shown
above but includes information about the number and type of accesses to
each mount point.

Amq default information
-----------------------

   With no arguments, "Amq" obtains a brief list of all existing mounts
created by Amd.  This is different from the list displayed by df(1)
since the latter only includes system mount points.

The output from this option includes the following information:

   * the automount point,

   * the filesystem type,

   * the mount map or mount information,

   * the internal, or system mount point.

For example:

     /            root   "root"                    sky:(pid75)
     /homes       toplvl /usr/local/etc/amd.homes  /homes
     /home        toplvl /usr/local/etc/amd.home   /home
     /homes/jsp   nfs    charm:/home/charm         /a/charm/home/charm/jsp
     /homes/phjk  nfs    toytown:/home/toytown     /a/toytown/home/toytown/ai/phjk

If an argument is given then statistics for that volume name will be
output.  For example:

     What         Uid   Getattr Lookup RdDir   RdLnk   Statfs Mounted@
     /homes       0     1196    512    22      0       30     90/09/14 12:32:55
     /homes/jsp   0     0       0      0       1180    0      90/10/13 12:56:58

`What'
     the volume name.

`Uid'
     ignored.

`Getattr'
     the count of NFS "getattr" requests on this node.  This should
     only be non-zero for directory nodes.

`Lookup'
     the count of NFS "lookup" requests on this node.  This should only
     be non-zero for directory nodes.

`RdDir'
     the count of NFS "readdir" requests on this node.  This should only
     be non-zero for directory nodes.

`RdLnk'
     the count of NFS "readlink" requests on this node.  This should be
     zero for directory nodes.

`Statfs'
     the count of NFS "statfs" requests on this node.  This should only
     be non-zero for top-level automount points.

`Mounted@'
     the date and time the volume name was first referenced.

Amq `-f' option
---------------

   The `-f' option causes Amd to flush the internal mount map cache.
This is useful for example in Hesiod maps since Amd will not
automatically notice when they have been updated.  The map cache can
also be synchronized with the map source by using the `sync' option
(see Automount Filesystem).

Amq `-h' option
---------------

   By default the local host is used.  In an HP-UX cluster the root
server is used since that is the only place in the cluster where Amd
will be running.  To query Amd on another host the `-h' option should
be used.

Amq `-H' option
---------------

   Print a brief help and usage string.

Amq `-l' option
---------------

   Tell Amd to use log_file as the log file name.  For security
reasons, this _must_ be the same log file which Amd used when started.
This option is therefore only useful to refresh Amd's open file handle
on the log file, so that it can be rotated and compressed via daily
cron jobs.

Amq `-m' option
---------------

   The `-m' option displays similar information about mounted
filesystems, rather than automount points.  The output includes the
following information:

   * the mount information,

   * the mount point,

   * the filesystem type,

   * the number of references to this filesystem,

   * the server hostname,

   * the state of the file server,

   * any error which has occurred.

   For example:

     "root"           truth:(pid602)     root   1 localhost is up
     hesiod.home      /home              toplvl 1 localhost is up
     hesiod.vol       /vol               toplvl 1 localhost is up
     hesiod.homes     /homes             toplvl 1 localhost is up
     amy:/home/amy    /a/amy/home/amy    nfs    5 amy is up
     swan:/home/swan  /a/swan/home/swan  nfs    0 swan is up (Permission denied)
     ex:/home/ex      /a/ex/home/ex      nfs    0 ex is down

   When the reference count is zero the filesystem is not mounted but
the mount point and server information is still being maintained by Amd.

Amq `-p' option
---------------

   Return the process ID of the remote or locally running Amd.  Useful
when you need to send a signal to the local Amd process, and would
rather not have to search through the process table.  This option is
used in the `ctl-amd' script.

Amq `-P' option
---------------

   Contact an alternate running Amd that had registered itself on a
different RPC PROGRAM_NUMBER and apply all other operations to that
instance of the automounter.  This is useful when you run multiple
copies of Amd, and need to manage each one separately.  If not
specified, Amq will use the default program number for Amd, 300019.
For security reasons, the only alternate program numbers Amd can use
range from 300019 to 300029, inclusive.

   For example, to kill an alternate running Amd:

     kill `amq -p -P 300020`

Amq `-s' option
---------------

   The `-s' option displays global statistics.  If any other options
are specified or any filesystems named then this option is ignored.
For example:

     requests  stale     mount     mount     unmount
     deferred  fhandles  ok        failed    failed
     1054      1         487       290       7017

`Deferred requests'
     are those for which an immediate reply could not be constructed.
     For example, this would happen if a background mount was required.

`Stale filehandles'
     counts the number of times the kernel passes a stale filehandle to
     Amd.  Large numbers indicate problems.

`Mount ok'
     counts the number of automounts which were successful.

`Mount failed'
     counts the number of automounts which failed.

`Unmount failed'
     counts the number of times a filesystem could not be unmounted.
     Very large numbers here indicate that the time between unmount
     attempts should be increased.

Amq `-T' option
---------------

   The `-T' option causes the Amq to contact Amd using the TCP
transport only (connection oriented).  Normally, Amq will use TCP
first, and if that failed, will try UDP.

Amq `-U' option
---------------

   The `-U' option causes the Amq to contact Amd using the UDP
transport only (connectionless).  Normally, Amq will use TCP first, and
if that failed, will try UDP.

Amq `-u' option
---------------

   The `-u' option causes the time-to-live interval of the named mount
points to be expired, thus causing an unmount attempt.  This is the only
safe way to unmount an automounted filesystem.  It is not possible to
unmount a filesystem which has been mounted with the `nounmount' flag.

Amq `-v' option
---------------

   The `-v' option displays the version of Amd in a similar way to
Amd's `-v' option.

Amq `-w' option
---------------

   The `-w' option translates a full pathname as returned by getpwd(3)
into a short Amd pathname that goes through its mount points.  This
option requires that Amd is running.

Other Amq options
-----------------

   Two other operations are implemented.  These modify the state of Amd
as a whole, rather than any particular filesystem.  The `-x' and `-D'
options have exactly the same effect as Amd's corresponding command
line options.

   When Amd receives a `-x' flag it limits the log options being
modified to those which were not enabled at startup.  This prevents a
user turning _off_ any logging option which was specified at startup,
though any which have been turned on since then can still be turned
off.  The `-D' option has a similar behavior.

FSinfo
******

   XXX: this chapter should be reviewed by someone knowledgeable with
fsinfo.

FSinfo overview
===============

   FSinfo is a filesystem management tool.  It has been designed to
work with Amd to help system administrators keep track of the ever
increasing filesystem namespace under their control.

   The purpose of FSinfo is to generate all the important standard
filesystem data files from a single set of input data.  Starting with a
single data source guarantees that all the generated files are
self-consistent.  One of the possible output data formats is a set of
Amd maps which can be used amongst the set of hosts described in the
input data.

   FSinfo implements a declarative language.  This language is
specifically designed for describing filesystem namespace and physical
layouts.  The basic declaration defines a mounted filesystem including
its device name, mount point, and all the volumes and access
permissions.  FSinfo reads this information and builds an internal map
of the entire network of hosts.  Using this map, many different data
formats can be produced including `/etc/fstab', `/etc/exports', Amd
mount maps and `/etc/bootparams'.

Using FSinfo
============

   The basic strategy when using FSinfo is to gather all the
information about all disks on all machines into one set of
declarations.  For each machine being managed, the following data is
required:

   * Hostname

   * List of all filesystems and, optionally, their mount points.

   * Names of volumes stored on each filesystem.

   * NFS export information for each volume.

   * The list of static filesystem mounts.

   The following information can also be entered into the same
configuration files so that all data can be kept in one place.

   * List of network interfaces

   * IP address of each interface

   * Hardware address of each interface

   * Dumpset to which each filesystem belongs

   * and more ...

   To generate Amd mount maps, the automount tree must also be defined
(see FSinfo automount definitions).  This will have been designed at
the time the volume names were allocated.  Some volume names will not be
automounted, so FSinfo needs an explicit list of which volumes should
be automounted.

   Hostnames are required at several places in the FSinfo language.  It
is important to stick to either fully qualified names or unqualified
names.  Using a mixture of the two will inevitably result in confusion.

   Sometimes volumes need to be referenced which are not defined in the
set of hosts being managed with FSinfo.  The required action is to add a
dummy set of definitions for the host and volume names required.  Since
the files generated for those particular hosts will not be used on them,
the exact values used is not critical.

FSinfo grammar
==============

   FSinfo has a relatively simple grammar.  Distinct syntactic
constructs exist for each of the different types of data, though they
share a common flavor.  Several conventions are used in the grammar
fragments below.

   The notation, list(xxx), indicates a list of zero or more xxx's.
The notation, opt(xxx), indicates zero or one xxx.  Items in double
quotes, eg "host", represent input tokens.  Items in angle brackets, eg
<HOSTNAME>, represent strings in the input.  Strings need not be in
double quotes, except to differentiate them from reserved words.
Quoted strings may include the usual set of C "\" escape sequences with
one exception: a backslash-newline-whitespace sequence is squashed into
a single space character.  To defeat this feature, put a further
backslash at the start of the second line.

   At the outermost level of the grammar, the input consists of a
sequence of host and automount declarations.  These declarations are
all parsed before they are analyzed.  This means they can appear in any
order and cyclic host references are possible.

     fsinfo      : list(fsinfo_attr) ;

     fsinfo_attr : host | automount ;

FSinfo host definitions
=======================

   A host declaration consists of three parts: a set of machine
attribute data, a list of filesystems physically attached to the
machine, and a list of additional statically mounted filesystems.

     host        : "host" host_data list(filesystem) list(mount) ;

   Each host must be declared in this way exactly once.  Such things as
the hardware address, the architecture and operating system types and
the cluster name are all specified within the "host data".

   All the disks the machine has should then be described in the "list
of filesystems".  When describing disks, you can specify what "volname"
the disk/partition should have and all such entries are built up into a
dictionary which can then be used for building the automounter maps.

   The "list of mounts" specifies all the filesystems that should be
statically mounted on the machine.

FSinfo host attributes
======================

   The host data, "host_data", always includes the "hostname".  In
addition, several other host attributes can be given.

     host_data   : <HOSTNAME>
                 | "{" list(host_attrs) "}" <HOSTNAME>
                 ;

     host_attrs  : host_attr "=" <STRING>
                 | netif
                 ;

     host_attr   : "config"
                 | "arch"
                 | "os"
                 | "cluster"
                 ;

   The "hostname" is, typically, the fully qualified hostname of the
machine.

   Examples:

     host dylan.doc.ic.ac.uk

     host {
         os = hpux
         arch = hp300
     } dougal.doc.ic.ac.uk

   The options that can be given as host attributes are shown below.

netif Option
------------

   This defines the set of network interfaces configured on the machine.
The interface attributes collected by FSinfo are the IP address, subnet
mask and hardware address.  Multiple interfaces may be defined for
hosts with several interfaces by an entry for each interface.  The
values given are sanity checked, but are currently unused for anything
else.

     netif       : "netif" <STRING> "{" list(netif_attrs) "}" ;

     netif_attrs : netif_attr "=" <STRING> ;

     netif_attr  : "inaddr" | "netmask" | "hwaddr" ;

   Examples:

     netif ie0 {
         inaddr  = 129.31.81.37
         netmask = 0xfffffe00
         hwaddr  = "08:00:20:01:a6:a5"
     }

     netif ec0 { }

config Option
-------------

   This option allows you to specify configuration variables for the
startup scripts (`rc' scripts).  A simple string should immediately
follow the keyword.

   Example:

     config "NFS_SERVER=true"
     config "ZEPHYR=true"

   This option is currently unsupported.

arch Option
-----------

   This defines the architecture of the machine.  For example:

     arch = hp300

   This is intended to be of use when building architecture specific
mountmaps, however, the option is currently unsupported.

os Option
---------

   This defines the operating system type of the host.  For example:

     os = hpux

   This information is used when creating the `fstab' files, for
example in choosing which format to use for the `fstab' entries within
the file.

cluster Option
--------------

   This is used for specifying in which cluster the machine belongs.
For example:

     cluster = "theory"

   The cluster is intended to be used when generating the automount
maps, although it is currently unsupported.

FSinfo filesystems
==================

   The list of physically attached filesystems follows the machine
attributes.  These should define all the filesystems available from this
machine, whether exported or not.  In addition to the device name,
filesystems have several attributes, such as filesystem type, mount
options, and `fsck' pass number which are needed to generate `fstab'
entries.

     filesystem  : "fs" <DEVICE> "{" list(fs_data) "}" ;

     fs_data     : fs_data_attr "=" <STRING>
                 | mount
                 ;

     fs_data_attr
                 : "fstype" | "opts" | "passno"
                 | "freq" | "dumpset" | "log"
                 ;

   Here, <DEVICE> is the device name of the disk (for example,
`/dev/dsk/2s0').  The device name is used for building the mount maps
and for the `fstab' file.  The attributes that can be specified are
shown in the following section.

   The FSinfo configuration file for `dylan.doc.ic.ac.uk' is listed
below.

     host dylan.doc.ic.ac.uk

     fs /dev/dsk/0s0 {
             fstype = swap
     }

     fs /dev/dsk/0s0 {
             fstype = hfs
             opts = rw,noquota,grpid
             passno = 0;
             freq = 1;
             mount / { }
     }

     fs /dev/dsk/1s0 {
             fstype = hfs
             opts = defaults
             passno = 1;
             freq = 1;
             mount /usr {
                     local {
                             exportfs "dougal eden dylan zebedee brian"
                             volname /nfs/hp300/local
                     }
             }
     }

     fs /dev/dsk/2s0 {
             fstype = hfs
             opts = defaults
             passno = 1;
             freq = 1;
             mount default {
                     exportfs "toytown_clients hangers_on"
                     volname /home/dylan/dk2
             }
     }

     fs /dev/dsk/3s0 {
             fstype = hfs
             opts = defaults
             passno = 1;
             freq = 1;
             mount default {
                     exportfs "toytown_clients hangers_on"
                     volname /home/dylan/dk3
             }
     }

     fs /dev/dsk/5s0 {
             fstype = hfs
             opts = defaults
             passno = 1;
             freq = 1;
             mount default {
                     exportfs "toytown_clients hangers_on"
                     volname /home/dylan/dk5
             }
     }

fstype Option
-------------

   This specifies the type of filesystem being declared and will be
placed into the `fstab' file as is.  The value of this option will be
handed to `mount' as the filesystem type--it should have such values as
`4.2', `nfs' or `swap'.  The value is not examined for correctness.

   There is one special case.  If the filesystem type is specified as
`export' then the filesystem information will not be added to the
host's `fstab' information, but it will still be visible on the
network.  This is useful for defining hosts which contain referenced
volumes but which are not under full control of FSinfo.

   Example:

     fstype = swap

opts Option
-----------

   This defines any options that should be given to mount(8) in the
`fstab' file.  For example:

     opts = rw,nosuid,grpid

passno Option
-------------

   This defines the fsck(8) pass number in which to check the
filesystem.  This value will be placed into the `fstab' file.

   Example:

     passno = 1

freq Option
-----------

   This defines the interval (in days) between dumps.  The value is
placed as is into the `fstab' file.

   Example:

     freq = 3

mount Option
------------

   This defines the mountpoint at which to place the filesystem.  If the
mountpoint of the filesystem is specified as `default', then the
filesystem will be mounted in the automounter's tree under its volume
name and the mount will automatically be inherited by the automounter.

   Following the mountpoint, namespace information for the filesystem
may be described.  The options that can be given here are `exportfs',
`volname' and `sel'.

   The format is:

     mount       : "mount" vol_tree ;

     vol_tree    : list(vol_tree_attr) ;

     vol_tree_attr
                 :  <STRING> "{" list(vol_tree_info) vol_tree "}" ;

     vol_tree_info
                 : "exportfs" <EXPORT-DATA>
                 | "volname" <VOLNAME>
                 | "sel" <SELECTOR-LIST>
                 ;

   Example:

     mount default {
         exportfs "dylan dougal florence zebedee"
         volname /vol/andrew
     }

   In the above example, the filesystem currently being declared will
have an entry placed into the `exports' file allowing the filesystem to
be exported to the machines `dylan', `dougal', `florence' and
`zebedee'.  The volume name by which the filesystem will be referred to
remotely, is `/vol/andrew'.  By declaring the mountpoint to be
`default', the filesystem will be mounted on the local machine in the
automounter tree, where Amd will automatically inherit the mount as
`/vol/andrew'.

`exportfs'
     a string defining which machines the filesystem may be exported to.
     This is copied, as is, into the `exports' file--no sanity checking
     is performed on this string.

`volname'
     a string which declares the remote name by which to reference the
     filesystem.  The string is entered into a dictionary and allows
     you to refer to this filesystem in other places by this volume
     name.

`sel'
     a string which is placed into the automounter maps as a selector
     for the filesystem.

dumpset Option
--------------

   This provides support for Imperial College's local file backup tools
and is not documented further here.

log Option
----------

   Specifies the log device for the current filesystem. This is ignored
if not required by the particular filesystem type.

FSinfo static mounts
====================

   Each host may also have a number of statically mounted filesystems.
For example, the host may be a diskless workstation in which case it
will have no `fs' declarations.  In this case the `mount' declaration
is used to determine from where its filesystems will be mounted.  In
addition to being added to the `fstab' file, this information can also
be used to generate a suitable `bootparams' file.

     mount       : "mount" <VOLNAME> list(localinfo) ;

     localinfo   : localinfo_attr <STRING> ;

     localinfo_attr
                 : "as"
                 | "from"
                 | "fstype"
                 | "opts"
                 ;

   The filesystem specified to be mounted will be searched for in the
dictionary of volume names built when scanning the list of hosts'
definitions.

   The attributes have the following semantics:
`from MACHINE'
     mount the filesystem from the machine with the hostname of
     "machine".

`as MOUNTPOINT'
     mount the filesystem locally as the name given, in case this is
     different from the advertised volume name of the filesystem.

`opts OPTIONS'
     native mount(8) options.

`fstype TYPE'
     type of filesystem to be mounted.

   An example:

     mount /export/exec/hp300/local as /usr/local

   If the mountpoint specified is either `/' or `swap', the machine
will be considered to be booting off the net and this will be noted for
use in generating a `bootparams' file for the host which owns the
filesystems.

Defining an Amd Mount Map in FSinfo
===================================

   The maps used by Amd can be constructed from FSinfo by defining all
the automount trees.  FSinfo takes all the definitions found and builds
one map for each top level tree.

   The automount tree is usually defined last.  A single automount
configuration will usually apply to an entire management domain.  One
`automount' declaration is needed for each Amd automount point.  FSinfo
determines whether the automount point is "direct" (see Direct Automount Filesystem)
or "indirect" (see Top-level Filesystem).
Direct automount points are distinguished by the fact that there is no
underlying "automount_tree".

     automount   : "automount" opt(auto_opts) automount_tree ;

     auto_opts   : "opts" <MOUNT-OPTIONS> ;

     automount_tree
                 : list(automount_attr)
                 ;

     automount_attr
                 : <STRING> "=" <VOLNAME>
                 | <STRING> "->" <SYMLINK>
                 | <STRING> "{" automount_tree "}"
                 ;

   If <MOUNT-OPTIONS> is given, then it is the string to be placed in
the maps for Amd for the `opts' option.

   A "map" is typically a tree of filesystems, for example `home'
normally contains a tree of filesystems representing other machines in
the network.

   A map can either be given as a name representing an already defined
volume name, or it can be a tree.  A tree is represented by placing
braces after the name.  For example, to define a tree `/vol', the
following map would be defined:

     automount /vol { }

   Within a tree, the only items that can appear are more maps.  For
example:

     automount /vol {
         andrew { }
         X11 { }
     }

   In this case, FSinfo will look for volumes named `/vol/andrew' and
`/vol/X11' and a map entry will be generated for each.  If the volumes
are defined more than once, then FSinfo will generate a series of
alternate entries for them in the maps.

   Instead of a tree, either a link (NAME `->' DESTINATION) or a
reference can be specified (NAME `=' DESTINATION).  A link creates a
symbolic link to the string specified, without further processing the
entry.  A reference will examine the destination filesystem and
optimize the reference.  For example, to create an entry for `njw' in
the `/homes' map, either of the two forms can be used:

     automount /homes {
         njw -> /home/dylan/njw
     }

   or

     automount /homes {
         njw = /home/dylan/njw
     }

   In the first example, when `/homes/njw' is referenced from Amd, a
link will be created leading to `/home/dylan/njw' and the automounter
will be referenced a second time to resolve this filename.  The map
entry would be:

     njw type:=link;fs:=/home/dylan/njw

   In the second example, the destination directory is analyzed and
found to be in the filesystem `/home/dylan' which has previously been
defined in the maps. Hence the map entry will look like:

     njw rhost:=dylan;rfs:=/home/dylan;sublink:=njw

   Creating only one symbolic link, and one access to Amd.

FSinfo Command Line Options
===========================

   FSinfo is started from the command line by using the command:

     fsinfo [options] files ...

   The input to FSinfo is a single set of definitions of machines and
automount maps.  If multiple files are given on the command-line, then
the files are concatenated together to form the input source.  The files
are passed individually through the C pre-processor before being parsed.

   Several options define a prefix for the name of an output file.  If
the prefix is not specified no output of that type is produced.  The
suffix used will correspond either to the hostname to which a file
belongs, or to the type of output if only one file is produced.
Dumpsets and the `bootparams' file are in the latter class.  To put the
output into a subdirectory simply put a `/' at the end of the prefix,
making sure that the directory has already been made before running
Fsinfo.

`-a' AUTODIR
------------

   Specifies the directory name in which to place the automounter's
mountpoints.  This defaults to `/a'.  Some sites have the autodir set
to be `/amd', and this would be achieved by:

     fsinfo -a /amd ...

`-b' BOOTPARAMS
---------------

   This specifies the prefix for the `bootparams' filename.  If it is
not given, then the file will not be generated.  The `bootparams' file
will be constructed for the destination machine and will be placed into
a file named `bootparams' and prefixed by this string.  The file
generated contains a list of entries describing each diskless client
that can boot from the destination machine.

   As an example, to create a `bootparams' file in the directory
`generic', the following would be used:

     fsinfo -b generic/ ...

`-d' DUMPSETS
-------------

   This specifies the prefix for the `dumpsets' file.  If it is not
specified, then the file will not be generated.  The file will be for
the destination machine and will be placed into a filename `dumpsets',
prefixed by this string.  The `dumpsets' file is for use by Imperial
College's local backup system.

   For example, to create a `dumpsets' file in the directory `generic',
then you would use the following:

     fsinfo -d generic/ ...

`-e' EXPORTFS
-------------

   Defines the prefix for the `exports' files.  If it is not given,
then the file will not be generated.  For each machine defined in the
configuration files as having disks, an `exports' file is constructed
and given a filename determined by the name of the machine, prefixed
with this string.  If a machine is defined as diskless, then no
`exports' file will be created for it.  The files contain entries for
directories on the machine that may be exported to clients.

   Example: To create the `exports' files for each diskfull machine and
place them into the directory `exports':

     fsinfo -e exports/ ...

`-f' FSTAB
----------

   This defines the prefix for the `fstab' files.  The files will only
be created if this prefix is defined.  For each machine defined in the
configuration files, a `fstab' file is created with the filename
determined by prefixing this string with the name of the machine.  These
files contain entries for filesystems and partitions to mount at boot
time.

   Example, to create the files in the directory `fstabs':

     fsinfo -f fstabs/ ...

`-h' HOSTNAME
-------------

   Defines the hostname of the destination machine to process for.  If
this is not specified, it defaults to the local machine name, as
returned by gethostname(2).

   Example:

     fsinfo -h dylan.doc.ic.ac.uk ...

`-m' MOUNT-MAPS
---------------

   Defines the prefix for the automounter files.  The maps will only be
produced if this prefix is defined.  The mount maps suitable for the
network defined by the configuration files will be placed into files
with names calculated by prefixing this string to the name of each map.

   For example, to create the automounter maps and place them in the
directory `automaps':

     fsinfo -m automaps/ ...

`-q'
----

   Selects quiet mode.  FSinfo suppress the "running commentary" and
only outputs any error messages which are generated.

`-v'
----

   Selects verbose mode.  When this is activated, the program will
display more messages, and display all the information discovered when
performing the semantic analysis phase.  Each verbose message is output
to `stdout' on a line starting with a `#' character.

`-D' NAME[=defn]
----------------

   Defines a symbol "name" for the preprocessor when reading the
configuration files.  Equivalent to `#define' directive.

`-I' DIRECTORY
--------------

   This option is passed into the preprocessor for the configuration
files.  It specifies directories in which to find include files

`-U' NAME
---------

   Removes any initial definition of the symbol "name".  Inverse of the
`-D' option.