UNIX System Administration Handbook - Evi Nemeth [300]
automount configuration is relatively simple and concise. amd is more complicated and more powerful, and it includes some features that are largely experimental. You might want to check out amd’s feature list and see if there’s anything that you can’t live without.
The second edition of this book vigorously recommended amd over automount. Since automount did not actually work, the choice was easy.8
However, in the context of a working, autofs-based automount, there isn’t really a compelling argument to be made in favor of either automounter. In general, the simplicity of automount and the fact that it’s preinstalled on many systems make it a good default. Try it and see if it works for you.
17.7 AUTOMOUNT: THE ORIGINAL AUTOMOUNTER
Both Solaris and HP-UX provide a current automount. Red Hat has an automount clone with some minor variations in configuration syntax. See the Red Hat information on page 509 for specifics.
automount understands three different kinds of configuration files (called “maps”): direct maps, indirect maps, and master maps.9
Direct and indirect maps provide information about filesystems that are to be automounted. A master map lists direct and indirect maps that automount should pay attention to. Only one master map can be active at once; the default master map is kept in /etc/auto_master.
When run, automount reads its configuration files, sets up any necessary autofs mounts, and exits. References to automounted filesystems are actually handled (via autofs) by a separate daemon, automountd. automountd normally does its work silently and does not need additional configuration.
If you change the master map or one of the direct maps that it references, you must rerun automount to pick up the changes. With the -v option, automount will show you the adjustments it’s making to its configuration.
automount accepts a -t argument that tells how long (in seconds) an automounted filesystem may remain unused before being unmounted. The default is 5 minutes. Since an NFS mount whose server has crashed can cause programs that touch it to hang, it’s good hygiene to clean up automounts that are no longer in use; don’t raise the timeout too much.10
Indirect maps
Indirect maps automount several filesystems underneath a common directory. The path of the directory is specified in the master map, not in the indirect map itself. For example, an indirect map for filesystems that get mounted under /chimchim might look like this:
users chimchim:/chimchim/users
devel -soft,proto=udp chimchim:/chimchim/devel
info -ro chimchim:/chimchim/info
The first column names the subdirectory where each automount should be installed, and subsequent items list the mount options and source path of the filesystem. This example (perhaps stored in /etc/auto.chim) tells automount that it can mount the directories /chimchim/users, /chimchim/devel, and /chimchim/info from host chimchim, with info being mounted read-only and devel being mounted via UDP (this example is from a Solaris system, so TCP is the default).
In this configuration the paths on chimchim and the local host will be identical, but this correspondence is not required.
Direct maps
Direct maps list filesystems that do not share a common prefix, such as /usr/src and /cs/tools. A direct map (e.g., /etc/auto.direct) that described both of these filesystems to automount might look something like this:
/usr/src chimchim:/usr/src
/cs/tools -ro anchor:/cs/tools
Because they do not share a common parent directory, these automounts must each be implemented with a separate autofs mount. This configuration requires slightly more overhead, but it has the added advantage that the mount point and directory structure are always accessible by commands such as ls. Using