This is am-utils.info, produced by makeinfo version 4.1 from
am-utils.texi.

INFO-DIR-SECTION Administration
START-INFO-DIR-ENTRY
* Am-utils: (am-utils).          The Amd automounter suite of utilities
END-INFO-DIR-ENTRY


File: am-utils.info,  Node: Network Filesystem,  Next: Network Host Filesystem,  Prev: Filesystem Types,  Up: Filesystem Types

Network Filesystem (`nfs')
==========================

   The "nfs" (`type:=nfs') filesystem type provides access to Sun's NFS.

The following options must be specified:

`rhost'
     the remote fileserver.  This must be an entry in the hosts
     database.  IP addresses are not accepted.  The default value is
     taken from the local host name (`${host}') if no other value is
     specified.

`rfs'
     the remote filesystem.  If no value is specified for this option,
     an internal default of `${path}' is used.

   NFS mounts require a two stage process.  First, the "file handle" of
the remote file system must be obtained from the server.  Then a mount
system call must be done on the local system.  Amd keeps a cache of
file handles for remote file systems.  The cache entries have a
lifetime of a few minutes.

   If a required file handle is not in the cache, Amd sends a request
to the remote server to obtain it.  Amd "does not" wait for a response;
it notes that one of the locations needs retrying, but continues with
any remaining locations.  When the file handle becomes available, and
assuming none of the other locations was successfully mounted, Amd will
retry the mount.  This mechanism allows several NFS filesystems to be
mounted in parallel.  The first one which responds with a valid file
handle will be used.

An NFS entry might be:

     jsp  host!=charm;type:=nfs;rhost:=charm;rfs:=/home/charm;sublink:=jsp

   The mount system call and any unmount attempts are always done in a
new task to avoid the possibility of blocking Amd.


File: am-utils.info,  Node: Network Host Filesystem,  Next: Network Filesystem Group,  Prev: Network Filesystem,  Up: Filesystem Types

Network Host Filesystem (`host')
================================

   The "host" (`type:=host') filesystem allows access to the entire
export tree of an NFS server.  The implementation is layered above the
`nfs' implementation so keep-alives work in the same way.  The only
option which needs to be specified is `rhost' which is the name of the
fileserver to mount.

   The `host' filesystem type works by querying the mount daemon on the
given fileserver to obtain its export list.  Amd then obtains
filehandles for each of the exported filesystems.  Any errors at this
stage cause that particular filesystem to be ignored.  Finally each
filesystem is mounted.  Again, errors are logged but ignored.  One
common reason for mounts to fail is that the mount point does not exist.
Although Amd attempts to automatically create the mount point, it may
be on a remote filesystem to which Amd does not have write permission.

   When an attempt to unmount a `host' filesystem mount fails, Amd
remounts any filesystems which had successfully been unmounted.  To do
this Amd queries the mount daemon again and obtains a fresh copy of the
export list.  Amd then tries to mount any exported filesystems which
are not currently mounted.

   Sun's automounter provides a special `-hosts' map.  To achieve the
same effect with Amd requires two steps.  First a mount map must be
created as follows:

     *       type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root

and then start Amd with the following command

     amd /net net.map

where `net.map' is the name of map described above.  Note that the
value of `${fs}' is overridden in the map.  This is done to avoid a
clash between the mount tree and any other filesystem already mounted
from the same fileserver.

   If different mount options are needed for different hosts then
additional entries can be added to the map, for example

     host2       opts:=ro,nosuid,soft

would soft mount `host2' read-only.


File: am-utils.info,  Node: Network Filesystem Group,  Next: Unix Filesystem,  Prev: Network Host Filesystem,  Up: Filesystem Types

Network Filesystem Group (`nfsx')
=================================

   The "nfsx" (`type:=nfsx') filesystem allows a group of filesystems
to be mounted from a single NFS server.  The implementation is layered
above the `nfs' implementation so keep-alives work in the same way.

   The options are the same as for the `nfs' filesystem with one
difference.

The following options should be specified:

`rhost'
     the remote fileserver.  The default value is taken from the local
     host name (`${host}') if no other value is specified.

`rfs'
     is a list of filesystems to mount, and must be specified.  The
     list is in the form of a comma separated strings.

For example:

     pub  type:=nfsx;rhost:=gould;\
          rfs:=/public,/,graphics,usenet;fs:=${autodir}/${rhost}/root

   The first string defines the root of the tree, and is applied as a
prefix to the remaining members of the list which define the individual
filesystems.  The first string is _not_ used as a filesystem name.  A
parallel operation is used to determine the local mount points to
ensure a consistent layout of a tree of mounts.

   Here, the _three_ filesystems, `/public', `/public/graphics' and
`/public/usenet', would be mounted.

   A local mount point, `${fs}', _must_ be specified.  The default
local mount point will not work correctly in the general case.  A
suggestion is to use `fs:=${autodir}/${rhost}/root'.


File: am-utils.info,  Node: Unix Filesystem,  Next: Caching Filesystem,  Prev: Network Filesystem Group,  Up: Filesystem Types

Unix Filesystem (`ufs', `xfs', or `efs')
========================================

   The "ufs" (`type:=ufs') filesystem type provides access to the
system's standard disk filesystem--usually a derivative of the Berkeley
Fast Filesystem.

The following option must be specified:

`dev'
     the block special device to be mounted.

   A UFS entry might be:

     jsp   host==charm;type:=ufs;dev:=/dev/sd0d;sublink:=jsp

   UFS is the default Unix disk-based file system, which Am-utils picks
up during the autoconfiguration phase.  Some systems have more than one
type, such as IRIX, that comes with EFS (Extent File System) and XFS
(Extended File System).  In those cases, you may explicitly set the file
system type, by using entries such:

     ez1   type:=efs;dev:=/dev/xd0a
     ez2   type:=xfs;dev:=/dev/sd3c


File: am-utils.info,  Node: Caching Filesystem,  Next: CD-ROM Filesystem,  Prev: Unix Filesystem,  Up: Filesystem Types

Caching Filesystem (`cachefs')
==============================

   The "cachefs" (`type:=cachefs') filesystem caches files from one
location onto another, presumably providing faster access.  It is
particularly useful to cache from a larger and remote (slower) NFS
partition to a smaller and local (faster) UFS directory.

The following options must be specified:

`cachedir'
     the directory where the cache is stored.

`rfs'
     the path name to the "back file system" to be cached from.

`fs'
     the "front file system" mount point to the cached files, where Amd
     will set a symbolic link pointing to.

   A CacheFS entry for, say, the `/import' Amd mount point, might be:

     copt  type:=cachefs;cachedir:=/cache;rfs:=/import/opt;fs:=/n/import/copt

   Access to the pathname `/import/copt' will follow a symbolic link to
`/n/import/copt'.  The latter is the mount point for a caching file
system, that caches from `/import/opt' to `/cache'.

   Caveats:
  1. This file system is currently only implemented for Solaris 2.x!

  2. Before being used for the first time, the cache directory must be
     initialized with `cfsadmin -c CACHEDIR'.  See the manual page for
     cfsadmin(1M) for more information.

  3. The "back file system" mounted must be a complete file system, not
     a subdirectory thereof; otherwise you will get an error "Invalid
     Argument".

  4. If Amd aborts abnormally, the state of the cache may be
     inconsistent, requiring running the command `fsck -F cachefs
     CACHEDIR'.  Otherwise you will get the error "No Space Left on
     Device".


File: am-utils.info,  Node: CD-ROM Filesystem,  Next: Loopback Filesystem,  Prev: Caching Filesystem,  Up: Filesystem Types

CD-ROM Filesystem (`cdfs')
==========================

   The "cdfs" (`type:=cdfs') filesystem mounts a CD-ROM with an ISO9660
format filesystem on it.

The following option must be specified:

`dev'
     the block special device to be mounted.

   Some operating systems will fail to mount read-only CDs unless the
`ro' option is specified.  A cdfs entry might be:

     cdfs      os==sunos4;type:=cdfs;dev:=/dev/sr0 \
               os==sunos5;addopts:=ro;type:=cdfs;dev:=/dev/dsk/c0t6d0s2


File: am-utils.info,  Node: Loopback Filesystem,  Next: Memory/RAM Filesystem,  Prev: CD-ROM Filesystem,  Up: Filesystem Types

Loopback Filesystem (`lofs')
============================

   The "lofs" (`type:=lofs') filesystem is also called the loopback
filesystem.  It mounts a local directory on another, thus providing
mount-time binding to another location (unlike symbolic links).

   The loopback filesystem is particularly useful within the context of
a chroot-ed directory (via chroot(2)), to provide access to directories
otherwise inaccessible.

The following option must be specified:

`rfs'
     the pathname to be mounted on top of `${fs}'.

   Usually, the FTP server runs in a chroot-ed environment, for security
reasons.  In this example, lofs is used to provide a subdirectory within
a user's home directory, also available for public ftp.

     lofs      type:=lofs;rfs:=/home/ezk/myftpdir;fs:=/usr/ftp/pub/ezk


File: am-utils.info,  Node: Memory/RAM Filesystem,  Next: Null Filesystem,  Prev: Loopback Filesystem,  Up: Filesystem Types

Memory/RAM Filesystem (`mfs')
=============================

   The "mfs" (`type:=mfs') filesystem is available in 4.4BSD, Linux,
and other systems.  It creates a filesystem in a portion of the
system's memory, thus providing very fast file (volatile) access.

   XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!


File: am-utils.info,  Node: Null Filesystem,  Next: Floppy Filesystem,  Prev: Memory/RAM Filesystem,  Up: Filesystem Types

Null Filesystem (`nullfs')
==========================

   The "nullfs" (`type:=nullfs') filesystem is available from 4.4BSD,
and is very similar to the loopback filesystem, "lofs".

   XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!


File: am-utils.info,  Node: Floppy Filesystem,  Next: Translucent Filesystem,  Prev: Null Filesystem,  Up: Filesystem Types

Floppy Filesystem (`pcfs')
==========================

   The "pcfs" (`type:=pcfs') filesystem mounts a floppy previously
formatted for the MS-DOS format.

The following option must be specified:

`dev'
     the block special device to be mounted.

   A pcfs entry might be:

     pcfs      os==sunos4;type:=pcfs;dev:=/dev/fd0 \
               os==sunos5;type:=pcfs;dev:=/dev/diskette


File: am-utils.info,  Node: Translucent Filesystem,  Next: Shared Memory+Swap Filesystem,  Prev: Floppy Filesystem,  Up: Filesystem Types

Translucent Filesystem (`tfs')
==============================

   The "tfs" (`type:=tfs') filesystem is an older version of the 4.4BSD
"unionfs".

   XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!


File: am-utils.info,  Node: Shared Memory+Swap Filesystem,  Next: User ID Mapping Filesystem,  Prev: Translucent Filesystem,  Up: Filesystem Types

Shared Memory+Swap Filesystem (`tmpfs')
=======================================

   The "tmpfs" (`type:=tmpfs') filesystem shares memory between a the
swap device and the rest of the system.  It is generally used to
provide a fast access `/tmp' directory, one that uses memory that is
otherwise unused.  This filesystem is available in SunOS 4.x and 5.x.

   XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!


File: am-utils.info,  Node: User ID Mapping Filesystem,  Next: Program Filesystem,  Prev: Shared Memory+Swap Filesystem,  Up: Filesystem Types

User ID Mapping Filesystem (`umapfs')
=====================================

   The "umapfs" (`type:=umapfs') filesystem maps User IDs of file
ownership, and is available from 4.4BSD.

   XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!


File: am-utils.info,  Node: Program Filesystem,  Next: Symbolic Link Filesystem,  Prev: User ID Mapping Filesystem,  Up: Filesystem Types

Program Filesystem (`program')
==============================

   The "program" (`type:=program') filesystem type allows a program to
be run whenever a mount or unmount is required.  This allows easy
addition of support for other filesystem types, such as MIT's Remote
Virtual Disk (RVD) which has a programmatic interface via the commands
`rvdmount' and `rvdunmount'.

The following options must be specified:

`mount'
     the program which will perform the mount.

`unmount'
     the program which will perform the unmount.

   The exit code from these two programs is interpreted as a Unix error
code.  As usual, exit code zero indicates success.  To execute the
program Amd splits the string on whitespace to create an array of
substrings.  Single quotes `'' can be used to quote whitespace if that
is required in an argument.  There is no way to escape or change the
quote character.

   To run the program `rvdmount' with a host name and filesystem as
arguments would be specified by
`fs:=${autodir}${path};mount:="/etc/rvdmount rvdmount fserver ${fs}"'.

   The first element in the array is taken as the pathname of the
program to execute.  The other members of the array form the argument
vector to be passed to the program, "including argument zero".  This
means that the split string must have at least two elements.  The
program is directly executed by Amd, not via a shell.  This means that
scripts must begin with a `#!' interpreter specification.

   If a filesystem type is to be heavily used, it may be worthwhile
adding a new filesystem type into Amd, but for most uses the program
filesystem should suffice.

   When the program is run, standard input and standard error are
inherited from the current values used by Amd.  Standard output is a
duplicate of standard error.  The value specified with the `-l' command
line option has no effect on standard error.


File: am-utils.info,  Node: Symbolic Link Filesystem,  Next: Symbolic Link Filesystem II,  Prev: Program Filesystem,  Up: Filesystem Types

Symbolic Link Filesystem (`link')
=================================

   Each filesystem type creates a symbolic link to point from the volume
name to the physical mount point.  The `link' filesystem does the same
without any other side effects.  This allows any part of the machines
name space to be accessed via Amd.

   One common use for the symlink filesystem is `/homes' which can be
made to contain an entry for each user which points to their
(auto-mounted) home directory.  Although this may seem rather expensive,
it provides a great deal of administrative flexibility.

The following option must be defined:

`fs'
     The value of FS option specifies the destination of the link, as
     modified by the SUBLINK option.  If SUBLINK is non-null, it is
     appended to `${fs}'`/' and the resulting string is used as the
     target.

   The `link' filesystem can be thought of as identical to the `ufs'
filesystem but without actually mounting anything.

   An example entry might be:

     jsp   host==charm;type:=link;fs:=/home/charm;sublink:=jsp
   which would return a symbolic link pointing to `/home/charm/jsp'.


File: am-utils.info,  Node: Symbolic Link Filesystem II,  Next: NFS-Link Filesystem,  Prev: Symbolic Link Filesystem,  Up: Filesystem Types

Symbolic Link Filesystem II (`linkx')
=====================================

   The "linkx" (`type:=linkx') filesystem type is identical to `link'
with the exception that the target of the link must exist.  Existence
is checked with the lstat(2) system call.

   The `linkx' filesystem type is particularly useful for wildcard map
entries.  In this case, a list of possible targets can be given and Amd
will choose the first one which exists on the local machine.


File: am-utils.info,  Node: NFS-Link Filesystem,  Next: Automount Filesystem,  Prev: Symbolic Link Filesystem II,  Up: Filesystem Types

NFS-Link Filesystem (`nfsl')
============================

   The "nfsl" (`type:=nfsl') filesystem type is a combination of two
others: `link' and `nfs'.  If the local host name is equal to the value
of `${rhost}', or if the target pathname listed in `${fs}' exists,
`nfsl' will behave exactly as `type:=link', and refer to the target as
a symbolic link.  If the local host name is not equal to the value of
`${rhost}', or if the target of the link does not exist, Amd will treat
it as `type:=nfs', and will mount a remote pathname for it.

   The `nfsl' filesystem type is particularly useful as a shorthand for
the more cumbersome and yet one of the most popular Amd entries.  For
example, you can simplify all map entries that look like:

     zing    -fs:=/n/shekel/u/zing \
             host!=shekel;type:=nfs;rhost:=shekel;rfs:=${fs} \
             host==shekel;type:=link

   or

     zing    -fs:=/n/shekel/u/zing \
             exists(${fs});type:=link \
             !exists(${fs});type:=nfs;rhost:=shekel;rfs:=${fs}

   into a shorter form

     zing    type:=nfsl;fs:=/n/shekel/u/zing;rhost:=shekel;rfs:=${fs}

   Not just does it make the maps smaller and simpler, but it avoids
possible mistakes that often happen when forgetting to set up the two
entries (one for `type:=nfs' and the other for `type:=link') necessary
to perform transparent mounts of existing or remote mounts.


File: am-utils.info,  Node: Automount Filesystem,  Next: Direct Automount Filesystem,  Prev: NFS-Link Filesystem,  Up: Filesystem Types

Automount Filesystem (`auto')
=============================

   The "auto" (`type:=auto') filesystem type creates a new automount
point below an existing automount point.  Top-level automount points
appear as system mount points.  An automount mount point can also
appear as a sub-directory of an existing automount point.  This allows
some additional structure to be added, for example to mimic the mount
tree of another machine.

   The following options may be specified:

`cache'
     specifies whether the data in this mount-map should be cached.
     The default value is `none', in which case no caching is done in
     order to conserve memory.

     However, better performance and reliability can be obtained by
     caching some or all of a mount-map.

     If the cache option specifies `all', the entire map is enumerated
     when the mount point is created.

     If the cache option specifies `inc', caching is done incrementally
     as and when data is required.  Some map types do not support cache
     mode `all', in which case `inc' is used whenever `all' is
     requested.

     Caching can be entirely disabled by using cache mode `none'.

     If the cache option specifies `regexp' then the entire map will be
     enumerated and each key will be treated as an egrep-style regular
     expression.  The order in which a cached map is searched does not
     correspond to the ordering in the source map so the regular
     expressions should be mutually exclusive to avoid confusion.

     Each mount map type has a default cache type, usually `inc', which
     can be selected by specifying `mapdefault'.

     The cache mode for a mount map can only be selected on the command
     line.  Starting Amd with the command:

          amd /homes hesiod.homes -cache:=inc

     will cause `/homes' to be automounted using the "Hesiod" name
     server with local incremental caching of all successfully resolved
     names.

     All cached data is forgotten whenever Amd receives a `SIGHUP'
     signal and, if cache `all' mode was selected, the cache will be
     reloaded.  This can be used to inform Amd that a map has been
     updated.  In addition, whenever a cache lookup fails and Amd needs
     to examine a map, the map's modify time is examined.  If the cache
     is out of date with respect to the map then it is flushed as if a
     `SIGHUP' had been received.

     An additional option (`sync') may be specified to force Amd to
     check the map's modify time whenever a cached entry is being used.
     For example, an incremental, synchronized cache would be created
     by the following command:

          amd /homes hesiod.homes -cache:=inc,sync

`fs'
     specifies the name of the mount map to use for the new mount point.

     Arguably this should have been specified with the `${rfs}' option
     but we are now stuck with it due to historical accident.

`pref'
     alters the name that is looked up in the mount map.  If `${pref}',
     the "prefix", is non-null then it is prepended to the name
     requested by the kernel "before" the map is searched.

`opts'
     Normally, `auto' style maps are not browsable even if you turn on
     directory browsability (*note browsable_dirs Parameter::).  To
     enable browsing entries in `auto' maps, specify `opts:=browsable'
     in the description of this map.

   The server `dylan.doc.ic.ac.uk' has two user disks: `/dev/dsk/2s0'
and `/dev/dsk/5s0'.  These are accessed as `/home/dylan/dk2' and
`/home/dylan/dk5' respectively.  Since `/home' is already an automount
point, this naming is achieved with the following map entries:

     dylan        type:=auto;fs:=${map};pref:=${key}/
     dylan/dk2    type:=ufs;dev:=/dev/dsk/2s0
     dylan/dk5    type:=ufs;dev:=/dev/dsk/5s0


File: am-utils.info,  Node: Direct Automount Filesystem,  Next: Union Filesystem,  Prev: Automount Filesystem,  Up: Filesystem Types

Direct Automount Filesystem (`direct')
======================================

   The "direct" (`type:=direct') filesystem is almost identical to the
automount filesystem.  Instead of appearing to be a directory of mount
points, it appears as a symbolic link to a mounted filesystem.  The
mount is done at the time the link is accessed.  *Note Automount
Filesystem::, for a list of required options.

   Direct automount points are created by specifying the `direct'
filesystem type on the command line:

     amd ... /usr/man auto.direct -type:=direct

   where `auto.direct' would contain an entry such as:

     usr/man    -type:=nfs;rfs:=/usr/man \
                rhost:=man-server1  rhost:=man-server2

   In this example, `man-server1' and `man-server2' are file servers
which export copies of the manual pages.  Note that the key which is
looked up is the name of the automount point without the leading `/'.


File: am-utils.info,  Node: Union Filesystem,  Next: Error Filesystem,  Prev: Direct Automount Filesystem,  Up: Filesystem Types

Union Filesystem (`union')
==========================

   The "union" (`type:=union') filesystem type allows the contents of
several directories to be merged and made visible in a single
directory.  This can be used to overcome one of the major limitations
of the Unix mount mechanism which only allows complete directories to
be mounted.

   For example, supposing `/tmp' and `/var/tmp' were to be merged into
a new directory called `/mtmp', with files in `/var/tmp' taking
precedence.  The following command could be used to achieve this effect:

     amd ... /mtmp union:/tmp:/var/tmp -type:=union

   Currently, the unioned directories must _not_ be automounted.  That
would cause a deadlock.  This seriously limits the current usefulness of
this filesystem type and the problem will be addressed in a future
release of Amd.

   Files created in the union directory are actually created in the last
named directory.  This is done by creating a wildcard entry which points
to the correct directory.  The wildcard entry is visible if the union
directory is listed, so allowing you to see which directory has
priority.

   The files visible in the union directory are computed at the time
Amd is started, and are not kept up-to-date with respect to the
underlying directories.  Similarly, if a link is removed, for example
with the `rm' command, it will be lost forever.


File: am-utils.info,  Node: Error Filesystem,  Next: Top-level Filesystem,  Prev: Union Filesystem,  Up: Filesystem Types

Error Filesystem (`error')
==========================

   The "error" (`type:=error') filesystem type is used internally as a
catch-all in the case where none of the other filesystems was selected,
or some other error occurred.  Lookups and mounts always fail with "No
such file or directory".  All other operations trivially succeed.

   The error filesystem is not directly accessible.


File: am-utils.info,  Node: Top-level Filesystem,  Next: Root Filesystem,  Prev: Error Filesystem,  Up: Filesystem Types

Top-level Filesystem (`toplvl')
===============================

   The "toplvl" (`type:=toplvl') filesystems is derived from the `auto'
filesystem and is used to mount the top-level automount nodes.
Requests of this type are automatically generated from the command line
arguments.


File: am-utils.info,  Node: Root Filesystem,  Next: Inheritance Filesystem,  Prev: Top-level Filesystem,  Up: Filesystem Types

Root Filesystem (`root')
========================

   The "root" (`type:=root') filesystem type acts as an internal
placeholder onto which Amd can pin `toplvl' mounts.  Only one node of
this type need ever exist and one is created automatically during
startup.  The effect of having more than one root node is undefined.

   The root filesystem is not directly accessible.


File: am-utils.info,  Node: Inheritance Filesystem,  Prev: Root Filesystem,  Up: Filesystem Types

Inheritance Filesystem (`inherit')
==================================

   The "inheritance" (`type:=inherit') filesystem is not directly
accessible.  Instead, internal mount nodes of this type are
automatically generated when Amd is started with the `-r' option.  At
this time the system mount table is scanned to locate any filesystems
which are already mounted.  If any reference to these filesystems is
made through Amd then instead of attempting to mount it, Amd simulates
the mount and "inherits" the filesystem.  This allows a new version of
Amd to be installed on a live system simply by killing the old daemon
with `SIGTERM' and starting the new one.

   This filesystem type is not generally visible externally, but it is
possible that the output from `amq -m' may list `inherit' as the
filesystem type.  This happens when an inherit operation cannot be
completed for some reason, usually because a fileserver is down.


File: am-utils.info,  Node: Amd Configuration File,  Next: Run-time Administration,  Prev: Filesystem Types,  Up: Top

Amd Configuration File
**********************

   The `amd.conf' file is the configuration file for Amd, as part of
the am-utils suite.  This file contains runtime configuration
information for the Amd automounter program.

* Menu:

* File Format::
* The Global Section::
* Regular Map Sections::
* Common Parameters::
* Global Parameters::
* Regular Map Parameters::
* amd.conf Examples::


File: am-utils.info,  Node: File Format,  Next: The Global Section,  Prev: Amd Configuration File,  Up: Amd Configuration File

File Format
===========

   The `amd.conf' file consists of sections and parameters.  A section
begins with the name of the section in square brackets `[]' and
continues until the next section begins or the end of the file is
reached.  Sections contain parameters of the form `name = value'.

   The file is line-based -- that is, each newline-terminated line
represents either a comment, a section name or a parameter.  No
line-continuation syntax is available.

   Section names, parameter names and their values are case sensitive.

   Only the first equals sign in a parameter is significant.  Whitespace
before or after the first equals sign is discarded.  Leading, trailing
and internal whitespace in section and parameter names is irrelevant.
Leading and trailing whitespace in a parameter value is discarded.
Internal whitespace within a parameter value is not allowed, unless the
whole parameter value is quoted with double quotes as in `name = "some
value"'.

   Any line beginning with a pound sign `#' is ignored, as are lines
containing only whitespace.

   The values following the equals sign in parameters are all either a
string (no quotes needed if string does not include spaces) or a
boolean, which may be given as `yes'/`no'.  Case is significant in all
values.  Some items such as cache timeouts are numeric.


File: am-utils.info,  Node: The Global Section,  Next: Regular Map Sections,  Prev: File Format,  Up: Amd Configuration File

The Global Section
==================

   The global section must be specified as `[global]'.  Parameters in
this section either apply to Amd as a whole, or to all other regular map
sections which follow.  There should be only one global section defined
in one configuration file.

   It is highly recommended that this section be specified first in the
configuration file.  If it is not, then regular map sections which
precede it will not use global values defined later.


File: am-utils.info,  Node: Regular Map Sections,  Next: Common Parameters,  Prev: The Global Section,  Up: Amd Configuration File

Regular Map Sections
====================

   Parameters in regular (non-global) sections apply to a single map
entry.  For example, if the map section `[/homes]' is defined, then all
parameters following it will be applied to the `/homes' Amd-managed
mount point.


File: am-utils.info,  Node: Common Parameters,  Next: Global Parameters,  Prev: Regular Map Sections,  Up: Amd Configuration File

Common Parameters
=================

   These parameters can be specified either in the global or a
map-specific section.  Entries specified in a map-specific section
override the default value or one defined in the global section.   If
such a common parameter is specified only in the global section, it is
applicable to all regular map sections that follow.

* Menu:

* browsable_dirs Parameter::
* map_options Parameter::
* map_type Parameter::
* mount_type Parameter::
* search_path Parameter::


File: am-utils.info,  Node: browsable_dirs Parameter,  Next: map_options Parameter,  Prev: Common Parameters,  Up: Common Parameters

browsable_dirs Parameter
------------------------

   (type=string, default=`no').  If `yes', then Amd's top-level mount
points will be browsable to readdir(3) calls.  This means you could run
for example ls(1) and see what keys are available to mount in that
directory.  Not all entries are made visible to readdir(3): the
`/defaults' entry, wildcard entries, and those with a `/' in them are
not included.  If you specify `full' to this option, all but the
`/defaults' entry will be visible.  Note that if you run a command
which will attempt to stat(2) the entries, such as often done by `ls
-l' or `ls -F', Amd will attempt to mount every entry in that map.
This is often called a "mount storm".


File: am-utils.info,  Node: map_options Parameter,  Next: map_type Parameter,  Prev: browsable_dirs Parameter,  Up: Common Parameters

map_options Parameter
---------------------

   (type=string, default no options).  This option is the same as
specifying map options on the command line to Amd, such as `cache:=all'.


File: am-utils.info,  Node: map_type Parameter,  Next: mount_type Parameter,  Prev: map_options Parameter,  Up: Common Parameters

map_type Parameter
------------------

   (type=string, default search all map types).  If specified, Amd will
initialize the map only for the type given.  This is useful to avoid the
default map search type used by Amd which takes longer and can have
undesired side-effects such as initializing NIS even if not used.
Possible values are

`file'
     plain files

`hesiod'
     Hesiod name service from MIT

`ldap'
     Lightweight Directory Access Protocol

`ndbm'
     (New) dbm style hash files

`nis'
     Network Information Services (version 2)

`nisplus'
     Network Information Services Plus (version 3)

`passwd'
     local password files

`union'
     union maps


File: am-utils.info,  Node: mount_type Parameter,  Next: search_path Parameter,  Prev: map_type Parameter,  Up: Common Parameters

mount_type Parameter
--------------------

   (type=string, default=`nfs').  All Amd mount types default to NFS.
That is, Amd is an NFS server on the map mount points, for the local
host it is running on.  If `autofs' is specified, Amd will be an autofs
server for those mount points.


File: am-utils.info,  Node: search_path Parameter,  Prev: mount_type Parameter,  Up: Common Parameters

search_path Parameter
---------------------

   (type=string, default no search path).  This provides a
(colon-delimited) search path for file maps.  Using a search path,
sites can allow for local map customizations and overrides, and can
distributed maps in several locations as needed.


File: am-utils.info,  Node: Global Parameters,  Next: Regular Map Parameters,  Prev: Common Parameters,  Up: Amd Configuration File

Global Parameters
=================

   The following parameters are applicable to the `[global]' section
only.

* Menu:

* arch Parameter::
* auto_dir Parameter::
* cache_duration Parameter::
* cluster Parameter::
* debug_options Parameter::
* dismount_interval Parameter::
* full_os Parameter::
* fully_qualified_hosts Parameter::
* hesiod_base Parameter::
* karch Parameter::
* ldap_base Parameter::
* ldap_cache_maxmem Parameter::
* ldap_cache_seconds Parameter::
* ldap_hostports Parameter::
* local_domain Parameter::
* log_file Parameter::
* log_options Parameter::
* map_reload_interval Parameter::
* nfs_proto Parameter::
* nfs_proto Parameter::
* nfs_retransmit_counter Parameter::
* nfs_retry_interval Parameter::
* nfs_vers Parameter::
* nis_domain Parameter::
* normalize_hostnames Parameter::
* os Parameter::
* osver Parameter::
* pid_file Parameter::
* plock Parameter::
* portmap_program Parameter::
* print_pid Parameter::
* print_version Parameter::
* restart_mounts Parameter::
* selectors_in_defaults Parameter::
* show_statfs_entries Parameter::
* unmount_on_exit Parameter::
* vendor Parameter::


File: am-utils.info,  Node: arch Parameter,  Next: auto_dir Parameter,  Prev: Global Parameters,  Up: Global Parameters

arch Parameter
--------------

   (type=string, default to compiled in value).  Same as the `-A'
option to Amd.  Allows you to override the value of the arch Amd
variable.


File: am-utils.info,  Node: auto_dir Parameter,  Next: cache_duration Parameter,  Prev: arch Parameter,  Up: Global Parameters

auto_dir Parameter
------------------

   (type=string, default=`/a').  Same as the `-a' option to Amd.  This
sets the private directory where Amd will create sub-directories for
its real mount points.


File: am-utils.info,  Node: cache_duration Parameter,  Next: cluster Parameter,  Prev: auto_dir Parameter,  Up: Global Parameters

cache_duration Parameter
------------------------

   (type=numeric, default=300).  Same as the `-c' option to Amd.  Sets
the duration in seconds that looked up map entries remain in the cache.


File: am-utils.info,  Node: cluster Parameter,  Next: debug_options Parameter,  Prev: cache_duration Parameter,  Up: Global Parameters

cluster Parameter
-----------------

   (type=string, default no cluster).  Same as the `-C' option to Amd.
Specifies the alternate HP-UX cluster to use.


File: am-utils.info,  Node: debug_options Parameter,  Next: dismount_interval Parameter,  Prev: cluster Parameter,  Up: Global Parameters

debug_options Parameter
-----------------------

   (type=string, default no debug options).  Same as the `-D' option to
Amd.  Specify any debugging options for Amd.  Works only if am-utils
was configured for debugging using the `--enable-debug' option.  The
`mem' option, as well as all other options, can be turned on via
`--enable-debug=mem'.  Otherwise debugging options are ignored.
Options are comma delimited, and can be preceded by the string `no' to
negate their meaning.  You can get the list of supported debugging and
logging options by running `amd -H'.  Possible values are:

`all'
     all options

`amq'
     register for amq

`daemon'
     enter daemon mode

`fork'
     fork server

`full'
     program trace

`mem'
     trace memory allocations

`mtab'
     use local `./mtab' file

`str'
     debug string munging

`test'
     full debug but no daemon

`trace'
     trace RPC protocol and NFS mount arguments


File: am-utils.info,  Node: dismount_interval Parameter,  Next: full_os Parameter,  Prev: debug_options Parameter,  Up: Global Parameters

dismount_interval Parameter
---------------------------

   (type=numeric, default=120).  Same as the `-w' option to Amd.
Specify in seconds, the time between attempts to dismount file systems
that have exceeded their cached times.


File: am-utils.info,  Node: full_os Parameter,  Next: fully_qualified_hosts Parameter,  Prev: dismount_interval Parameter,  Up: Global Parameters

full_os Parameter
-----------------

   (type=string, default to compiled in value).  The full name of the
operating system, along with its version.  Allows you to override the
compiled-in full name and version of the operating system.  Useful when
the compiled-in name is not desired.  For example, the full operating
system name on linux comes up as `linux', but you can override it to
`linux-2.2.5'.


File: am-utils.info,  Node: fully_qualified_hosts Parameter,  Next: hesiod_base Parameter,  Prev: full_os Parameter,  Up: Global Parameters

fully_qualified_hosts Parameter
-------------------------------

   (type=string, default=`no').  If `yes', Amd will perform RPC
authentication using fully-qualified host names.  This is necessary for
some systems, and especially when performing cross-domain mounting.  For
this function to work, the Amd variable `${hostd}' is used, requiring
that `${domain}' not be null.


File: am-utils.info,  Node: hesiod_base Parameter,  Next: karch Parameter,  Prev: fully_qualified_hosts Parameter,  Up: Global Parameters

hesiod_base Parameter
---------------------

   (type=string, default=`automount').  Specify the base name for
hesiod maps.


File: am-utils.info,  Node: karch Parameter,  Next: ldap_base Parameter,  Prev: hesiod_base Parameter,  Up: Global Parameters

karch Parameter
---------------

   (type=string, default to karch of the system).  Same as the `-k'
option to Amd.  Allows you to override the kernel-architecture of your
system.  Useful for example on Sun (Sparc) machines, where you can
build one Amd binary, and run it on multiple machines, yet you want
each one to get the correct karch variable set (for example, sun4c,
sun4m, sun4u, etc.)  Note that if not specified, Amd will use uname(2)
to figure out the kernel architecture of the machine.


File: am-utils.info,  Node: ldap_base Parameter,  Next: ldap_cache_maxmem Parameter,  Prev: karch Parameter,  Up: Global Parameters

ldap_base Parameter
-------------------

   (type=string, default not set).  Specify the base name for LDAP.
This often includes LDAP-specific values such as country and
organization.


File: am-utils.info,  Node: ldap_cache_maxmem Parameter,  Next: ldap_cache_seconds Parameter,  Prev: ldap_base Parameter,  Up: Global Parameters

ldap_cache_maxmem Parameter
---------------------------

   (type=numeric, default=131072).  Specify the maximum memory Amd
should use to cache LDAP entries.


File: am-utils.info,  Node: ldap_cache_seconds Parameter,  Next: ldap_hostports Parameter,  Prev: ldap_cache_maxmem Parameter,  Up: Global Parameters

ldap_cache_seconds Parameter
----------------------------

   (type=numeric, default=0).  Specify the number of seconds to keep
entries in the cache.


File: am-utils.info,  Node: ldap_hostports Parameter,  Next: local_domain Parameter,  Prev: ldap_cache_seconds Parameter,  Up: Global Parameters

ldap_hostports Parameter
------------------------

   (type=string, default not set).  Specify the LDAP host and port
values.


File: am-utils.info,  Node: local_domain Parameter,  Next: log_file Parameter,  Prev: ldap_hostports Parameter,  Up: Global Parameters

local_domain Parameter
----------------------

   (type=string, default no sub-domain).  Same as the `-d' option to
Amd.  Specify the local domain name.  If this option is not given the
domain name is determined from the hostname, by removing the first
component of the fully-qualified host name.


File: am-utils.info,  Node: log_file Parameter,  Next: log_options Parameter,  Prev: local_domain Parameter,  Up: Global Parameters

log_file Parameter
------------------

   (type=string, default=`stderr').  Same as the `-l' option to Amd.
Specify a file name to log Amd events to.  If the string `/dev/stderr'
is specified, Amd will send its events to the standard error file
descriptor.

   If the string `syslog' is given, Amd will record its events with the
system logger syslogd(8).  If your system supports syslog facilities,
then the default facility used is `LOG_DAEMON'.

   When using syslog, if you wish to change the facility, append its
name to the option name, delimited by a single colon.  For example, if
it is the string `syslog:local7' then Amd will log messages via
syslog(3) using the `LOG_LOCAL7' facility.  If the facility name
specified is not recognized, Amd will default to `LOG_DAEMON'.  Note:
while you can use any syslog facility available on your system, it is
generally a bad idea to use those reserved for other services such as
`kern', `lpr', `cron', etc.


File: am-utils.info,  Node: log_options Parameter,  Next: map_reload_interval Parameter,  Prev: log_file Parameter,  Up: Global Parameters

log_options Parameter
---------------------

   (type=string, default no logging options).  Same as the `-x' option
to Amd.  Specify any logging options for Amd.  Options are comma
delimited, and can be preceded by the string `no' to negate their
meaning.  The `debug' logging option is only available if am-utils was
configured with `--enable-debug'.  You can get the list of supported
debugging options by running `amd -H'.  Possible values are:

`all'
     all messages

`debug'
     debug messages

`error'
     non-fatal system errors

`fatal'
     fatal errors

`info'
     information

`map'
     map errors

`stats'
     additional statistical information

`user'
     non-fatal user errors

`warn'
     warnings

`warning'
     warnings


File: am-utils.info,  Node: map_reload_interval Parameter,  Next: nfs_proto Parameter,  Prev: log_options Parameter,  Up: Global Parameters

map_reload_interval Parameter
-----------------------------

   (type=numeric, default=3600).  The number of seconds that Amd will
wait before it checks to see if any maps have changed at their source
(NIS servers, LDAP servers, files, etc.).  Amd will reload only those
maps that have changed.


File: am-utils.info,  Node: nfs_proto Parameter,  Next: nfs_retransmit_counter Parameter,  Prev: map_reload_interval Parameter,  Up: Global Parameters

nfs_proto Parameter
-------------------

   (type=string, default to trying version tcp then udp).  By default,
Amd tries `tcp' and then `udp'.  This option forces the overall NFS
protocol used to TCP or UDP.  It overrides what is in the Amd maps, and
is useful when Amd is compiled with NFSv3 support that may not be
stable.  With this option you can turn off the complete usage of NFSv3
dynamically (without having to recompile Amd) until such time as NFSv3
support is desired again.


File: am-utils.info,  Node: nfs_retransmit_counter Parameter,  Next: nfs_retry_interval Parameter,  Prev: nfs_proto Parameter,  Up: Global Parameters

nfs_retransmit_counter Parameter
--------------------------------

   (type=numeric, default=11).  Same as the retransmit part of the `-t'
timeout.retransmit option to Amd.  Specifies the number of NFS
retransmissions that the kernel will use to communicate with Amd.
*Note -t Option::.


File: am-utils.info,  Node: nfs_retry_interval Parameter,  Next: nfs_vers Parameter,  Prev: nfs_retransmit_counter Parameter,  Up: Global Parameters

nfs_retry_interval Parameter
----------------------------

   (type=numeric, default=8).  Same as the timeout part of the `-t'
timeout.retransmit option to Amd.  Specifies the NFS timeout interval,
in _tenths_ of seconds, between NFS/RPC retries (for UDP only).  This
is the value that the kernel will use to communicate with Amd.  *Note
-t Option::.

   Amd relies on the kernel RPC retransmit mechanism to trigger mount
retries.  The values of the nfs_retransmit_counter and the
nfs_retry_interval parameters change the overall retry interval.  Too
long an interval gives poor interactive response; too short an interval
causes excessive retries.


File: am-utils.info,  Node: nfs_vers Parameter,  Next: nis_domain Parameter,  Prev: nfs_retry_interval Parameter,  Up: Global Parameters

nfs_vers Parameter
------------------

   (type=numeric, default to trying version 3 then 2).  By default, Amd
tries version 3 and then version 2.  This option forces the overall NFS
protocol used to version 3 or 2.  It overrides what is in the Amd maps,
and is useful when Amd is compiled with NFSv3 support that may not be
stable.  With this option you can turn off the complete usage of NFSv3
dynamically (without having to recompile Amd) until such time as NFSv3
support is desired again.


File: am-utils.info,  Node: nis_domain Parameter,  Next: normalize_hostnames Parameter,  Prev: nfs_vers Parameter,  Up: Global Parameters

nis_domain Parameter
--------------------

   (type=string, default to local NIS domain name).  Same as the `-y'
option to Amd.  Specify an alternative NIS domain from which to fetch
the NIS maps.  The default is the system domain name.  This option is
ignored if NIS support is not available.


File: am-utils.info,  Node: normalize_hostnames Parameter,  Next: os Parameter,  Prev: nis_domain Parameter,  Up: Global Parameters

normalize_hostnames Parameter
-----------------------------

   (type=boolean, default=`no').  Same as the `-n' option to Amd.  If
`yes', then the name referred to by `${rhost}' is normalized relative
to the host database before being used.  The effect is to translate
aliases into "official" names.


File: am-utils.info,  Node: os Parameter,  Next: osver Parameter,  Prev: normalize_hostnames Parameter,  Up: Global Parameters

os Parameter
------------

   (type=string, default to compiled in value).  Same as the `-O'
option to Amd.  Allows you to override the compiled-in name of the
operating system.  Useful when the built-in name is not desired for
backward compatibility reasons.  For example, if the built-in name is
`sunos5', you can override it to `sos5', and use older maps which were
written with the latter in mind.


File: am-utils.info,  Node: osver Parameter,  Next: pid_file Parameter,  Prev: os Parameter,  Up: Global Parameters

osver Parameter
---------------

   (type=string, default to compiled in value).  Same as the `-o'
option to Amd.  Allows you to override the compiled-in version number
of the operating system.  Useful when the built-in version is not
desired for backward compatibility reasons.  For example, if the build
in version is `2.5.1', you can override it to `5.5.1', and use older
maps that were written with the latter in mind.


File: am-utils.info,  Node: pid_file Parameter,  Next: plock Parameter,  Prev: osver Parameter,  Up: Global Parameters

pid_file Parameter
------------------

   (type=string, default=`/dev/stdout').  Specify a file to store the
process ID of the running daemon into.  If not specified, Amd will
print its process id onto the standard output.  Useful for killing Amd
after it had run.  Note that the PID of a running Amd can also be
retrieved via Amq (*note Amq -p option::).

   This file is used only if the `print_pid' option is on (*note
print_pid Parameter::).


File: am-utils.info,  Node: plock Parameter,  Next: portmap_program Parameter,  Prev: pid_file Parameter,  Up: Global Parameters

plock Parameter
---------------

   (type=boolean, default=`yes').  Same as the `-S' option to Amd.  If
`yes', lock the running executable pages of Amd into memory.  To
improve Amd's performance, systems that support the plock(3) or
mlockall(2) call can lock the Amd process into memory.  This way there
is less chance the operating system will schedule, page out, and swap
the Amd process as needed.  This improves Amd's performance, at the
cost of reserving the memory used by the Amd process (making it
unavailable for other processes).


File: am-utils.info,  Node: portmap_program Parameter,  Next: print_pid Parameter,  Prev: plock Parameter,  Up: Global Parameters

portmap_program Parameter
-------------------------

   (type=numeric, default=300019).  Specify an alternate Port-mapper RPC
program number, other than the official number.  This is useful when
running multiple Amd processes.  For example, you can run another Amd
in "test" mode, without affecting the primary Amd process in any way.
For safety reasons, the alternate program numbers that can be specified
must be in the range 300019-300029, inclusive.  Amq has an option `-P'
which can be used to specify an alternate program number of an Amd to
contact.  In this way, amq can fully control any number of Amd
processes running on the same host.


File: am-utils.info,  Node: print_pid Parameter,  Next: print_version Parameter,  Prev: portmap_program Parameter,  Up: Global Parameters

print_pid Parameter
-------------------

   (type=boolean, default=`no').  Same as the `-p' option to Amd.  If
`yes', Amd will print its process ID upon starting.

