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 fiThe 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.homeswhere the map amd.homes contained the entries:
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./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
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 5The 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 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):
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:local/tex
local/tex/fonts
local/tex/lib
local/tex/bin
local/tex/bin/sun3
local/tex/bin/sun4
local/tex/bin/hp9000
...
tex/fontsWhen /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.
/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
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 blahNote 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.
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
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