UNIX System Administration Handbook - Evi Nemeth [301]
Master maps
A master map lists the direct and indirect maps that automount should pay attention to. For each indirect map, it also specifies the root directory used by the mounts defined in the map.
A master map that made use of the direct and indirect maps shown in the previous examples would look something like this:
# Directory Map
/chimchim /etc/auto.chim -proto=tcp
/- /etc/auto.direct
The first column is a local directory name for an indirect map, or the special token /- for a direct map. The second column identifies the file in which the map is stored. You can have several maps of each type. When you specify mount options at the end of a line, they set the defaults for all mounts within the map.
On most systems, default options set on a master map entry do not “blend” with options specified in the direct or indirect map to which it points. If a map entry has its own list of options, the defaults are completely ignored. Red Hat merges the two sets, however. If the same option is specified in both places, the map entry’s value overrides the default.
The master map can usually be replaced or augmented by a version shared via NIS or NIS+. See your documentation for details.
Executable maps
If an indirect map file is executable, it’s assumed to be a script that dynamically generates automounting information. Instead of reading the map as a text file, the automounter will execute it with an argument (called the “key”) that indicates which subdirectory a user has attempted to access. The script is responsible for printing out an appropriate indirect map entry; if the specified key is not valid, the script can simply exit without printing anything.
This feature is very powerful and makes up for many of the potential deficiencies in automounter’s rather strange configuration system. In effect, it allows you to easily define a site-wide automount configuration file in a format of your own choice. You can write a simple Perl script to decode the global configuration on each machine.
Since automount scripts run dynamically as needed, it’s unnecessary to distribute the master configuration file after every change or to convert it preemptively to the automounter format; in fact, the global configuration file can have a permanent home on an NFS server.
Replicated filesystems using automount
In some cases, a read-only filesystem such as /usr/man may be identical on several different servers. In this case, you can tell automount about several potential sources for the filesystem. It will choose a server based on its own idea of which ones are closest given network numbers, NFS protocol versions, and response times from an initial query.
Although it is not required by automount, replicated mounts should represent read-only filesystems such as /usr/man or /usr/local/X11. There’s no way for automount to synchronize writes across a set of servers, and so replicated read-write filesystems are of little practical use.
Replicated filesystems should be truly identical. Otherwise, users will become agitated when a filesystem is replaced, and they may act in unpredictable ways.
Under Solaris, automount can smoothly switch from one server of a replicated mount to another when problems occur. This feature is only supposed to work properly for read-only mounts, but rumor has it that read-write mounts are handled more reasonably than the documentation would suggest. References to files that have been opened for writing will still hang when automount switches servers, however, which is yet another reason why replicated read-write mounts are perhaps not so useful.
Although automount can pick servers according to its own criteria of efficiency and locality, you can assign explicit priorities if you like. The priorities are small integers, with