The sections ``Creating master automount maps'' and ``Creating indirect and direct automount maps'' provide examples for creating master, direct, and indirect automount maps in their basic and simplest form.
automount provides advanced configuration options for use in these maps to ease maintenance, improve automount performance, and provide additional automount capabilities:
The built-in maps (-hosts, -passwd, and -null) do not need to be created. automount recognizes these names and attaches special automount operations to each. For information on these special operations, see the built-in map descriptions.
Built-in maps are typically used on the automount command line or in the master map. These uses are illustrated below. The -hosts and -passwd maps may also be used in direct and indirect maps. See ``Mixing local and distributed automount maps'' for this usage.
Here are examples of each built-in map used on an automount
automount /net -hosts
automount /home/server -passwd
automount /usr/bin -null
Here is an example of a master map showing usage of each type of built-in map:
/net -hosts mount_options /home/server -passwd mount_options /usr/bin -null mount_options
In both of the above examples and for each built-in map type, the built-in map must be associated with a mount point expressed as an absolute pathname.
Both direct and indirect maps contain a ``location'' field
where the filesystem to be mounted is specified.
The syntax of this field is:
We recommend that a subdirectory entry be provided in the ``location'' field when different map entries refer to the same mounted filesystem from the same server. This allows automount to work more efficiently. The following example shows a common use of subdirectories that optimizes the work of automount.
This indirect map shows a common way in which automount can be configured to distribute home directories from NFS servers to clients. Such a map may be called auto.home.
moscow moscow:/home/moscow prague prague:/home/prague zurich zurich:/home/zurichGiven this indirect map, every time a user wants to access a home directory in, for example, /home/moscow, all the directories under it are mounted. Another way to organize an auto.home map is by user name:
john moscow:/home/moscow/john mary moscow:/home/moscow/mary joe moscow:/home/moscow/joeThe above example assumes that home directories on the NFS client are of the form /home/user rather than /home/server/user. If a user now enters:
ls ~john ~\maryautomount performs the equivalent of:
mkdir /tmp_mnt/home/john mount -f NFS moscow:/home/moscow/john /tmp_mnt/home/john ln -s /tmp_mnt/home/john /home/johnIt is possible to optimize the work done by automount by modifying the entries in the auto.home map to use the optional ``subdirectory'' field of the ``location'' field of the indirect map. The new auto.home map looks like:
mkdir /tmp_mnt/home/mary mount -f NFS moscow:/home/moscow/mary /tmp_mnt/home/mary ln -s /tmp_mnt/home/mary /home/mary
john moscow:/home/moscow:john mary moscow:/home/moscow:mary joe moscow:/home/moscow:joeHere ``john,'' ``mary,'' and ``joe'' are entries in the ``subdirectory'' field. Now when a user refers to john's home directory, automount mounts moscow:/home/moscow and links /tmp_mnt/home/moscow/john and /home/john.
If the user then requests access to mary's home directory, automount sees that moscow:/home/moscow is already mounted, and simply links /tmp_mnt/home/moscow/mary and /home/mary. Therefore, automount now performs only the equivalent of:
mkdir /tmp_mnt/home/john mount -f NFS moscow:/home/moscow /tmp_mnt/home ln -s /tmp_mnt/home/john /home/john ln -s /tmp_mnt/home/mary /home/mary
automount recognizes the ``&'' and ``'' characters as having a special meaning within maps. Using these characters as string substitutions within automount maps reduces redundancy in each line of a map and saves a user from having to duplicate information.
Suppose you have an indirect map with a lot of subdirectories specified, for example:
john moscow:/home/moscow:john mary moscow:/home/moscow:mary joe moscow:/home/moscow:joe able prague:/export/home:able baker sydney:/export/home:baker [. . .]Consider using string substitutions. If the string in the ``key'' field is repeated in the ``location'' field, you can use the ampersand character (&) in place of the key value string wherever it appears in the ``location'' field.
Using the ampersand, the above map now looks like:
john moscow:/home/moscow:& mary moscow:/home/moscow:& joe moscow:/home/moscow:& able prague:/export/home:& baker sydney:/export/home:& [. . .]Suppose the name of the server is the same as the key itself, for instance:
moscow moscow:/home/moscow sydney sydney:/home/sydney prague prague:/home/prague milan milan:/home/milan zurich zurich:/home/zurich [. . .]The use of the ampersand results in:
moscow &:/home/& sydney &:/home/& prague &:/home/& milan &:/home/& zurich &:/home/& [. . .]
You can also use key substitutions in a direct map:
/usr/man moscow,seattle,zurich:/usr/manThis could be written as:
/usr/man moscow,seattle,zurich:&Notice that the ampersand substitution uses the whole key string, so if the key in a direct map starts with a ``/'' (as it should), that slash is carried over, and you could not do something like this:
/progs &1,&2,&3:/export/src/progsThis is because automount interprets it as:
Notice that all the entries in the ampersand indirect map examples have the same format. This permits you to use the usual substitute character, the asterisk (). The asterisk reduces the whole thing to:
&:/home/&Here each ampersand is substituted by the value of any given key. This tells automount to mount /home/server from any known server.
Once automount reads the substitute key, it does not continue reading the map, so that the following map is viable:
milan &:/export/& zurich &:/export/& &:/home/&In the next map the last two entries are always ignored:
&:/home/& milan &:/export/& zurich &:/export/&
Under certain circumstances, you may have to mount directories whose names may confuse automount's map parser. This is a concern only with servers without a UNIX operating system. An example might be a directory called rc0:dk1; this could result in an entry like:
/patriot -ro boston:rc0:dk1The presence of the two colons in the ``location'' field confuses automount's parser. To avoid this confusion, use a backslash to escape the second colon and remove its special meaning of separator:
/patriot -ro boston:rc0\:dk1
You can also use double quotes where they hide the blank space in the name:
/marbles beijing:/"chinese checkers"/marbles
Redundant servers can be specified in either a direct or indirect map. In both cases, multiple servers are specified in the ``location'' field of a map entry. In the direct mount example in ``An example of direct mounting using automount'', instead of specifying just london as the remote server for /usr/man, it is possible to specify remote servers madrid and oslo, as well. The resulting direct map could look like:
/usr/man -ro,soft london:/usr/man \ madrid:/usr/man \ oslo:/usr/manThis means that the mounting can be done from any of the specified locations (london, madrid, or oslo). This list can also be expressed as a list of servers (separated by commas and followed by a colon) and the pathname (as long as the pathname is the same for all of the specified servers), for example:
/usr/man -ro,soft london,madrid,oslo:/usr/manThe first server to respond to the RPC ping issued by automount is selected, and an attempt is made to mount from it. The list does not imply an ordering, although servers on the local network will be contacted first.
This redundancy, which is very useful in an environment where individual servers may or may not be exporting their filesystems, exists at mount time only. There is no status checking of the mounted-from server by automount once the mount occurs. If the server goes down while the mount is in effect, the filesystem becomes unavailable. An option here is to wait the default five minutes until the auto-unmount takes place and try again. Next time around, automount chooses one of the other, available servers. Another option is to use the umount command, inform automount of the change in the mount table (as specified in the section ``Stopping and restarting automount''), and retry the mount.
You can mount multiple remote filesystems to a single local directory with a direct mount configuration. This section compares the two ways in which you can configure direct multiple mounts with an analogous indirect mount.
``An example of indirect mounting using automount'',
illustrates an indirect mount where two filesystems, each from
a different server, are mounted under a single parent directory.
In this indirect mount, each of the remote filesystems is mounted
only when that remote filesystem is accessed.
Further, if you access one directory, causing it to be mounted,
and then try to cd to the other using a relative path, the system
will not find or mount the other directory. For example:
../roff: No such file or directory
To reach /doc_tools/roff would require:
If you access /doc_tools/roff before executing cd ../roff, with the ls command for example, then /doc_tools/roff gets mounted and you can reach it using a relative path.
Here is an example showing one way in which you could mount the same two remote filesystems under a single parent, but using a direct mount configuration:
/doc_tools/spellers -ro,soft madrid:/doc.stuff/spellers /doc_tools/roff -ro,soft oslo:/doc/bin/roff
Like the indirect mount configuration, each of the remote filesystems here is mounted separately and only when that remote filesystem is accessed. With this configuration, if you access one directory, causing it to be mounted, and then try to cd to the other using a relative path, automount will mount the other filesystem and place the user in the desired directory if the user is running ksh. If the user is not running ksh, the system will not find or mount the other directory, as in the indirect map configuration.
Here is an example showing a second way in which you can mount the same two remote filesystems under a single parent, but using a single direct configuration.
/doc_tools \ /spellers -ro,soft madrid:/doc.stuff/spellers \ /roff -ro,soft oslo:/doc/bin/roff
With this configuration, both filesystems are mounted if either one is accessed. Because both filesystems are always mounted at the same time, a cd using a relative path between the two filesystems will work regardless of the shell being used. Note that the syntax of this configuration differs from the direct map syntax shown in ``About automount maps''. The parent directory appears on the first line with a ``\'' indicating a continued entry. Each subsequent line contains a mount point (that begins with a slash), options, and a location. Redundant locations can be specified as described in ``Specifying redundant servers''.
This ``unified mount'' has these advantages over the previous direct mount example:
The above examples show remote filesystems residing on different servers. The above examples would still be valid if all remote filesystems were from the same server or there were more than two remote filesystems being mounted and all were from different servers.
If unified direct mounts share the same options, it is not necessary to duplicate these options for each server. Rather, the options can precede the different mounts:
/doc_tools -ro,soft \ /spellers madrid:/doc.stuff/spellers \ /roff oslo:/doc/bin/roffIf one of the mount points needs a different specification, modify only its options:
/doc_tools -ro,soft \ /spellers -rw madrid:/doc.stuff/spellers \ /roff oslo:/doc/bin/roff
A special case of multiple direct mounts occurs when the root of a filesystem has to be mounted as well. This is called a ``hierarchical'' mount. A true hierarchical mount might be:
/usr/local \ / prague:/usr/local \ /bin -ro,soft tokyo:/usr/local/bin \ /src -ro milan:/usr/local/src