UNIX System Administration Handbook - Evi Nemeth [302]
An auto.direct file that defines /usr/man and /cs/tools as replicated filesystems might look like this:
/usr/man -ro chimchim:/usr/share/man band(1):/usr/man
/cs/tools -ro anchor,band:/cs/tools
Note that server names can be listed together if the source path on each is the same. The (1) after band in the first line sets that server’s priority with respect to /usr/man.
Automatic automounts
Instead of listing every possible mount in a direct or indirect map, it’s possible to tell automount a little about your filesystem naming conventions and let it figure things out for itself. The key piece of glue that makes this work is the fact that it is possible to query the mountd running on a remote server to find out what filesystems the server exports.
There are several ways to configure “automatic automounts,” the simplest of which is the -hosts mount type. If you list -hosts as a map name in your master map file, automount will map remote hosts’ exports into the specified automount directory:
/net -hosts -nosuid,soft
For example, if chimchim exports /usr/share/man, that directory could then be reached via the automounter at the path /net/chimchim/usr/share/man.
The implementation of -hosts does not enumerate all possible hosts from which filesystems can be mounted; that would be impossible. Instead, it waits for individual subdirectory names to be referenced, then runs off and mounts the exported filesystems from the requested host.
A similar but finer-grained effect can be achieved with the * and & wildcards in an indirect map file. Also, a number of macros available for use in maps expand to the current hostname, architecture type, and so on. See the automount(1M) man page for details.
Specifics for Red Hat Linux
Red Hat’s automount is an independent implementation, and it has diverged a bit from Sun’s. The changes mostly have to do with the naming of commands and files.
First, in Red Hat, automount is the daemon that actually mounts and unmounts remote filesystems. It fills the same niche as the automountd daemon in Sun’s system and generally does not need to be run by hand.
The command that you use to make your changes to the master map take effect—automount, in Sun-land—is /etc/rc.d/init.d/autofs under Red Hat. The autofs command takes the arguments stop, start, reload, and status; reload, of course, is what you’d generally want to do after making changes.
The default master map file is /etc/auto.master. Its format and the format of indirect maps are as described previously. The documentation can be hard to find, however. The master map format is described in auto.master(5) and the indirect map format in autofs(5); be careful, or you’ll get autofs(8), which documents the syntax of the autofs command. (As one of the man pages says, “The documentation leaves a lot to be desired.”)
Red Hat does not support direct maps.
17.8 AMD: A MORE SOPHISTICATED AUTOMOUNTER
amd is an elaborate riff on the automounter concept. It became something of an orphan when its original author stopped maintaining it. It’s now kept up by Erez Zadok at Columbia University as a component of the am-utils package. The current URL is
http://www.cs.columbia.edu/~ezk/am-utils
amd offers the following advantages over automount:
• amd sends “keep alive” queries to remote servers at regular intervals and maintains a list of servers that are accessible. amd will mount, unmount, and replace filesystems based on this information. If a server crashes, future filesystem accesses return an “operation would block” error rather than hanging.
• amd contains no proprietary source code and has been ported to over 20 versions of UNIX.
• amd offers support for a number of mount types, such as the “union” mount, that are not supported by automount.
• The amd distribution includes a query-and-manipulation tool, amq, that lets you monitor amd’s status and send it hints and commands (such as forced unmount requests).
• amd’s map