• Choose a category
• All
• Classic-Fiction

Managing /tools with the automounter offers several advantages. All of the individual mount points are replaced by a single map that creates the appropriate mount points as needed. The automounter mount point contains only the handful of entries corresponding to the working set of tools that the user employs at any one time. It's also much simpler to add a new tool: instead of having to create the mount point and edit /etc/vfstab on every host in the network, you simply update the NIS-managed automounter map.

Finally, the automounter looks for a filesystem on one of several servers. Manual pages, read-only libraries, and other replicated filesystems will be mounted from the first server in a set to respond to the mount request. In addition to providing a simple load-balancing scheme similar to that of NIS, the automounter removes single-host dependencies that would make a diskless or dataless workstation unusable in the event of a server crash.

Automounter maps

The behavior of the automounter is governed by its maps. An indirect map is useful when you are mounting several filesystems with common pathname prefixes (as seen on the clients, not necessarily on the servers). A good example is the /tools directory described previously, although home directories also fit the indirect map model well. A direct map is used for irregularly named filesystems, where each mount point does not have a common prefix with other mount points. Some good examples of mounts requiring direct maps are /usr/local and /usr/man.

Direct and indirect maps vary in how the automounter emulates the underlying mount point. For a direct map, the automounter looks like a symbolic link at each mount point in the map. With an indirect map, the automounter emulates a directory of symbolic links, where the directory is the common pathname prefix shared by all of the automounter-managed mount points. This is confusing and is best explained by the examples that follow.

The master map is a meta-map (a map describing other maps). It contains a list of indirect maps and direct mount points and tells the automounter where to look for all of its map information. We'll look at a typical master map after seeing how the indirect and direct maps are used to mount NFS filesystems.

Indirect maps

Indirect maps are the simplest and most useful automounter convention. They correspond directly to regularly named filesystems, such as home directories, desktop tools, and system utility software. While tools directories may not be consistently named across fileservers, for example, you can use NFS mounts to make them appear consistent on a client machine. The automounter replaces all of the /etc/vfstab entries that would be required to effect this naming scheme on the clients.

Each indirect map has a directory associated with it that is specified on the command line or in the master map (see Section 9.2.1 later in this chapter). The map itself contains a key, which is the name of the mount point in the directory, optional NFS mount options, and the server:pathname pair identifying the source of the filesystem. Automounter maps are usually named auto_contents, where contents describes the map. The map name does not have to correspond to its mount point — it can be anything that indicates the map's function. Maps are placed in /etc or maintained via NIS.

The best way to understand how an indirect map works is to look at an example. We'll look at an automounter map and equivalent vfstab file for a directory structure like this:

/tools/deskset

/tools/sting

/tools/news

/tools/bugview

Here is an indirect automounter map for the /tools directory, called auto_tools:

deskset -ro mahimahi:/tools2/deskset

sting mahimahi:/tools2/sting

news thud:/tools3/news

bugview jetstar:/usr/bugview

The first field is called the map key and is the final component of the mount point. The map name suffix and the mount point do not have to share the same name, but adopting this