Examples

Starting is best started from /etc/rc.local:

if [ -f /usr/local/etc/amd.start ]; then
        sh /usr/local/etc/amd.start; (echo -n ' amd')      >/dev/console
fi
The shell script, amd.start, contains:
PATH=/usr/local/etc:/bin:/usr/bin:/usr/ucb:$PATH export PATH

#
# Either name of logfile or "syslog"
#
LOGFILE=syslog
#LOGFILE=/var/adm/am.log

#
# Figure out whether domain name is in host name
# If the hostname is just the machine name then
# pass in the name of the local domain so that the
# hostnames in the map are domain stripped correctly.
#
case `hostname` in
*.*) dmn= ;;
*) dmn='-d doc.ic.ac.uk'
esac

#
# Zap earlier log file
#
case "$LOGFILE" in
*/*)
        mv "$LOGFILE" "$LOGFILE"-
        > "$LOGFILE"
        ;;
syslog)
        : nothing
        ;;
esac

cd /usr/local/etc
#
# -r            restart
# -d dmn        local domain
# -w wait       wait between unmount attempts
# -l log        logfile or "syslog"
#
eval ./amd -r $dmn -w 240 -l "$LOGFILE" \
        /homes amd.homes -cache:=inc \
        /home amd.home -cache:=inc \
        /vol amd.vol -cache:=inc \
        /n amd.net -cache:=inc

If the list of automount points and maps is contained in a file or YP map it is easily incorporated onto the command line:

...
eval ./amd -r $dmn -w 240 -l "$LOGFILE" `ypcat -k auto.master`

User Filesystems With more than one fileserver, the directories most frequently cross-mounted are those containing user home directories. A common convention used at Imperial College is to mount the user disks under /home/machine. Typically, the /etc/fstab file[*] contained a long list of entries such as:

machine:/home/machine /home/machine nfs ...
for each fileserver on the network.

There are numerous problems with this system. The mount list can become quite large and some of the machines may be down when a system is booted. When a new fileserver is installed, /etc/fstab must be updated on every machine, the mount directory created and the filesystem mounted. In research environments most people use the same few workstations, but it is convenient to go to a colleague's machine and access your own files. When a server goes down, it can cause a process on a client machine to hang. By minimising the mounted filesystems to only include those actively being used, there is less chance that a filesystem will be mounted when a server goes down.

The following is a short extract from a map taken from a research fileserver at Imperial College. Note the entry for localhost which is used for users such as the operator (opr) who have a home directory on most machine as /home/localhost/opr.

/defaults       opts:=rw,intr,grpid,nosuid
charm           host!=${key};type:=nfs;rhost:=${key};rfs:=/home/${key} \
                host==${key};type:=ufs;dev:=/dev/xd0g
#
...

#
localhost       type:=link;fs:=${host}
...
#
# dylan has two user disks so have a
# top directory in which to mount them.
#
dylan           type:=auto;fs:=${map};pref:=${key}/
#
dylan/dk2       host!=dylan;type:=nfs;rhost:=dylan;rfs:=/home/${key} \
                host==dylan;type:=ufs;dev:=/dev/dsk/2s0
#
dylan/dk5       host!=dylan;type:=nfs;rhost:=dylan;rfs:=/home/${key} \
                host==dylan;type:=ufs;dev:=/dev/dsk/5s0
...
#
toytown         host!=${key};type:=nfs;rhost:=${key};rfs:=/home/${key} \
                host==${key};type:=ufs;dev:=/dev/xy1g
...
#
zebedee         host!=${key};type:=nfs;rhost:=${key};rfs:=/home/${key} \
                host==${key};type:=ufs;dev:=/dev/dsk/1s0
#
# Just for access...
#
gould           type:=auto;fs:=${map};pref:=${key}/
gould/staff     host!=gould;type:=nfs;rhost:=gould;rfs:=/home/${key}
#
gummo           host!=${key};type:=nfs;rhost:=${key};rfs:=/home/${key}
...

This map is shared by most of the machines listed so on those systems any of the user disks is accessible via a consistent name. is started with the following command

amd /home amd.home

Note that when mounting a remote filesystem, the automounted mount point is referenced, so that the filesystem will be mounted if it is not yet (at the time the remote mountd obtains the file handle).

Home Directories One convention for home directories is to locate them in /homes so user jsp's home directory is /homes/jsp. With more than a single fileserver it is convenient to spread user files across several machines. All that is required is a mount-map which converts login names to an automounted directory.

Such a map might be started by the command:

amd /homes amd.homes
where the map amd.homes contained the entries:
/defaults type:=link # All the entries are of type:=link
jsp fs:=/home/charm/jsp
njw fs:=/home/dylan/dk5/njw
...
phjk fs:=/home/toytown/ai/phjk
sjv fs:=/home/ganymede/sjv
Whenever a login name is accessed in /homes a symbolic link appears pointing to the real location of that user's home directory. In this example, /homes/jsp would appear to be a symbolic link pointing to /home/charm/jsp. Of course, /home would also be an automount point.

This system causes an extra level of symbolic links to be used. Although that turns out to be relatively inexpensive, an alternative is to directly mount the required filesystems in the /homes map. The required map is simple, but long, and its creation best automated. The entry for jsp could be:


jsp      -sublink:=${key};rfs:=/home/charm \

jsp -sublink:=${key};rfs:=/home/charm \
host==charm;type:=ufs;dev:=/dev/xd0g \
host!=charm;type:=nfs;rhost:=charm

This map can become quite big if it contains a large number of entries. By combining two other features of it can be greatly simplified. First the partitions should be mounted under the control of /etc/fstab, taking care that they are mounted in the same place that would have automounted them, /a/host/home/host. In this case /etc/fstab on host charm would have a line

/dev/xy0g /a/charm/home/charm 4.2 rw,nosuid,grpid 1 5
The map can then be changed to:
/defaults type:=nfs;sublink:=key;opts:=rw,intr,nosuid,grpid
jsp rhost:=charm;rfs:=/home/charm
njw rhost:=dylan;rfs:=/home/dylan/dk5
...
phjk rhost:=toytown;rfs:=/home/toytown;sublink:=ai/key
sjv rhost:=ganymede;rfs:=/home/ganymede

This map operates as usual on a remote machine (ie host $\not=$ rhost). On the machine where the filesystem is stored (ie host = rhost), will construct a local filesystem mount point which corresponds to the name of the locally mounted partition. If is started with the ``-r'' option then instead of attempting an mount, will simply inherit the mount (ifs).

Architecture Sharing Often a filesystem will be shared by machines of different architectures. Separate trees can be maintained for the executable images for each architecture, but it may be more convenient to have a shared tree, with distinct subdirectories.

A shared tree might have the following structure on the fileserver (called fserver in the example):

local/tex
local/tex/fonts
local/tex/lib
local/tex/bin
local/tex/bin/sun3
local/tex/bin/sun4
local/tex/bin/hp9000
...
In this example, the subdirectories of local/tex/bin should be hidden when accessed via the automount point (conventionally /vol). A mount-map for /vol to achieve this would look like:

tex/fonts     

/defaults rfs:=/vol;sublink:=${key};rhost:=fserver;type:=link
tex type:=auto;fs:=${map};pref:=${key}/
tex/fonts host!=fserver;type:=nfs \
host==fserver;fs:=/usr/local
tex/lib host!=fserver;type:=nfs \
host==fserver;fs:=/usr/local
tex/bin -sublink:=${key}/${arch} host!=fserver;type:=nfs \
host:=fserver;fs:=/usr/local
When /vol/tex/bin is referenced, the current machine architecture is automatically appended to the path by the sublink variable. This means that users can have /vol/tex/bin in their PATH without concern for architecture dependencies.

Wildcard names & Replicated Servers By using the wildcard facility, can overlay an existing directory with additional entries. The system files are usually mounted under /usr. If instead is mounted on /usr, additional names can be overlayed to augment or replace names in the ``master'' /usr. A map to do this would have the form:


local     blah 

local type:=auto;fs:=local-map
share type:=auto;fs:=share-map
* -type:=nfs;rfs:=/export/exec/${arch};sublink:="${key}" \
rhost:=fserv1 rhost:=fserv2 rhost:=fserv3
Note that the assignment to sublink is surrounded by double quotes to prevent the incoming key from causing the map to be misinterpreted. This map has the effect of directing any access to /usr/local or /usr/share to another automount point. In this example, it is assumed that the /usr files are replicated on three fileservers: fserv1, fserv2 and fserv3. For any references other than to local and share one of the servers is used and a symbolic link to autodir/rhost/export/exec/arch/whatever is returned once an appropriate filesystem has been mounted.

rwho servers

The /usr/spool/rwho directory is a good candidate for automounting. For efficiency reasons it is best to capture the rwho data on a small number of machines and then mount that information onto a large number of clients. The data written into the rwho files is byte order dependent so only servers with the correct byte ordering can be used by a client:


usr/spool/rwho     blah 

/defaults type:=nfs
usr/spool/rwho -byte==little;rfs:=/usr/spool/rwho \
rhost:=vaxA rhost:=vaxB \
|| -rfs:=/usr/spool/rwho \
rhost:=sun4 rhost:=hp300

/vol /vol is used as a catch-all for volumes which do not have other conventional names.

Below is part of the /vol map for the domain doc.ic.ac.uk. The r+d tree is used for new or experimental software that needs to be available everywhere without installing it on all the fileservers. Users wishing to try out the new software then simply include /vol/r+d/bin,ucb in their path.

The main tree resides on one host gould.doc.ic.ac.uk, which has different bin, etc, lib and ucb sub-directories for each machine architecture. For example, /vol/r+d/bin for a Sun-4 would be stored in the sub-directory bin/sun4 of the filesystem /usr/r+d. When it was accessed a symbolic link pointing to /a/gould/usr/r+d/bin/sun4 would be returned.

/defaults    type:=nfs;opts:=rw,grpid,nosuid,intr,soft
wp           -opts:=rw,grpid,nosuid;rhost:=charm \
             host==charm;type:=link;fs:=/usr/local/wp \
             host!=charm;type:=nfs;rfs:=/vol/wp
...
#
src          -opts:=rw,grpid,nosuid;rhost:=charm \
             host==charm;type:=link;fs:=/usr/src \
             host!=charm;type:=nfs;rfs:=/vol/src
#
r+d          type:=auto;fs:=${map};pref:=r+d/
# per architecture bin,etc,lib&ucb...
r+d/bin      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}/${arch}
r+d/etc      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}/${arch}
r+d/include  rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}
r+d/lib      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}/${arch}
r+d/man      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}
r+d/src      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}
r+d/ucb      rhost:=gould.doc.ic.ac.uk;rfs:=/usr/r+d;sublink:=${/key}/${arch}
# hades pictures
pictures     -opts:=rw,grpid,nosuid;rhost:=thpfs \
             host==thpfs;type:=link;fs:=/nbsd/pictures \
             host!=thpfs;type:=nfs;rfs:=/nbsd;sublink:=pictures
# hades tools
hades        -opts:=rw,grpid,nosuid;rhost:=thpfs \
             host==thpfs;type:=link;fs:=/nbsd/hades \
             host!=thpfs;type:=nfs;rfs:=/nbsd;sublink:=hades
# bsd tools for hp.
bsd          -opts:=rw,grpid,nosuid;arch==hp9000;rhost:=thpfs \
             host==thpfs;type:=link;fs:=/nbsd/bsd \
             host!=thpfs;type:=nfs;rfs:=/nbsd;sublink:=bsd