| |
 |
 |
|
|
|
|
|
|
am-utils
File: am-utils.info, Node: Top, Next: License, Up: (DIR)
Am-utils (4.4BSD Automounter Utilities) User Manual
For version 6.0.9, 28 August 2003
Erez Zadok
(Originally by Jan-Simon Pendry and Nick Williams)
Copyright (C) 1997-2004 Erez Zadok
Copyright (C) 1989 Jan-Simon Pendry
Copyright (C) 1989 Imperial College of Science, Technology & Medicine
Copyright (C) 1989 The Regents of the University of California.
All Rights Reserved.
Permission to copy this document, or any portion of it, as necessary
for use of this software is granted provided this copyright notice and
statement of permission are included.
Am-utils is the 4.4BSD Automounter Tool Suite, which includes the Amd
automounter, the Amq query and control program, the Hlfsd daemon, and
other tools. This Info file describes how to use and understand the
tools within Am-utils.
* Menu:
* License:: Explains the terms and conditions for using
and distributing Am-utils.
* Distrib:: How to get the latest Am-utils distribution.
* Intro:: An introduction to Automounting concepts.
* History:: History of am-utils' development.
* Overview:: An overview of Amd.
* Supported Platforms:: Machines and Systems supported by Amd.
* Mount Maps:: Details of mount maps
* Amd Command Line Options:: All the Amd command line options explained.
* Filesystem Types:: The different mount types supported by Amd.
* Amd Configuration File:: The amd.conf file syntax and meaning.
* Run-time Administration:: How to start, stop and control Amd.
* FSinfo:: The FSinfo filesystem management tool.
* Hlfsd:: The Home-Link Filesystem server.
* Assorted Tools:: Other tools which come with am-utils.
* Examples:: Some examples showing how Amd might be used.
* Internals:: Implementation details.
* Acknowledgments & Trademarks:: Legal Notes
Indexes
* Index:: An item for each concept.
File: am-utils.info, Node: License, Next: Distrib, Prev: Top, Up: Top
License
*******
Am-utils is not in the public domain; it is copyrighted and there are
restrictions on its distribution.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
"This product includes software developed by the University of
California, Berkeley and its contributors, as well as the Trustees
of Columbia University."
4. Neither the name of the University nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
File: am-utils.info, Node: Distrib, Next: Intro, Prev: License, Up: Top
Source Distribution
*******************
The Am-utils home page is located in
`http://www.am-utils.org/'
You can get the latest distribution version of Am-utils from
`ftp://ftp.am-utils.org/pub/am-utils/am-utils.tar.gz'
Additional alpha, beta, and release distributions are available in
`ftp://ftp.am-utils.org/pub/am-utils/'.
Revision 5.2 was part of the 4.3BSD Reno distribution.
Revision 5.3bsdnet, a late alpha version of 5.3, was part of the BSD
network version 2 distribution
Revision 6.0 was made independently by Erez Zadok
<ezkATcs.edu> at the Computer Science Department of Columbia
University (http://www.cs.columbia.edu/), as part of his PhD thesis
work
(http://www.cs.columbia.edu/~ezk/research/tp/thesis_proposal.html).
Am-utils (especially version 6.1) continues to be developed and
maintained at the Computer Science Department
(http://www.cs.sunysb.edu/) of Stony Brook University
(http://www.stonybrook.edu/), as a service to the user community.
*Note History::, for more details.
Bug Reports
===========
Before reporting a bug, see if it is a known one in the bugs
(http://www.am-utils.org/BUGS.txt) file. Send all bug reports to
<am-utilsATam-utils.org> quoting the details of the release and your
configuration. These can be obtained by running the command `amd -v'.
It would greatly help if you could provide a reproducible procedure for
detecting the bug you are reporting.
Providing working patches is highly encouraged. Every patch
incorporated, however small, will get its author an honorable mention in
the authors file (http://www.am-utils.org/AUTHORS.txt).
Mailing Lists
=============
There are several mailing lists for people interested in keeping
up-to-date with developments.
1. The users mailing list, `am-utils' is for
- announcements of alpha and beta releases of am-utils
- reporting of bugs and patches
- discussions of new features for am-utils
- implementation and porting issues
To subscribe, visit
`http://lists.am-utils.org/mailman/listinfo/am-utils'. After
subscribing, you can post a message to this list at
<am-utilsATam-utils.org>. To avoid as much spam as possible, only
subscribers to this list may post to it.
Subscribers of `am-utils' are most helpful if they have the time
and resources to test new and development versions of amd, on as
many different platforms as possible. They should also be
prepared to learn and use the GNU Autoconf, Automake, and Libtool
packages, as needed; and of course, become familiar with the
complex code in the am-utils package. In other words, subscribers
on this list should hopefully be able to contribute meaningfully
to the development of amd.
Note that this `am-utils' list used to be called `amd-dev' before
January 1st, 2004. Please use the new name, `am-utils'.
2. The announcements mailing list, `am-utils-announce' is for
announcements only (mostly new releases). To subscribe, visit
`http://lists.am-utils.org/mailman/listinfo/am-utils-announce'.
This list is read-only: only am-utils developers may post to it.
3. We distribute nightly CVS snapshots in
`ftp://ftp.am-utils.org/pub/am-utils/snapshots/daily/'. If you
like to get email notices of commits to the am-utils CVS
repository, subscribe to the CVS logs mailing list, `am-utils-cvs'
at `http://lists.am-utils.org/mailman/listinfo/am-utils-cvs'.
4. The older list which was used to user discussions, `amd-workers',
is defunct as of January 2004. (Its last address was
<amd-workersATmajordomo.edu>.) Don't use `amd-workers':
use the newer, more active `am-utils' list.
5. For completeness, there's a developers-only closed list called
`am-utils-developersATam-utils.org'.
Am-utils Book
=============
Erez Zadok <ezkATcs.edu> wrote a book
(http://www.fsl.cs.sunysb.edu/docs/amd-book/), titled Linux NFS and
Automounter Administration, ISBN 0-7821-2739-8, (Sybex, 2001). The
book is full of details and examples that go beyond what this manual
has. The book also covers NFS in great detail. Although the book is
geared toward Linux users, it is general enough for any Unix
administrator and contains specific sections for non-Linux systems.
File: am-utils.info, Node: Intro, Next: History, Prev: Distrib, Up: Top
Introduction
************
An "automounter" maintains a cache of mounted filesystems. Filesystems
are mounted on demand when they are first referenced, and unmounted
after a period of inactivity.
Amd may be used as a replacement for Sun's automounter. The choice
of which filesystem to mount can be controlled dynamically with
"selectors". Selectors allow decisions of the form "hostname is THIS,"
or "architecture is not THAT." Selectors may be combined arbitrarily.
Amd also supports a variety of filesystem types, including NFS, UFS and
the novel "program" filesystem. The combination of selectors and
multiple filesystem types allows identical configuration files to be
used on all machines thus reducing the administrative overhead.
Amd ensures that it will not hang if a remote server goes down.
Moreover, Amd can determine when a remote server has become
inaccessible and then mount replacement filesystems as and when they
become available.
Amd contains no proprietary source code and has been ported to
numerous flavors of Unix.
File: am-utils.info, Node: History, Next: Overview, Prev: Intro, Up: Top
History
*******
The Amd package has been without an official maintainer since 1992.
Several people have stepped in to maintain it unofficially. Most
notable were the `upl' (Unofficial Patch Level) releases of Amd,
created by me (Erez Zadok <ezkATcs.edu>), and available from
`ftp://ftp.am-utils.org/pub/amd/'. The last such unofficial release
was `upl102'.
Through the process of patching and aging, it was becoming more and
more apparent that Amd was in much need of revitalizing. Maintaining
Amd had become a difficult task. I took it upon myself to cleanup the
code, so that it would be easier to port to new platforms, add new
features, keep up with the many new feature requests, and deal with the
never ending stream of bug reports.
I have been working on such a release of Amd on and off since
January of 1996. The new suite of tools is currently named "am-utils"
(AutoMounter Utilities), in line with GNU naming conventions, befitting
the contents of the package. In October of 1996 I had received enough
offers to help me with this task that I decided to make a mailing list
for this group of people. Around the same time, Amd had become a
necessary part of my PhD thesis work, resulting in more work performed
on am-utils.
Am-utils version 6.0 was numbered with a major new release number to
distinguish it from the last official release of Amd (5.x). Many new
features have been added such as a GNU `configure' system, NFS Version
3, a run-time configuration file (`amd.conf'), many new ports, more
scripts and programs, as well as numerous bug fixes. Another reason
for the new major release number was to alert users of am-utils that
user-visible interfaces may have changed. In order to make Amd work
well for the next 10 years, and be easier to maintain, it was necessary
to remove old or unused features, change various syntax files, etc.
However, great care was taken to ensure the maximum possible backwards
compatibility.
File: am-utils.info, Node: Overview, Next: Supported Platforms, Prev: History, Up: Top
1 Overview
**********
Amd maintains a cache of mounted filesystems. Filesystems are
"demand-mounted" when they are first referenced, and unmounted after a
period of inactivity. Amd may be used as a replacement for Sun's
automount(8) program. It contains no proprietary source code and has
been ported to numerous flavors of Unix. *Note Supported Platforms::.
Amd was designed as the basis for experimenting with filesystem
layout and management. Although Amd has many direct applications it is
loaded with additional features which have little practical use. At
some point the infrequently used components may be removed to streamline
the production system.
* Menu:
* Fundamentals::
* Filesystems and Volumes::
* Volume Naming::
* Volume Binding::
* Operational Principles::
* Mounting a Volume::
* Automatic Unmounting::
* Keep-alives::
* Non-blocking Operation::
File: am-utils.info, Node: Fundamentals, Next: Filesystems and Volumes, Prev: Overview, Up: Overview
1.1 Fundamentals
================
The fundamental concept behind Amd is the ability to separate the name
used to refer to a file from the name used to refer to its physical
storage location. This allows the same files to be accessed with the
same name regardless of where in the network the name is used. This is
very different from placing `/n/hostname' in front of the pathname
since that includes location dependent information which may change if
files are moved to another machine.
By placing the required mappings in a centrally administered
database, filesystems can be re-organized without requiring changes to
configuration files, shell scripts and so on.
File: am-utils.info, Node: Filesystems and Volumes, Next: Volume Naming, Prev: Fundamentals, Up: Overview
1.2 Filesystems and Volumes
===========================
Amd views the world as a set of fileservers, each containing one or
more filesystems where each filesystem contains one or more "volumes".
Here the term "volume" is used to refer to a coherent set of files such
as a user's home directory or a TeX distribution.
In order to access the contents of a volume, Amd must be told in
which filesystem the volume resides and which host owns the filesystem.
By default the host is assumed to be local and the volume is assumed to
be the entire filesystem. If a filesystem contains more than one
volume, then a "sublink" is used to refer to the sub-directory within
the filesystem where the volume can be found.
File: am-utils.info, Node: Volume Naming, Next: Volume Binding, Prev: Filesystems and Volumes, Up: Overview
1.3 Volume Naming
=================
Volume names are defined to be unique across the entire network. A
volume name is the pathname to the volume's root as known by the users
of that volume. Since this name uniquely identifies the volume
contents, all volumes can be named and accessed from each host, subject
to administrative controls.
Volumes may be replicated or duplicated. Replicated volumes contain
identical copies of the same data and reside at two or more locations in
the network. Each of the replicated volumes can be used
interchangeably. Duplicated volumes each have the same name but contain
different, though functionally identical, data. For example,
`/vol/tex' might be the name of a TeX distribution which varied for
each machine architecture.
Amd provides facilities to take advantage of both replicated and
duplicated volumes. Configuration options allow a single set of
configuration data to be shared across an entire network by taking
advantage of replicated and duplicated volumes.
Amd can take advantage of replacement volumes by mounting them as
required should an active fileserver become unavailable.
File: am-utils.info, Node: Volume Binding, Next: Operational Principles, Prev: Volume Naming, Up: Overview
1.4 Volume Binding
==================
Unix implements a namespace of hierarchically mounted filesystems. Two
forms of binding between names and files are provided. A "hard link"
completes the binding when the name is added to the filesystem. A
"soft link" delays the binding until the name is accessed. An
"automounter" adds a further form in which the binding of name to
filesystem is delayed until the name is accessed.
The target volume, in its general form, is a tuple (host, filesystem,
sublink) which can be used to name the physical location of any volume
in the network.
When a target is referenced, Amd ignores the sublink element and
determines whether the required filesystem is already mounted. This is
done by computing the local mount point for the filesystem and checking
for an existing filesystem mounted at the same place. If such a
filesystem already exists then it is assumed to be functionally
identical to the target filesystem. By default there is a one-to-one
mapping between the pair (host, filesystem) and the local mount point so
this assumption is valid.
File: am-utils.info, Node: Operational Principles, Next: Mounting a Volume, Prev: Volume Binding, Up: Overview
1.5 Operational Principles
==========================
Amd operates by introducing new mount points into the namespace. These
are called "automount" points. The kernel sees these automount points
as NFS filesystems being served by Amd. Having attached itself to the
namespace, Amd is now able to control the view the rest of the system
has of those mount points. RPC calls are received from the kernel one
at a time.
When a "lookup" call is received Amd checks whether the name is
already known. If it is not, the required volume is mounted. A
symbolic link pointing to the volume root is then returned. Once the
symbolic link is returned, the kernel will send all other requests
direct to the mounted filesystem.
If a volume is not yet mounted, Amd consults a configuration
"mount-map" corresponding to the automount point. Amd then makes a
runtime decision on what and where to mount a filesystem based on the
information obtained from the map.
Amd does not implement all the NFS requests; only those relevant to
name binding such as "lookup", "readlink" and "readdir". Some other
calls are also implemented but most simply return an error code; for
example "mkdir" always returns "read-only filesystem".
File: am-utils.info, Node: Mounting a Volume, Next: Automatic Unmounting, Prev: Operational Principles, Up: Overview
1.6 Mounting a Volume
=====================
Each automount point has a corresponding mount map. The mount map
contains a list of key-value pairs. The key is the name of the volume
to be mounted. The value is a list of locations describing where the
filesystem is stored in the network. In the source for the map the
value would look like
location1 location2 ... locationN
Amd examines each location in turn. Each location may contain
"selectors" which control whether Amd can use that location. For
example, the location may be restricted to use by certain hosts. Those
locations which cannot be used are ignored.
Amd attempts to mount the filesystem described by each remaining
location until a mount succeeds or Amd can no longer proceed. The
latter can occur in three ways:
* If none of the locations could be used, or if all of the locations
caused an error, then the last error is returned.
* If a location could be used but was being mounted in the
background then Amd marks that mount as being "in progress" and
continues with the next request; no reply is sent to the kernel.
* Lastly, one or more of the mounts may have been "deferred". A
mount is deferred if extra information is required before the
mount can proceed. When the information becomes available the
mount will take place, but in the mean time no reply is sent to
the kernel. If the mount is deferred, Amd continues to try any
remaining locations.
Once a volume has been mounted, Amd establishes a "volume mapping"
which is used to satisfy subsequent requests.
File: am-utils.info, Node: Automatic Unmounting, Next: Keep-alives, Prev: Mounting a Volume, Up: Overview
1.7 Automatic Unmounting
========================
To avoid an ever increasing number of filesystem mounts, Amd removes
volume mappings which have not been used recently. A time-to-live
interval is associated with each mapping and when that expires the
mapping is removed. When the last reference to a filesystem is removed,
that filesystem is unmounted. If the unmount fails, for example the
filesystem is still busy, the mapping is re-instated and its
time-to-live interval is extended. The global default for this grace
period is controlled by the `-w' command-line option (*note -w: -w
Option.) or the amd.conf parameter `dismount_interval' (*note
dismount_interval Parameter::). It is also possible to set this value
on a per-mount basis (*note opts: opts Option.).
Filesystems can be forcefully timed out using the Amq command.
*Note Run-time Administration::.
File: am-utils.info, Node: Keep-alives, Next: Non-blocking Operation, Prev: Automatic Unmounting, Up: Overview
1.8 Keep-alives
===============
Use of some filesystem types requires the presence of a server on
another machine. If a machine crashes then it is of no concern to
processes on that machine that the filesystem is unavailable. However,
to processes on a remote host using that machine as a fileserver this
event is important. This situation is most widely recognized when an
NFS server crashes and the behavior observed on client machines is that
more and more processes hang. In order to provide the possibility of
recovery, Amd implements a "keep-alive" interval timer for some
filesystem types. Currently only NFS makes use of this service.
The basis of the NFS keep-alive implementation is the observation
that most sites maintain replicated copies of common system data such as
manual pages, most or all programs, system source code and so on. If
one of those servers goes down it would be reasonable to mount one of
the others as a replacement.
The first part of the process is to keep track of which fileservers
are up and which are down. Amd does this by sending RPC requests to the
servers' NFS `NullProc' and checking whether a reply is returned.
While the server state is uncertain the requests are re-transmitted at
three second intervals and if no reply is received after four attempts
the server is marked down. If a reply is received the fileserver is
marked up and stays in that state for 30 seconds at which time another
NFS ping is sent.
Once a fileserver is marked down, requests continue to be sent every
30 seconds in order to determine when the fileserver comes back up.
During this time any reference through Amd to the filesystems on that
server fail with the error "Operation would block". If a replacement
volume is available then it will be mounted, otherwise the error is
returned to the user.
Although this action does not protect user files, which are unique on
the network, or processes which do not access files via Amd or already
have open files on the hung filesystem, it can prevent most new
processes from hanging.
File: am-utils.info, Node: Non-blocking Operation, Prev: Keep-alives, Up: Overview
1.9 Non-blocking Operation
==========================
Since there is only one instance of Amd for each automount point, and
usually only one instance on each machine, it is important that it is
always available to service kernel calls. Amd goes to great lengths to
ensure that it does not block in a system call. As a last resort Amd
will fork before it attempts a system call that may block indefinitely,
such as mounting an NFS filesystem. Other tasks such as obtaining
filehandle information for an NFS filesystem, are done using a purpose
built non-blocking RPC library which is integrated with Amd's task
scheduler. This library is also used to implement NFS keep-alives
(*note Keep-alives::).
Whenever a mount is deferred or backgrounded, Amd must wait for it
to complete before replying to the kernel. However, this would cause
Amd to block waiting for a reply to be constructed. Rather than do
this, Amd simply "drops" the call under the assumption that the kernel
RPC mechanism will automatically retry the request.
File: am-utils.info, Node: Supported Platforms, Next: Mount Maps, Prev: Overview, Up: Top
2 Supported Platforms
*********************
Am-utils has been ported to a wide variety of machines and operating
systems. Am-utils's code works for little-endian and big-endian
machines, as well as 32 bit and 64 bit architectures. Furthermore, when
Am-utils ports to an Operating System on one architecture, it is
generally readily portable to the same Operating System on all
platforms on which it is available.
The table below lists those platforms supported by the latest
release. The listing is based on the standard output from GNU's
`config.guess' script. Since significant changes have been made to
am-utils, not all systems listed here have been verified working for all
features.
Auto-Configured System Name Config Compile Amd NFS3 Shlib Hlfsd
alpha-dec-osf2.1 yes yes yes ? no ?
alpha-dec-osf4.0 yes yes yes yes yes ?
alpha-dec-osf4.0f yes yes yes yes yes ?
alpha-dec-osf5.1 yes yes yes yes yes ?
alphaev5-unknown-linux-gnu yes yes yes n/a yes ?
alphaev5-unknown-linux-gnu-rh5.2yes yes yes n/a yes ?
alphaev6-dec-osf5.0 yes yes yes yes yes ?
hppa1.0-hp-hpux11.00 yes yes yes no yes yes
hppa1.1-hp-hpux10.10 yes yes yes n/a no ?
hppa1.1-hp-hpux10.20 yes yes yes no no ?
hppa1.1-hp-hpux11.00 yes yes yes UDP yes yes
hppa1.1-hp-hpux9.01 yes yes yes n/a yes ?
hppa1.1-hp-hpux9.05 yes yes yes n/a yes ?
hppa1.1-hp-hpux9.07 yes yes yes n/a yes ?
hppa2.0w-hp-hpux11.00 yes yes yes n/a yes ?
i386-pc-bsdi2.1 yes yes yes n/a no ?
i386-pc-bsdi3.0 yes yes yes yes no ?
i386-pc-bsdi3.1 yes yes yes yes no ?
i386-pc-bsdi4.0 yes yes yes yes yes ?
i386-pc-bsdi4.0.1 yes yes yes yes yes ?
i386-pc-bsdi4.1 yes yes yes yes yes ?
i386-pc-linux-rh7.2 yes yes yes yes yes yes
i386-pc-solaris2.5.1 yes yes yes yes yes yes
i386-pc-solaris2.6 yes yes yes yes yes yes
i386-pc-solaris2.7 yes yes yes yes yes yes
i386-unknown-freebsd2.1.0 yes yes yes n/a ? ?
i386-unknown-freebsd2.2.1 yes yes yes n/a yes ?
i386-unknown-freebsd2.2.6 yes yes yes n/a yes ?
i386-unknown-freebsd2.2.7 yes yes yes n/a yes ?
i386-unknown-freebsd2.2.8 yes yes yes n/a yes ?
i386-unknown-freebsd3.0 yes yes yes yes yes ?
i386-unknown-freebsd4.2 yes yes yes yes yes ?
i386-unknown-freebsd4.4 yes yes yes yes yes ?
i386-unknown-freebsd5.0 yes yes yes yes yes ?
i386-unknown-freebsdelf3.0 yes yes yes yes yes ?
i386-unknown-freebsdelf3.1 yes yes yes yes yes ?
i386-unknown-freebsdelf3.2 yes yes yes yes yes ?
i386-unknown-freebsdelf3.3 yes yes yes yes yes ?
i386-unknown-freebsdelf3.4 yes yes yes yes yes ?
i386-unknown-freebsdelf4.0 yes yes yes yes yes ?
i386-unknown-netbsd1.2.1 yes yes yes yes yes ?
i386-unknown-netbsd1.3 yes yes yes yes yes ?
i386-unknown-netbsd1.3.1 yes yes yes yes yes ?
i386-unknown-netbsd1.3.2 yes yes yes yes yes ?
i386-unknown-netbsd1.3.3 yes yes yes yes yes ?
i386-unknown-netbsd1.4 yes yes yes yes yes ?
i386-unknown-netbsd1.4.1 yes yes yes yes yes ?
i386-unknown-openbsd2.1 yes yes yes yes yes ?
i386-unknown-openbsd2.2 yes yes yes yes yes ?
i386-unknown-openbsd2.3 yes yes yes yes yes ?
i386-unknown-openbsd2.4 yes yes yes yes yes ?
i386-unknown-openbsd2.5 yes yes yes yes yes ?
i486-ncr-sysv4.3.03 yes yes ? yes yes ?
i486-pc-linux-gnu-rh6.0 yes yes yes n/a yes ?
i486-pc-linux-gnulibc1 yes yes yes n/a yes ?
i486-pc-linux-gnulibc1-rh4.2 yes yes yes n/a yes ?
i486-pc-linux-gnuoldld yes yes yes n/a yes ?
i586-pc-linux-gnu yes yes yes n/a yes ?
i586-pc-linux-gnu-rh5.2 yes yes yes n/a yes ?
i586-pc-linux-gnu-rh6.0 yes yes yes n/a yes ?
i586-pc-linux-gnu-rh6.1 yes yes yes n/a yes ?
i586-pc-linux-gnu-rh6.2 yes yes yes n/a yes ?
i586-pc-linux-gnulibc1 yes yes yes n/a yes ?
i586-pc-linux-gnulibc1-rh4.2 yes yes yes n/a yes ?
i686-pc-linux-gnu yes yes yes n/a yes ?
i686-pc-linux-gnu-rh5.2 yes yes yes n/a yes ?
i686-pc-linux-gnu-rh6.0 yes yes yes n/a yes ?
i686-pc-linux-gnu-rh6.2 yes yes yes n/a yes yes
i686-pc-linux-gnulibc yes yes yes n/a yes ?
i686-pc-linux-gnulibc1 yes yes yes n/a yes ?
ia64-hp-hpux11.20 yes yes yes yes yes ?
ia64-unknown-linux-rh2.1AS yes yes yes yes yes yes
ia64-unknown-linux-rh2.1AW yes yes yes yes yes yes
ia64-unknown-linux-rh7.1 yes yes yes yes yes yes
ia64-unknown-linux-rh7.2 yes yes yes yes yes yes
m68k-hp-hpux9.00 yes yes yes n/a ? ?
m68k-sun-sunos4.1.1 yes yes yes n/a no ?
m68k-next-nextstep3 yes yes yes n/a no ?
mips-dec-ultrix4.3 yes yes yes n/a ? ?
mips-sgi-irix5.2 ? ? ? ? ? ?
mips-sgi-irix5.3 yes yes yes yes yes ?
mips-sgi-irix6.2 yes yes yes yes yes ?
mips-sgi-irix6.4 yes yes yes yes yes ?
mips-sgi-irix6.5 yes yes yes yes yes ?
powerpc-ibm-aix4.1.5.0 yes yes yes n/a no/broken?
powerpc-ibm-aix4.2.1.0 yes yes yes yes no/broken?
powerpc-ibm-aix4.3.1.0 yes yes ? yes ? ?
powerpc-unknown-linux-gnu yes yes yes n/a yes ?
rs6000-ibm-aix3.2 yes yes yes n/a ? ?
rs6000-ibm-aix3.2.5 yes yes yes n/a ? ?
rs6000-ibm-aix4.1.4.0 yes yes yes n/a no/broken?
rs6000-ibm-aix4.1.5.0 yes yes yes n/a no/broken?
sparc-sun-solaris2.3 yes yes yes n/a yes ?
sparc-sun-solaris2.4 yes yes yes n/a yes ?
sparc-sun-solaris2.5 yes yes yes yes yes ?
sparc-sun-solaris2.5.1 yes yes yes yes yes yes
sparc-sun-solaris2.6 yes yes yes yes yes yes
sparc-sun-solaris2.7 yes yes yes yes yes yes
sparc-sun-solaris2.8 yes yes yes yes yes yes
sparc-sun-sunos4.1.1 yes yes yes n/a yes ?
sparc-sun-sunos4.1.3 yes yes yes n/a yes ?
sparc-sun-sunos4.1.3C yes yes yes n/a yes ?
sparc-sun-sunos4.1.3_U1 yes yes yes n/a yes ?
sparc-sun-sunos4.1.4 yes yes yes n/a yes ?
sparc-unknown-linux-gnulibc1 yes yes yes n/a yes ?
sparc-unknown-netbsd1.2E yes yes yes ? ? ?
sparc-unknown-netbsd1.2G yes yes yes ? ? ?
sparc64-unknown-linux-gnu yes yes yes n/a yes ?
sparc64-unknown-linux-suse7.3 yes yes yes yes yes ?
See the `INSTALL' in the distribution for more specific details on
building and/or configuring for some systems.
File: am-utils.info, Node: Mount Maps, Next: Amd Command Line Options, Prev: Supported Platforms, Up: Top
3 Mount Maps
************
Amd has no built-in knowledge of machines or filesystems. External
"mount-maps" are used to provide the required information.
Specifically, Amd needs to know when and under what conditions it
should mount filesystems.
The map entry corresponding to the requested name contains a list of
possible locations from which to resolve the request. Each location
specifies filesystem type, information required by that filesystem (for
example the block special device in the case of UFS), and some
information describing where to mount the filesystem (*note fs
Option::). A location may also contain "selectors" (*note Selectors::).
* Menu:
* Map Types::
* Key Lookup::
* Location Format::
File: am-utils.info, Node: Map Types, Next: Key Lookup, Prev: Mount Maps, Up: Mount Maps
3.1 Map Types
=============
A mount-map provides the run-time configuration information to Amd.
Maps can be implemented in many ways. Some of the forms supported by
Amd are regular files, ndbm databases, NIS maps, the "Hesiod" name
server, and even the password file.
A mount-map "name" is a sequence of characters. When an automount
point is created a handle on the mount-map is obtained. For each map
type configured, Amd attempts to reference the map of the appropriate
type. If a map is found, Amd notes the type for future use and deletes
the reference, for example closing any open file descriptors. The
available maps are configured when Amd is built and can be displayed by
running the command `amd -v'.
When using an Amd configuration file (*note Amd Configuration File::)
and the keyword `map_type' (*note map_type Parameter::), you may force
the map used to any type.
By default, Amd caches data in a mode dependent on the type of map.
This is the same as specifying `cache:=mapdefault' and selects a
suitable default cache mode depending on the map type. The individual
defaults are described below. The CACHE option can be specified on
automount points to alter the caching behavior (*note Automount
Filesystem::).
The following map types have been implemented, though some are not
available on all machines. Run the command `amd -v' to obtain a list
of map types configured on your machine.
* Menu:
* File maps::
* ndbm maps::
* NIS maps::
* NIS+ maps::
* Hesiod maps::
* Password maps::
* Union maps::
* LDAP maps::
File: am-utils.info, Node: File maps, Next: ndbm maps, Prev: Map Types, Up: Map Types
3.1.1 File maps
---------------
When Amd searches a file for a map entry it does a simple scan of the
file and supports both comments and continuation lines.
Continuation lines are indicated by a backslash character (`\') as
the last character of a line in the file. The backslash, newline
character _and any leading white space on the following line_ are
discarded. A maximum line length of 2047 characters is enforced after
continuation lines are read but before comments are stripped. Each
line must end with a newline character; that is newlines are
terminators, not separators. The following examples illustrate this:
key valA valB; \
valC
specifies _three_ locations, and is identical to
key valA valB; valC
However,
key valA valB;\
valC
specifies only _two_ locations, and is identical to
key valA valB;valC
After a complete line has been read from the file, including
continuations, Amd determines whether there is a comment on the line.
A comment begins with a hash ("`#'") character and continues to the end
of the line. There is no way to escape or change the comment lead-in
character.
Note that continuation lines and comment support "only" apply to
file maps, or ndbm maps built with the `mk-amd-map' program.
When caching is enabled, file maps have a default cache mode of
`all' (*note Automount Filesystem::).
File: am-utils.info, Node: ndbm maps, Next: NIS maps, Prev: File maps, Up: Map Types
3.1.2 ndbm maps
---------------
An ndbm map may be used as a fast access form of a file map. The
program, `mk-amd-map', converts a normal map file into an ndbm database.
This program supports the same continuation and comment conventions that
are provided for file maps. Note that ndbm format files may _not_ be
sharable across machine architectures. The notion of speed generally
only applies to large maps; a small map, less than a single disk block,
is almost certainly better implemented as a file map.
ndbm maps have a default cache mode of `all' (*note Automount
Filesystem::).
File: am-utils.info, Node: NIS maps, Next: NIS+ maps, Prev: ndbm maps, Up: Map Types
3.1.3 NIS maps
--------------
When using NIS (formerly YP), an Amd map is implemented directly by the
underlying NIS map. Comments and continuation lines are _not_
supported in the automounter and must be stripped when constructing the
NIS server's database.
NIS maps have a default cache mode of `all' (*note Automount
Filesystem::).
The following rule illustrates what could be added to your NIS
`Makefile', in this case causing the `amd.home' map to be rebuilt:
$(YPTSDIR)/amd.home.time: $(ETCDIR)/amd.home
-@sed -e "s/#.*$$//" -e "/^$$/d" $(ETCDIR)/amd.home | \
awk '{ \
for (i = 1; i <= NF; i++) \
if (i == NF) { \
if (substr($$i, length($$i), 1) == "\\") \
printf("%s", substr($$i, 1, length($$i) - 1)); \
else \
printf("%s\n", $$i); \
} \
else \
printf("%s ", $$i); \
}' | \
$(MAKEDBM) - $(YPDBDIR)/amd.home; \
touch $(YPTSDIR)/amd.home.time; \
echo "updated amd.home"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) amd.home; \
echo "pushed amd.home"; \
else \
: ; \
fi
Here `$(YPTSDIR)' contains the time stamp files, and `$(YPDBDIR)'
contains the dbm format NIS files.
File: am-utils.info, Node: NIS+ maps, Next: Hesiod maps, Prev: NIS maps, Up: Map Types
3.1.4 NIS+ maps
---------------
NIS+ maps do not support cache mode `all' and, when caching is enabled,
have a default cache mode of `inc'.
XXX: FILL IN WITH AN EXAMPLE.
File: am-utils.info, Node: Hesiod maps, Next: Password maps, Prev: NIS+ maps, Up: Map Types
3.1.5 Hesiod maps
-----------------
When the map name begins with the string `hesiod.' lookups are made
using the "Hesiod" name server. The string following the dot is used
as a name qualifier and is prepended with the key being located. The
entire string is then resolved in the `automount' context, or the
amd.conf parameter `hesiod_base' (*note hesiod_base Parameter::). For
example, if the key is `jsp' and map name is `hesiod.homes' then
"Hesiod" is asked to resolve `jsp.homes.automount'.
Hesiod maps do not support cache mode `all' and, when caching is
enabled, have a default cache mode of `inc' (*note Automount
Filesystem::).
The following is an example of a "Hesiod" map entry:
jsp.homes.automount HS TXT "rfs:=/home/charm;rhost:=charm;sublink:=jsp"
njw.homes.automount HS TXT "rfs:=/home/dylan/dk2;rhost:=dylan;sublink:=njw"
File: am-utils.info, Node: Password maps, Next: Union maps, Prev: Hesiod maps, Up: Map Types
3.1.6 Password maps
-------------------
The password map support is unlike the four previous map types. When
the map name is the string `/etc/passwd' Amd can lookup a user name in
the password file and re-arrange the home directory field to produce a
usable map entry.
Amd assumes the home directory has the format
`/anydir/dom1/../domN/login'. It breaks this string into a map entry
where `${rfs}' has the value `/anydir/domN', `${rhost}' has the value
`domN.....dom1', and `${sublink}' has the value login.
Thus if the password file entry was
/home/achilles/jsp
the map entry used by Amd would be
rfs:=/home/achilles;rhost:=achilles;sublink:=jsp
Similarly, if the password file entry was
/home/cc/sugar/mjh
the map entry used by Amd would be
rfs:=/home/sugar;rhost:=sugar.cc;sublink:=jsp
File: am-utils.info, Node: Union maps, Next: LDAP maps, Prev: Password maps, Up: Map Types
3.1.7 Union maps
----------------
The union map support is provided specifically for use with the union
filesystem, *note Union Filesystem::.
It is identified by the string `union:' which is followed by a colon
separated list of directories. The directories are read in order, and
the names of all entries are recorded in the map cache. Later
directories take precedence over earlier ones. The union filesystem
type then uses the map cache to determine the union of the names in all
the directories.
File: am-utils.info, Node: LDAP maps, Prev: Union maps, Up: Map Types
3.1.8 LDAP maps
---------------
LDAP (Lightweight Directory Access Protocol) maps do not support cache
mode `all' and, when caching is enabled, have a default cache mode of
`inc'.
For example, an Amd map `amd.home' that looks as follows:
/defaults opts:=rw,intr;type:=link
zing -rhost:=shekel \
host==shekel \
host!=shekel;type:=nfs
when converted to LDAP (*note amd2ldif::), will result in the
following LDAP database:
$ amd2ldif amd.home CUCS < amd.home
dn: cn=amdmap timestamp, CUCS
cn : amdmap timestamp
objectClass : amdmapTimestamp
amdmapTimestamp: 873071363
dn: cn=amdmap amd.home[/defaults], CUCS
cn : amdmap amd.home[/defaults]
objectClass : amdmap
amdmapName : amd.home
amdmapKey : /defaults
amdmapValue : opts:=rw,intr;type:=link
dn: cn=amdmap amd.home[], CUCS
cn : amdmap amd.home[]
objectClass : amdmap
amdmapName : amd.home
amdmapKey :
amdmapValue :
dn: cn=amdmap amd.home[zing], CUCS
cn : amdmap amd.home[zing]
objectClass : amdmap
amdmapName : amd.home
amdmapKey : zing
amdmapValue : -rhost:=shekel host==shekel host!=shekel;type:=nfs
File: am-utils.info, Node: Key Lookup, Next: Location Format, Prev: Map Types, Up: Mount Maps
3.2 How keys are looked up
==========================
The key is located in the map whose type was determined when the
automount point was first created. In general the key is a pathname
component. In some circumstances this may be modified by variable
expansion (*note Variable Expansion::) and prefixing. If the automount
point has a prefix, specified by the PREF option, then that is
prepended to the search key before the map is searched.
If the map cache is a `regexp' cache then the key is treated as an
egrep-style regular expression, otherwise a normal string comparison is
made.
If the key cannot be found then a "wildcard" match is attempted.
Amd repeatedly strips the basename from the key, appends `/*' and
attempts a lookup. Finally, Amd attempts to locate the special key `*'.
For example, the following sequence would be checked if
`home/dylan/dk2' was being located:
home/dylan/dk2
home/dylan/*
home/*
*
At any point when a wildcard is found, Amd proceeds as if an exact
match had been found and the value field is then used to resolve the
mount request, otherwise an error code is propagated back to the kernel.
(*note Filesystem Types::).
File: am-utils.info, Node: Location Format, Prev: Key Lookup, Up: Mount Maps
3.3 Location Format
===================
The value field from the lookup provides the information required to
mount a filesystem. The information is parsed according to the syntax
shown below.
location-list:
location-selection
location-list white-space || white-space location-selection
location-selection:
location
location-selection white-space location
location:
location-info
-location-info
-
location-info:
sel-or-opt
location-info;sel-or-opt
;
sel-or-opt:
selection
opt-ass
selection:
selector==value
selector!=value
opt-ass:
option:=value
white-space:
space
tab
Note that unquoted whitespace is not allowed in a location
description. White space is only allowed, and is mandatory, where
shown with non-terminal white-space.
A "location-selection" is a list of possible volumes with which to
satisfy the request. "location-selection"s are separated by the `||'
operator. The effect of this operator is to prevent use of
location-selections to its right if any of the location-selections on
its left were selected whether or not any of them were successfully
mounted (*note Selectors::).
The location-selection, and singleton "location-list",
`type:=ufs;dev:=/dev/xd1g' would inform Amd to mount a UFS filesystem
from the block special device `/dev/xd1g'.
The "sel-or-opt" component is either the name of an option required
by a specific filesystem, or it is the name of a built-in, predefined
selector such as the architecture type. The value may be quoted with
double quotes `"', for example `type:="ufs";dev:="/dev/xd1g"'. These
quotes are stripped when the value is parsed and there is no way to get
a double quote into a value field. Double quotes are used to get white
space into a value field, which is needed for the program filesystem
(*note Program Filesystem::).
* Menu:
* Map Defaults::
* Variable Expansion::
* Selectors::
* Map Options::
File: am-utils.info, Node: Map Defaults, Next: Variable Expansion, Prev: Location Format, Up: Location Format
3.3.1 Map Defaults
------------------
A location beginning with a dash `-' is used to specify default values
for subsequent locations. Any previously specified defaults in the
location-list are discarded. The default string can be empty in which
case no defaults apply.
The location `-fs:=/mnt;opts:=ro' would set the local mount point to
`/mnt' and cause mounts to be read-only by default. Defaults specified
this way are appended to, and so override, any global map defaults
given with `/defaults').
File: am-utils.info, Node: Variable Expansion, Next: Selectors, Prev: Map Defaults, Up: Location Format
3.3.2 Variable Expansion
------------------------
To allow generic location specifications Amd does variable expansion on
each location and also on some of the option strings. Any option or
selector appearing in the form `$"var"' is replaced by the current
value of that option or selector. For example, if the value of
`${key}' was `bin', `${autodir}' was `/a' and `${fs}' was
`${autodir}/local/${key}' then after expansion `${fs}' would have the
value `/a/local/bin'. Any environment variable can be accessed in a
similar way.
Two pathname operators are available when expanding a variable. If
the variable name begins with `/' then only the last component of the
pathname is substituted. For example, if `${path}' was `/foo/bar' then
`${/path}' would be expanded to `bar'. Similarly, if the variable name
ends with `/' then all but the last component of the pathname is
substituted. In the previous example, `${path/}' would be expanded to
`/foo'.
Two domain name operators are also provided. If the variable name
begins with `.' then only the domain part of the name is substituted.
For example, if `${rhost}' was `swan.doc.ic.ac.uk' then `${.rhost}'
would be expanded to `doc.ic.ac.uk'. Similarly, if the variable name
ends with `.' then only the host component is substituted. In the
previous example, `${rhost.}' would be expanded to `swan'.
Variable expansion is a two phase process. Before a location is
parsed, all references to selectors, eg `${path}', are expanded. The
location is then parsed, selections are evaluated and option assignments
recorded. If there were no selections or they all succeeded the
location is used and the values of the following options are expanded in
the order given: SUBLINK, RFS, FS, OPTS, REMOPTS, MOUNT and UNMOUNT.
Note that expansion of option values is done after "all" assignments
have been completed and not in a purely left to right order as is done
by the shell. This generally has the desired effect but care must be
taken if one of the options references another, in which case the
ordering can become significant.
There are two special cases concerning variable expansion:
1. before a map is consulted, any selectors in the name received from
the kernel are expanded. For example, if the request from the
kernel was for `${arch}.bin' and the machine architecture was
`vax', the value given to `${key}' would be `vax.bin'.
2. the value of `${rhost}' is expanded and normalized before the
other options are expanded. The normalization process strips any
local sub-domain components. For example, if `${domain}' was
`Berkeley.EDU' and `${rhost}' was initially `snow.Berkeley.EDU',
after the normalization it would simply be `snow'. Hostname
normalization is currently done in a _case-dependent_ manner.
File: am-utils.info, Node: Selectors, Next: Map Options, Prev: Variable Expansion, Up: Location Format
3.3.3 Selectors
---------------
Selectors are used to control the use of a location. It is possible to
share a mount map between many machines in such a way that filesystem
location, architecture and operating system differences are hidden from
the users. A selector of the form `arch==sun3;os==sunos4' would only
apply on Sun-3s running SunOS 4.x.
Selectors can be negated by using `!=' instead of `=='. For example
to select a location on all non-Vax machines the selector `arch!=vax'
would be used.
Selectors are evaluated left to right. If a selector fails then that
location is ignored. Thus the selectors form a conjunction and the
locations form a disjunction. If all the locations are ignored or
otherwise fail then Amd uses the "error" filesystem (*note Error
Filesystem::). This is equivalent to having a location `type:=error'
at the end of each mount-map entry.
The default value of many of the selectors listed here can be
overridden by an Amd command line switch or in an Amd configuration
file. *Note Amd Configuration File::.
The following selectors are currently implemented.
* Menu:
* arch Selector Variable::
* autodir Selector Variable::
* byte Selector Variable::
* cluster Selector Variable::
* domain Selector Variable::
* dollar Selector Variable::
* host Selector Variable::
* hostd Selector Variable::
* karch Selector Variable::
* os Selector Variable::
* osver Selector Variable::
* full_os Selector Variable::
* vendor Selector Variable::
* key Selector Variable::
* map Selector Variable::
* netnumber Selector Variable::
* network Selector Variable::
* path Selector Variable::
* wire Selector Variable::
* uid Selector Variable::
* gid Selector Variable::
* exists Selector Function::
* false Selector Function::
* netgrp Selector Function::
* netgrpd Selector Function::
* in_network Selector Function::
* true Selector Function::
File: am-utils.info, Node: arch Selector Variable, Next: autodir Selector Variable, Prev: Selectors, Up: Selectors
3.3.3.1 arch Selector Variable
..............................
The machine architecture which was automatically determined at compile
time. The architecture type can be displayed by running the command
`amd -v'. *Note Supported Platforms::.
File: am-utils.info, Node: autodir Selector Variable, Next: byte Selector Variable, Prev: arch Selector Variable, Up: Selectors
3.3.3.2 autodir Selector Variable
.................................
The default directory under which to mount filesystems. This may be
changed by the `-a' command line option. *Note fs Option::.
File: am-utils.info, Node: byte Selector Variable, Next: cluster Selector Variable, Prev: autodir Selector Variable, Up: Selectors
3.3.3.3 byte Selector Variable
..............................
The machine's byte ordering. This is either `little', indicating
little-endian, or `big', indicating big-endian. One possible use is to
share `rwho' databases (*note rwho servers::). Another is to share
ndbm databases, however this use can be considered a courageous
juggling act.
File: am-utils.info, Node: cluster Selector Variable, Next: domain Selector Variable, Prev: byte Selector Variable, Up: Selectors
3.3.3.4 cluster Selector Variable
.................................
This is provided as a hook for the name of the local cluster. This can
be used to decide which servers to use for copies of replicated
filesystems. `${cluster}' defaults to the value of `${domain}' unless
a different value is set with the `-C' command line option.
File: am-utils.info, Node: domain Selector Variable, Next: dollar Selector Variable, Prev: cluster Selector Variable, Up: Selectors
3.3.3.5 domain Selector Variable
................................
The local domain name as specified by the `-d' command line option.
*Note host Selector Variable::.
File: am-utils.info, Node: dollar Selector Variable, Next: host Selector Variable, Prev: domain Selector Variable, Up: Selectors
3.3.3.6 dollar Selector Variable
................................
This is a special variable, whose sole purpose is to produce a literal
dollar sign in the value of another variable. For example, if you have
a remote file system whose name is `/disk$s', you can mount it by
setting the remote file system variable as follows:
rfs:=/disk${dollar}s
File: am-utils.info, Node: host Selector Variable, Next: hostd Selector Variable, Prev: dollar Selector Variable, Up: Selectors
3.3.3.7 host Selector Variable
..............................
The local hostname as determined by gethostname(2). If no domain name
was specified on the command line and the hostname contains a period
`.' then the string before the period is used as the host name, and the
string after the period is assigned to `${domain}'. For example, if
the hostname is `styx.doc.ic.ac.uk' then `host' would be `styx' and
`domain' would be `doc.ic.ac.uk'. `hostd' would be `styx.doc.ic.ac.uk'.
File: am-utils.info, Node: hostd Selector Variable, Next: karch Selector Variable, Prev: host Selector Variable, Up: Selectors
3.3.3.8 hostd Selector Variable
...............................
This resolves to the `${host}' and `${domain}' concatenated with a `.'
inserted between them if required. If `${domain}' is an empty string
then `${host}' and `${hostd}' will be identical.
File: am-utils.info, Node: karch Selector Variable, Next: os Selector Variable, Prev: hostd Selector Variable, Up: Selectors
3.3.3.9 karch Selector Variable
...............................
This is provided as a hook for the kernel architecture. This is used on
SunOS 4 and SunOS 5, for example, to distinguish between different
`/usr/kvm' volumes. `${karch}' defaults to the "machine" value gotten
from uname(2). If the uname(2) system call is not available, the value
of `${karch}' defaults to that of `${arch}'. Finally, a different
value can be set with the `-k' command line option.
File: am-utils.info, Node: os Selector Variable, Next: osver Selector Variable, Prev: karch Selector Variable, Up: Selectors
3.3.3.10 os Selector Variable
.............................
The operating system. Like the machine architecture, this is
automatically determined at compile time. The operating system name can
be displayed by running the command `amd -v'. *Note Supported
Platforms::.
File: am-utils.info, Node: osver Selector Variable, Next: full_os Selector Variable, Prev: os Selector Variable, Up: Selectors
3.3.3.11 osver Selector Variable
................................
The operating system version. Like the machine architecture, this is
automatically determined at compile time. The operating system name can
be displayed by running the command `amd -v'. *Note Supported
Platforms::.
File: am-utils.info, Node: full_os Selector Variable, Next: vendor Selector Variable, Prev: osver Selector Variable, Up: Selectors
3.3.3.12 full_os Selector Variable
..................................
The full name of the operating system, including its version. This
value is automatically determined at compile time. The full operating
system name and version can be displayed by running the command `amd
-v'. *Note Supported Platforms::.
File: am-utils.info, Node: vendor Selector Variable, Next: key Selector Variable, Prev: full_os Selector Variable, Up: Selectors
3.3.3.13 vendor Selector Variable
.................................
The name of the vendor of the operating system. This value is
automatically determined at compile time. The name of the vendor can be
displayed by running the command `amd -v'. *Note Supported Platforms::.
The following selectors are also provided. Unlike the other
selectors, they vary for each lookup. Note that when the name from the
kernel is expanded prior to a map lookup, these selectors are all
defined as empty strings.
File: am-utils.info, Node: key Selector Variable, Next: map Selector Variable, Prev: vendor Selector Variable, Up: Selectors
3.3.3.14 key Selector Variable
..............................
The name being resolved. For example, if `/home' is an automount
point, then accessing `/home/foo' would set `${key}' to the string
`foo'. The key is prefixed by the PREF option set in the parent mount
point. The default prefix is an empty string. If the prefix was
`blah/' then `${key}' would be set to `blah/foo'.
File: am-utils.info, Node: map Selector Variable, Next: netnumber Selector Variable, Prev: key Selector Variable, Up: Selectors
3.3.3.15 map Selector Variable
..............................
The name of the mount map being used.
File: am-utils.info, Node: netnumber Selector Variable, Next: network Selector Variable, Prev: map Selector Variable, Up: Selectors
3.3.3.16 netnumber Selector Variable
....................................
This selector is identical to the `in_network' selector function, see
*Note in_network Selector Function::. It will match either the name or
number of any network interface on which this host is connected to.
The names and numbers of all attached interfaces are available from the
output of `amd -v'.
File: am-utils.info, Node: network Selector Variable, Next: path Selector Variable, Prev: netnumber Selector Variable, Up: Selectors
3.3.3.17 network Selector Variable
..................................
This selector is identical to the `in_network' selector function, see
*Note in_network Selector Function::. It will match either the name or
number of any network interface on which this host is connected to.
The names and numbers of all attached interfaces are available from the
output of `amd -v'.
File: am-utils.info, Node: path Selector Variable, Next: wire Selector Variable, Prev: network Selector Variable, Up: Selectors
3.3.3.18 path Selector Variable
...............................
The full pathname of the name being resolved. For example `/home/foo'
in the example above.
File: am-utils.info, Node: wire Selector Variable, Next: uid Selector Variable, Prev: path Selector Variable, Up: Selectors
3.3.3.19 wire Selector Variable
...............................
This selector is identical to the `in_network' selector function, see
*Note in_network Selector Function::. It will match either the name or
number of any network interface on which this host is connected to.
The names and numbers of all attached interfaces are available from the
output of `amd -v'.
File: am-utils.info, Node: uid Selector Variable, Next: gid Selector Variable, Prev: wire Selector Variable, Up: Selectors
3.3.3.20 uid Selector Variable
..............................
This selector provides the numeric effective user ID (UID) of the user
which last accessed an automounted path name. This simple example shows
how floppy mounting can be assigned only to machine owners:
floppy -type:=pcfs \
uid==2301;host==shekel;dev:=/dev/floppy \
uid==6712;host==titan;dev=/dev/fd0 \
uid==0;dev:=/dev/fd0c \
type:=error
The example allows two machine owners to mount floppies on their
designated workstations, allows the root user to mount on any host, and
otherwise forces an error.
File: am-utils.info, Node: gid Selector Variable, Next: exists Selector Function, Prev: uid Selector Variable, Up: Selectors
3.3.3.21 gid Selector Variable
..............................
This selector provides the numeric effective group ID (GID) of the user
which last accessed an automounted path name.
The following boolean functions are selectors which take an argument
ARG. They return a value of true or false, and thus do not need to be
compared with a value. Each of these may be negated by prepending `!'
to their name.
File: am-utils.info, Node: exists Selector Function, Next: false Selector Function, Prev: gid Selector Variable, Up: Selectors
3.3.3.22 exists Selector Function
.................................
If the file listed by ARG exists (via lstat(2)), this function
evaluates to true. Otherwise it evaluates to false.
File: am-utils.info, Node: false Selector Function, Next: netgrp Selector Function, Prev: exists Selector Function, Up: Selectors
3.3.3.23 false Selector Function
................................
Always evaluates to false. ARG is ignored.
File: am-utils.info, Node: netgrp Selector Function, Next: netgrpd Selector Function, Prev: false Selector Function, Up: Selectors
3.3.3.24 netgrp Selector Function
.................................
If the current host as determined by the value of `${host}' (e.g.,
short host name) is a member of the netgroup ARG, this selector
evaluates to true. Otherwise it evaluates to false.
For example, suppose you have a netgroup `ppp-hosts', and for
reasons of performance, these have a local `/home' partition, while all
other clients on the faster network can access a shared home directory.
A common map to use for both might look like the following:
home/* netgrp(ppp-hosts);type:=link;fs:=/local/${key} \
!netgrp(ppp-hosts);type:=nfs;rhost:=serv1;rfs:=/remote/${key}
File: am-utils.info, Node: netgrpd Selector Function, Next: in_network Selector Function, Prev: netgrp Selector Function, Up: Selectors
3.3.3.25 netgrpd Selector Function
..................................
If the current host as determined by the value of `${hostd}' is a
member of the netgroup ARG, this selector evaluates to true. Otherwise
it evaluates to false.
The `netgrpd' function uses fully-qualified host names (`${hostd}')
to match netgroup names, while the `netgrp' function (*note netgrp
Selector Function::) uses short host names (`${host}').
File: am-utils.info, Node: in_network Selector Function, Next: true Selector Function, Prev: netgrpd Selector Function, Up: Selectors
3.3.3.26 in_network Selector Function
.....................................
This selector matches against any network name or number with an
optional netmask. First, if the current host has any network interface
that is locally attached to the network specified in ARG (either via
name or number), this selector evaluates to true.
Second, `in_network' supports a network/netmask syntax such as
`128.59.16.0/255.255.255.0', `128.59.16.0/24',
`128.59.16.0/0xffffff00', or `128.59.16.0/'. Using the last form, Amd
will match the specified network number against the default netmasks of
each of the locally attached interfaces.
If the selector does not match, it evaluates to false.
For example, suppose you have two servers that have an exportable
`/opt' that smaller clients can NFS mount. The two servers are say,
`serv1' on network `foo-net.site.com' and `serv2' on network
`123.4.5.0'. You can write a map to be used by all clients that will
attempt to mount the closest one as follows:
opt in_network(foo-net.site.com);rhost:=serv1;rfs:=/opt \
in_network(123.4.5.0);rhost:=serv2;rfs:=/opt \
rhost:=fallback-server
File: am-utils.info, Node: true Selector Function, Prev: in_network Selector Function, Up: Selectors
3.3.3.27 true Selector Function
...............................
Always evaluates to true. ARG is ignored.
File: am-utils.info, Node: Map Options, Prev: Selectors, Up: Location Format
3.3.4 Map Options
-----------------
Options are parsed concurrently with selectors. The difference is that
when an option is seen the string following the `:=' is recorded for
later use. As a minimum the TYPE option must be specified. Each
filesystem type has other options which must also be specified. *Note
Filesystem Types::, for details on the filesystem specific options.
Superfluous option specifications are ignored and are not reported
as errors.
The following options apply to more than one filesystem type.
* Menu:
* addopts Option::
* delay Option::
* fs Option::
* opts Option::
* remopts Option::
* sublink Option::
* type Option::
File: am-utils.info, Node: addopts Option, Next: delay Option, Prev: Map Options, Up: Map Options
3.3.4.1 addopts Option
......................
This option adds additional options to default options normally
specified in the `/defaults' entry or the defaults of the key entry
being processed (*note opts Option::). Normally when you specify
`opts' in both the `/defaults' and the map entry, the latter overrides
the former completely. But with `addopts' it will append the options
and override any conflicting ones.
`addopts' also overrides the value of the `remopts' option (*note
remopts Option::), which unless specified defaults to the value of
`opts'.
Options which start with `no' will override those with the same name
that do not start with `no' and vice verse. Special handling is given
to inverted options such as `soft' and `hard', `bg' and `fg', `ro' and
`rw', etc.
For example, if the default options specified were
opts:=rw,nosuid,intr,rsize=1024,wsize=1024,quota,posix
and the ones specified in a map entry were
addopts:=grpid,suid,ro,rsize=2048,quota,nointr
then the actual options used would be
wsize=1024,posix,grpid,suid,ro,rsize=2048,quota,nointr
File: am-utils.info, Node: delay Option, Next: fs Option, Prev: addopts Option, Up: Map Options
3.3.4.2 delay Option
....................
The delay, in seconds, before an attempt will be made to mount from the
current location. Auxiliary data, such as network address, file handles
and so on are computed regardless of this value.
A delay can be used to implement the notion of primary and secondary
file servers. The secondary servers would have a delay of a few
seconds, thus giving the primary servers a chance to respond first.
File: am-utils.info, Node: fs Option, Next: opts Option, Prev: delay Option, Up: Map Options
3.3.4.3 fs Option
.................
The local mount point. The semantics of this option vary between
filesystems.
For NFS and UFS filesystems the value of `${fs}' is used as the
local mount point. For other filesystem types it has other meanings
which are described in the section describing the respective filesystem
type. It is important that this string uniquely identifies the
filesystem being mounted. To satisfy this requirement, it should
contain the name of the host on which the filesystem is resident and the
pathname of the filesystem on the local or remote host.
The reason for requiring the hostname is clear if replicated
filesystems are considered. If a fileserver goes down and a
replacement filesystem is mounted then the "local" mount point "must"
be different from that of the filesystem which is hung. Some encoding
of the filesystem name is required if more than one filesystem is to be
mounted from any given host.
If the hostname is first in the path then all mounts from a
particular host will be gathered below a single directory. If that
server goes down then the hung mount points are less likely to be
accidentally referenced, for example when getcwd(3) traverses the
namespace to find the pathname of the current directory.
The `fs' option defaults to `${autodir}/${rhost}${rfs}'. In
addition, `rhost' defaults to the local host name (`${host}') and `rfs'
defaults to the value of `${path}', which is the full path of the
requested file; `/home/foo' in the example above (*note Selectors::).
`${autodir}' defaults to `/a' but may be changed with the `-a' command
line option. Sun's automounter defaults to `/tmp_mnt'. Note that
there is no `/' between the `${rhost}' and `${rfs}' since `${rfs}'
begins with a `/'.
File: am-utils.info, Node: opts Option, Next: remopts Option, Prev: fs Option, Up: Map Options
3.3.4.4 opts Option
...................
The options to pass to the mount system call. A leading `-' is
silently ignored. The mount options supported generally correspond to
those used by mount(8) and are listed below. Some additional
pseudo-options are interpreted by Amd and are also listed.
Unless specifically overridden, each of the system default mount
options applies. Any options not recognized are ignored. If no
options list is supplied the string `rw,defaults' is used and all the
system default mount options apply. Options which are not applicable
for a particular operating system are silently ignored. For example,
only 4.4BSD is known to implement the `compress' and `spongy' options.
`acdirmax=N'
Set the maximum directory attribute cache timeout to N.
`acdirmin=N'
Set the minimum directory attribute cache timeout to N.
`acregmax=N'
Set the maximum file attribute cache timeout to N.
`acregmin=N'
Set the minimum file attribute cache timeout to N.
`actimeo=N'
Set the overall attribute cache timeout to N.
`auto'
`ignore'
Ignore this mount by df(1).
`cache'
Allow data to be cached from a remote server for this mount.
`compress'
Use NFS compression protocol.
`defperm'
Ignore the permission mode bits, and default file permissions to
0555, UID 0, and GID 0. Useful for CD-ROMs formatted as ISO-9660.
`dev'
Allow local special devices on this filesystem.
`dumbtimr'
Turn off the dynamic retransmit timeout estimator. This may be
useful for UDP mounts that exhibit high retry rates, since it is
possible that the dynamically estimated timeout interval is too
short.
`extatt'
Enable extended attributes in ISO-9660 file systems.
`fsid'
Set ID of filesystem.
`gens'
Enable generations in ISO-9660 file systems. Generations allow
you to see all versions of a given file.
`grpid'
Use BSD directory group-id semantics.
`int'
`intr'
Allow keyboard interrupts on hard mounts.
`lock'
Use the NFS locking protocol (default)
`multi'
Perform multi-component lookup on files.
`maxgroups'
Set the maximum number of groups to allow for this mount.
`nfsv3'
Use NFS Version 3 for this mount.
`noac'
Turn off the attribute cache.
`noauto'
This option is used by the mount command in `/etc/fstab' or
`/etc/vfstab' and means not to mount this file system when mount -a
is used.
`nocache'
Do not allow data to be cached from a remote server for this mount.
`noconn'
Don't make a connection on datagram transports.
`nocto'
No close-to-open consistency.
`nodefperm'
Do not ignore the permission mode bits. Useful for CD-ROMS
formatted as ISO-9660.
`nodev'
`nodevs'
Don't allow local special devices on this filesystem.
`noexec'
Don't allow program execution.
`noint'
Do not allow keyboard interrupts for this mount
`nolock'
Do not use the NFS locking protocol
`nomnttab'
This option is used internally to tell Amd that a Solaris 8 system
using mntfs is in use.
`norrip'
Turn off using of the Rock Ridge Interchange Protocol (RRIP)
extensions to ISO-9660.
`nosub'
Disallow mounts beneath this mount.
`nosuid'
Don't allow set-uid or set-gid executables on this filesystem.
`noversion'
Strip the extension `;#' from the version string of files recorded
on an ISO-9660 CD-ROM.
`optionstr'
Under Solaris 8, provide the kernel a string of options to parse
and show as part of the special in-kernel mount file system.
`overlay'
Overlay this mount on top of an existing mount, if any.
`pgthresh=N'
Set the paging threshold to N kilobytes.
`port=N'
Set the NFS port to N.
`posix'
Turn on POSIX static pathconf for mounts.
`proplist'
Support property lists (ACLs) for this mount, useful primarily for
DU-4.0.
`proto=S'
Use transport protocol S for NFS (can be `"tcp"' or `"udp"').
`quota'
Enable quota checking on this mount.
`rdonly'
`ro'
Mount this filesystem readonly.
`resvport'
Use a reserved port (smaller than 1024) for remote NFS mounts.
Most systems assume that, but some allow for mounts to occur on
non-reserved ports. This causes problems when such a system
tries to NFS mount one that requires reserved ports. It is
recommended that this option always be on.
`retrans=n'
The number of NFS retransmits made before a user error is
generated by a `soft' mounted filesystem, and before a `hard'
mounted filesystem reports `NFS server "yoyo" not responding still
trying'.
`retry'
Set the NFS retry counter.
`rrip'
Uses the Rock Ridge Interchange Protocol (RRIP) extensions to
ISO-9660.
`rsize=N'
The NFS read packet size. You may need to set this if you are
using NFS/UDP through a gateway or a slow link.
`rw'
Allow reads and writes on this filesystem.
`soft'
Give up after "retrans" retransmissions.
`spongy'
Like `soft' for status requests, and `hard' for data transfers.
`suid'
Allow set-uid programs on this mount.
`symttl'
Turn off the symbolic link cache time-to-live.
`sync'
Perform synchronous filesystem operations on this mount.
`tcp'
Use TCP/IP instead of UDP/IP, ignored if the NFS implementation
does not support TCP/IP mounts.
`timeo=N'
The NFS timeout, in tenth-seconds, before a request is
retransmitted.
`vers=N'
Use NFS protocol version number N (can be 2 or 3).
`wsize=N'
The NFS write packet size. You may need to set this if you are
using NFS/UDP through a gateway or a slow link.
The following options are implemented by Amd, rather than being
passed to the kernel.
`nounmount'
Configures the mount so that its time-to-live will never expire.
This is the default for non-network based filesystem types (such as
mounting local disks, floppies, and CD-ROMs). See also the related
unmount option.
`ping=N'
The interval, in seconds, between keep-alive pings. When four
consecutive pings have failed the mount point is marked as hung.
This interval defaults to 30 seconds. If the ping interval is
less than zero, no pings are sent and the host is assumed to be
always up. By default, pings are not sent for an NFS/TCP mount.
`retry=N'
The number of times to retry the mount system call.
`unmount'
Configures the mount so that its time-to-live will indeed expire
(and thus may be automatically unmounted). This is also the
default for network-based filesystem types (e.g., NFS). This
option is useful for removable local media such as CD-ROMs, USB
drives, etc. so they can expire when not in use, and get unmounted
(such drives can get work out when they keep spinning). See also
the related nounmount option.
`utimeout=N'
The interval, in seconds, by which the mount's time-to-live is
extended after an unmount attempt has failed. In fact the
interval is extended before the unmount is attempted to avoid
thrashing. The default value is 120 seconds (two minutes) or as
set by the `-w' command line option.
File: am-utils.info, Node: remopts Option, Next: sublink Option, Prev: opts Option, Up: Map Options
3.3.4.5 remopts Option
......................
This option has the same use as `${opts}' but applies only when the
remote host is on a non-local network. For example, when using NFS
across a gateway it is often necessary to use smaller values for the
data read and write sizes. This can simply be done by specifying the
small values in REMOPTS. When a non-local host is accessed, the
smaller sizes will automatically be used.
Amd determines whether a host is local by examining the network
interface configuration at startup. Any interface changes made after
Amd has been started will not be noticed. The likely effect will be
that a host may incorrectly be declared non-local.
Unless otherwise set, the value of `${remopts}' is the same as the
value of `${opts}'.
File: am-utils.info, Node: sublink Option, Next: type Option, Prev: remopts Option, Up: Map Options
3.3.4.6 sublink Option
......................
The subdirectory within the mounted filesystem to which the reference
should point. This can be used to prevent duplicate mounts in cases
where multiple directories in the same mounted filesystem are used.
File: am-utils.info, Node: type Option, Prev: sublink Option, Up: Map Options
3.3.4.7 type Option
...................
The filesystem type to be used. *Note Filesystem Types::, for a full
description of each type.
File: am-utils.info, Node: Amd Command Line Options, Next: Filesystem Types, Prev: Mount Maps, Up: Top
4 Amd Command Line Options
**************************
Many of Amd's parameters can be set from the command line. The command
line is also used to specify automount points and maps.
The general format of a command line is
amd [options] [{ directory map-name [-map-options] } ...]
For each directory and map-name given or specified in the `amd.conf'
file, Amd establishes an automount point. The "map-options" may be any
sequence of options or selectors--*note Location Format::. The
"map-options" apply only to Amd's mount point.
`type:=toplvl;cache:=mapdefault;fs:=${map}' is the default value for
the map options. Default options for a map are read from a special
entry in the map whose key is the string `/defaults'. When default
options are given they are prepended to any options specified in the
mount-map locations as explained in *Note Map Defaults::.
The "options" are any combination of those listed below.
Once the command line has been parsed, the automount points are
mounted. The mount points are created if they do not already exist, in
which case they will be removed when Amd exits. Finally, Amd
disassociates itself from its controlling terminal and forks into the
background.
Note: Even if Amd has been built with `-DDEBUG' (via `configure
--enable-debug'), it will still background itself and disassociate
itself from the controlling terminal. To use a debugger it is
necessary to specify `-D nodaemon' on the command line. However, even
with all of this, mounts and unmounts are performed in the background,
and Amd will always fork before doing them. Therefore, debugging what
happens closely during un/mounts is more challenging.
_All_ of Amd's command options (save `-F' and `-T') can be specified
in the `amd.conf' file. *Note Amd Configuration File::. If Amd is
invoked without any command line options, it will default to using the
configuration file `/etc/amd.conf', if one exists.
* Menu:
* -a Option:: Automount directory.
* -c Option:: Cache timeout interval.
* -d Option:: Domain name.
* -k Option:: Kernel architecture.
* -l Option:: Log file.
* -n Option:: Hostname normalization.
* -o Option:: Operating system version.
* -p Option:: Output process id.
* -r Option:: Restart existing mounts.
* -t Option:: Kernel RPC timeout.
* -v Option:: Version information.
* -w Option:: Wait interval after failed unmount.
* -x Option:: Log options.
* -y Option:: NIS domain.
* -C-Option:: Cluster name.
* -D-Option:: Debug flags.
* -F Option:: Amd configuration file.
* -H Option:: Show brief help.
* -O-Option:: Operating system name.
* -S Option:: Lock executable pages in memory.
* -T-Option:: Set tag for configuration file.
File: am-utils.info, Node: -a Option, Next: -c Option, Prev: Amd Command Line Options, Up: Amd Command Line Options
4.1 `-a' DIRECTORY
==================
Specifies the default mount directory. This option changes the variable
`${autodir}' which otherwise defaults to `/a'. For example, some sites
prefer `/amd' or `/n'.
amd -a /amd ...
File: am-utils.info, Node: -c Option, Next: -d Option, Prev: -a Option, Up: Amd Command Line Options
4.2 `-c' CACHE-INTERVAL
=======================
Selects the period, in seconds, for which a name is cached by Amd. If
no reference is made to the volume in this period, Amd discards the
volume name to filesystem mapping.
Once the last reference to a filesystem has been removed, Amd
attempts to unmount the filesystem. If the unmount fails the interval
is extended by a further period as specified by the `-w' command line
option or by the `utimeout' mount option.
The default "cache-interval" is 300 seconds (five minutes).
File: am-utils.info, Node: -d Option, Next: -k Option, Prev: -c Option, Up: Amd Command Line Options
4.3 `-d' DOMAIN
===============
Specifies the host's domain. This sets the internal variable
`${domain}' and affects the `${hostd}' variable.
If this option is not specified and the hostname already contains the
local domain then that is used, otherwise the default value of
`${domain}' is `unknown.domain'.
For example, if the local domain was `doc.ic.ac.uk', Amd could be
started as follows:
amd -d doc.ic.ac.uk ...
File: am-utils.info, Node: -k Option, Next: -l Option, Prev: -d Option, Up: Amd Command Line Options
4.4 `-k' KERNEL-ARCHITECTURE
============================
Specifies the kernel architecture of the system. This is usually the
output of `uname -m' (the "machine" value gotten from uname(2)). If
the uname(2) system call is not available, the value of `${karch}'
defaults to that of `${arch}'.
The only effect of this option is to set the variable `${karch}'.
This option would be used as follows:
amd -k `arch -k` ...
File: am-utils.info, Node: -l Option, Next: -n Option, Prev: -k Option, Up: Amd Command Line Options
4.5 `-l' LOG-OPTION
===================
Selects the form of logging to be made. Several special "log-options"
are recognized.
1. If "log-option" is the string `syslog', Amd will use the syslog(3)
mechanism. If your system supports syslog facilities, then the
default facility used is `LOG_DAEMON'.
2. When using syslog, if you wish to change the facility, append its
name to the log option name, delimited by a single colon. For
example, if "log-options" 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.
3. If "log-option" is the string `/dev/stderr', Amd will use standard
error, which is also the default target for log messages. To
implement this, Amd simulates the effect of the `/dev/fd' driver.
Any other string is taken as a filename to use for logging. Log
messages are appended to the file if it already exists, otherwise a new
file is created. The file is opened once and then held open, rather
than being re-opened for each message.
Normally, when long-running daemons hold an open file descriptor on a
log file, it is impossible to "rotate" the log file and compress older
logs on a daily basis. The daemon needs to be told to discard (via
close(2)) its file handle, and re-open the log file. This is done
using `amq -l' log-option. *Note Amq -l option::.
If the `syslog' option is specified but the system does not support
syslog or if the named file cannot be opened or created, Amd will use
standard error. Error messages generated before Amd has finished
parsing the command line are printed on standard error.
Since Amd tends to generate a lot of logging information (especially
if debugging was turned on), and due to it being an important program
running on the system, it is usually best to log to a separate disk
file. In that case Amd would be started as follows:
amd -l /var/log/amd ...
File: am-utils.info, Node: -n Option, Next: -o Option, Prev: -l Option, Up: Amd Command Line Options
4.6 `-n'
========
Normalizes the remote hostname before using it. Normalization is done
by replacing the value of `${rhost}' with the (generally fully
qualified) primary name returned by a hostname lookup.
This option should be used if several names are used to refer to a
single host in a mount map.
File: am-utils.info, Node: -o Option, Next: -p Option, Prev: -n Option, Up: Amd Command Line Options
4.7 `-o' OP-SYS-VER
===================
Overrides the compiled-in version number of the operating system, with
OP-SYS-VER. Useful when the built-in version is not desired for
backward compatibility reasons. For example, if the built-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: -p Option, Next: -r Option, Prev: -o Option, Up: Amd Command Line Options
4.8 `-p'
========
Causes Amd's process id to be printed on standard output. This can be
redirected to a suitable file for use with kill:
amd -p > /var/run/amd.pid ...
This option only has an affect if Amd is running in daemon mode. If
Amd is started with the `-D nodaemon' debug flag, this option is
ignored.
File: am-utils.info, Node: -r Option, Next: -t Option, Prev: -p Option, Up: Amd Command Line Options
4.9 `-r'
========
Tells Amd to restart existing mounts (*note Inheritance Filesystem::).
File: am-utils.info, Node: -t Option, Next: -v Option, Prev: -r Option, Up: Amd Command Line Options
4.10 `-t' TIMEOUT.RETRANSMIT
============================
Specifies the RPC "timeout" interval and the "retransmit" counter used
by the kernel to communicate to Amd. These are used to set the `timeo'
and `retrans' mount options, respectively. The default timeout is 0.8
seconds, and the default number of retransmissions is 11.
Amd relies on the kernel RPC retransmit mechanism to trigger mount
retries. The values of these 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: -v Option, Next: -w Option, Prev: -t Option, Up: Amd Command Line Options
4.11 `-v'
=========
Print version information on standard error and then exit. The output
is of the form:
Copyright (c) 1997-1999 Erez Zadok
Copyright (c) 1990 Jan-Simon Pendry
Copyright (c) 1990 Imperial College of Science, Technology & Medicine
Copyright (c) 1990 The Regents of the University of California.
am-utils version 6.0a15 (build 61).
Built by ezkATcs.edu on date Wed Oct 22 15:21:03 EDT 1997.
cpu=sparc (big-endian), arch=sun4, karch=sun4u.
full_os=solaris2.5.1, os=sos5, osver=5.5.1, vendor=sun.
Map support for: root, passwd, union, nisplus, nis, ndbm, file, error.
AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, inherit,
ufs, lofs, hsfs, pcfs, auto, direct, toplvl, error.
FS: cachefs, cdfs, lofs, nfs, nfs3, pcfs, tfs, tmpfs, ufs.
Network 1: wire="mcl-lab-net.cs.columbia.edu" (netnumber=128.59.13).
Network 2: wire="14-net.cs.columbia.edu" (netnumber=128.59.14).
Network 3: wire="old-net.cs.columbia.edu" (netnumber=128.59.16).
The information includes the version number, number of times Amd was
compiled on the local system, release date and name of the release.
Following come the cpu type, byte ordering, and the architecture and
kernel architecture as `${arch}' and `${karch}', respectively. The
next line lists the operating system full name, short name, version,
and vendor. These four values correspond to the variables
`${full_os}', `${os}', `${osver}', and `${vendor}', respectively.
*Note Supported Platforms::.
Then come a list of map types supported, filesystems internally
supported by Amd (AMFS), and generic filesystems available (FS).
Finally all known networks (if any) of this host are listed by name and
number. They are available via the variables `${wire}' or
`${network}', and `${netnumber}' (*note Selectors::) or the `in_network'
selector function (*note in_network Selector Function::).
File: am-utils.info, Node: -w Option, Next: -x Option, Prev: -v Option, Up: Amd Command Line Options
4.12 `-w' WAIT-TIMEOUT
======================
Selects the interval in seconds between unmount attempts after the
initial time-to-live has expired.
This defaults to 120 seconds (two minutes).
File: am-utils.info, Node: -x Option, Next: -y Option, Prev: -w Option, Up: Amd Command Line Options
4.13 `-x' OPTS
==============
Specifies the type and verbosity of log messages. "opts" is a comma
separated list selected from the following options:
`fatal'
Fatal errors
`error'
Non-fatal errors
`user'
Non-fatal user errors
`warn'
Recoverable errors
`warning'
Alias for `warn'
`info'
Information messages
`map'
Mount map usage
`stats'
Additional statistics
`all'
All of the above
Initially a set of default logging flags is enabled. This is as if
`-x all,nomap,nostats' had been selected. The command line is parsed
and logging is controlled by the `-x' option. The very first set of
logging flags is saved and can not be subsequently disabled using Amq.
This default set of options is useful for general production use.
The `info' messages include details of what is mounted and unmounted
and when filesystems have timed out. If you want to have the default
set of messages without the `info' messages then you simply need `-x
noinfo'. The messages given by `user' relate to errors in the mount
maps, so these are useful when new maps are installed. The following
table lists the syslog priorities used for each of the message types.
`fatal'
`LOG_CRIT'
`error'
`LOG_ERR'
`user'
`LOG_WARNING'
`warning'
`LOG_WARNING'
`info'
`LOG_INFO'
`debug'
`LOG_DEBUG'
`map'
`LOG_DEBUG'
`stats'
`LOG_INFO'
The options can be prefixed by the string `no' to indicate that this
option should be turned off. For example, to obtain all but `info'
messages the option `-x all,noinfo' would be used.
If Amd was built with debugging enabled the `debug' option is
automatically enabled regardless of the command line options.
File: am-utils.info, Node: -y Option, Next: -C-Option, Prev: -x Option, Up: Amd Command Line Options
4.14 `-y' NIS-DOMAIN
====================
Selects an alternate NIS domain. This is useful for debugging and
cross-domain shared mounting. If this flag is specified, Amd
immediately attempts to bind to a server for this domain.
File: am-utils.info, Node: -C-Option, Next: -D-Option, Prev: -y Option, Up: Amd Command Line Options
4.15 `-C' CLUSTER-NAME
======================
Specifies the name of the cluster of which the local machine is a
member. The only effect is to set the variable `${cluster}'. The
"cluster-name" is will usually obtained by running another command
which uses a database to map the local hostname into a cluster name.
`${cluster}' can then be used as a selector to restrict mounting of
replicated data. If this option is not given, `${cluster}' has the
same value as `${domain}'. This would be used as follows:
amd -C `clustername` ...
File: am-utils.info, Node: -D-Option, Next: -F Option, Prev: -C-Option, Up: Amd Command Line Options
4.16 `-D' OPTS
==============
Controls the verbosity and coverage of the debugging trace; "opts" is a
comma separated list of debugging options. The `-D' option is only
available if Amd was compiled with `-DDEBUG', or configured with
`configure --enable-debug'. The memory debugging facilities (`mem')
are only available if Amd was compiled with `-DDEBUG_MEM' (in addition
to `-DDEBUG'), or configured with `configure --enable-debug=mem'.
The most common options to use are `-D trace' and `-D test' (which
turns on all the useful debug options). As usual, every option can be
prefixed with `no' to turn it off.
`all'
all options
`amq'
register for amq
`daemon'
enter daemon mode
`fork'
fork server
`full'
program trace
`hrtime'
print high resolution time stamps (only if syslog(3) is not used)
`info'
info service specific debugging (hesiod, nis, etc.) In the case of
hesiod maps, turns on the hesiod RES_DEBUG internal debugging
option.
`mem'
trace memory allocations
`mtab'
use local `./mtab' file
`readdir'
show readdir progress
`str'
debug string munging
`test'
full debug but no daemon
`trace'
trace RPC protocol and NFS mount arguments
`xdrtrace'
trace XDR routines
You may also refer to the program source for a more detailed
explanation of the available options.
File: am-utils.info, Node: -F Option, Next: -H Option, Prev: -D-Option, Up: Amd Command Line Options
4.17 `-F' CONF-FILE
===================
Specify an Amd configuration file CONF-FILE to use. For a description
of the format and syntax, *note Amd Configuration File::. This
configuration file is used to specify any options in lieu of typing
many of them on the command line. The `amd.conf' file includes
directives for every command line option Amd has, and many more that
are only available via the configuration file facility. The
configuration file specified by this option is processed after all other
options had been processed, regardless of the actual location of this
option on the command line.
File: am-utils.info, Node: -H Option, Next: -O-Option, Prev: -F Option, Up: Amd Command Line Options
4.18 `-H'
=========
Print a brief help and usage string.
File: am-utils.info, Node: -O-Option, Next: -S Option, Prev: -H Option, Up: Amd Command Line Options
4.19 `-O' OP-SYS-NAME
=====================
Overrides the compiled-in name of the operating system, with
OP-SYS-NAME. Useful when the built-in name is not desired for backward
compatibility reasons. For example, if the build in name is `sunos5',
you can override it to the old name `sos5', and use older maps which
were written with the latter in mind.
File: am-utils.info, Node: -S Option, Next: -T-Option, Prev: -O-Option, Up: Amd Command Line Options
4.20 `-S'
=========
Do _not_ lock the running executable pages of Amd into memory. To
improve Amd's performance, systems that support the plock(3) call 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 tends to improve Amd's performance, at the cost of
reserving the memory used by the Amd process (making it unavailable for
other processes). If this behavior is not desired, use the `-S' option.
File: am-utils.info, Node: -T-Option, Prev: -S Option, Up: Amd Command Line Options
4.21 `-T' TAG
=============
Specify a tag to use with `amd.conf'. All map entries tagged with TAG
will be processed. Map entries that are not tagged are always
processed. Map entries that are tagged with a tag other than TAG will
not be processed.
File: am-utils.info, Node: Filesystem Types, Next: Amd Configuration File, Prev: Amd Command Line Options, Up: Top
5 Filesystem Types
******************
To mount a volume, Amd must be told the type of filesystem to be used.
Each filesystem type typically requires additional information such as
the fileserver name for NFS.
From the point of view of Amd, a "filesystem" is anything that can
resolve an incoming name lookup. An important feature is support for
multiple filesystem types. Some of these filesystems are implemented
in the local kernel and some on remote fileservers, whilst the others
are implemented internally by Amd.
The two common filesystem types are UFS and NFS. Four other user
accessible filesystems (`link', `program', `auto' and `direct') are
also implemented internally by Amd and these are described below.
There are two additional filesystem types internal to Amd which are not
directly accessible to the user (`inherit' and `error'). Their use is
described since they may still have an effect visible to the user.
* Menu:
* Network Filesystem:: A single NFS filesystem.
* Network Host Filesystem:: NFS mount a host's entire export tree.
* Network Filesystem Group:: An atomic group of NFS filesystems.
* Unix Filesystem:: Native disk filesystem.
* Caching Filesystem:: Caching from remote server filesystem.
* CD-ROM Filesystem:: ISO9660 CD ROM.
* Loopback Filesystem:: Local loopback-mount filesystem.
* Memory/RAM Filesystem:: A memory or RAM-based filesystem.
* Null Filesystem:: 4.4BSD's loopback-mount filesystem.
* Floppy Filesystem:: MS-DOS Floppy filesystem.
* Translucent Filesystem:: The directory merging filesystem.
* Shared Memory+Swap Filesystem:: Sun's tmpfs filesystem.
* User ID Mapping Filesystem:: 4.4BSD's umapfs filesystem.
* Program Filesystem:: Generic Program mounts.
* Symbolic Link Filesystem:: Local link.
* Symbolic Link Filesystem II:: Local link referencing existing filesystem.
* NFS-Link Filesystem:: Link if path exists, NFS otherwise.
* Automount Filesystem::
* Direct Automount Filesystem::
* Union Filesystem::
* Error Filesystem::
* Top-level Filesystem::
* Root Filesystem::
* Inheritance Filesystem::
File: am-utils.info, Node: Network Filesystem, Next: Network Host Filesystem, Prev: Filesystem Types, Up: Filesystem Types
5.1 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
5.2 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
5.3 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
5.4 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
5.5 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
5.6 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
5.7 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
5.8 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
5.9 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
5.10 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
5.11 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
5.12 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
5.13 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
5.14 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 progra | | |
Home