| By using NFS we have managed to create a series of static NFS mounts on the machines around the system, with the only ongoing task being to maintain /etc/dfstab on the servers and /etc/vfstab on the clients. This works fine, but after a while we may start to notice a few things, such as: Some mounts are hardly used for most of the time. For example, users may have their home directories NFS-mounted onto a machine they never actually log on to. As the number of servers increases, we can start to see "cross-mounting" problems.
To explain cross-mounts, let's look at the present setup. Helium is the NFS server and so must be available before all the other machines boot up; otherwise, any hard mounts will force the clients to hang when they boot. As long as we are aware of this we can work around this issue. Now let's alter the server configuration so that, say, helium becomes the NFS application server and carbon the server for the user's home directories. Each machine needs to mount the other's resources, so we now have cross-mounts between them. This means that if they were both rebooted at the same time, helium would hang waiting for carbon, and vice versa. We could actually work around this by mounting the resources with the background option, but Autofs provides another solution and also allows us to free up the redundant user mounts we mentioned earlier. Autofs works by allowing us to define a series of mount points, along with the devices that will be automatically mounted when they are required. When a user needs to access any data within an Autofs mounted area, the request will be intercepted and the device will be mounted, transparently to the users. After a predefined inactivity period, the mounted device will be unmounted, again by Autofs. The Autofs service is started at boot-time by a script named /etc/init.d/autofs, which runs two programsautomount and its daemon automountd. The automount process is responsible for determining all the mount points that it needs to control, which are defined in a series of plain-text files known as "maps." The automountd daemon carries out the actual mounting or unmounting of any devices as required. Three types of maps can be used: the master map, direct maps, and indirect maps. Master Map This is named /etc/auto_master and is the first map read by the automount process. Each line consists of the path name of a directory controlled by Autofs, followed by the name of the submap that contains the actual mount details, and finally any options for automount to use. These options are only used if the submap itself doesn't contain any options. Each directory is known as a "trigger node." This is used by Autofs to detect when its resource needs mounting. An example master map is shown below: helium# cat /etc/auto_master # # Master map for automounter # /net -hosts -nosuid,nobrowse /xfn -xfn /home auto_indirect_map /- auto_direct_map helium# Predefined Maps The first two entries in the master map above, "/net" and "/xfn," refer to two predefined maps: -hosts and -xfn, respectively. There are actually three predefined maps available. These are shown in Table 18.8. Table 18.8. Predefined Autofs MapsMap Name | Description |
|---|
-hosts | Locates all the shared resources for the machines around the network and makes them available through Autofs. | -xfn | Mounts the initial context of the FNS (Federated Naming Service). | -null | Cancels the previous map that was linked to the directory mount point. |
Taking the hosts map as an example, we know that helium has /data/remote_files/general shared, so we would be able to list its contents using the commands below: <client># cd /net/helium/data/remote_files/general <client># ls <output from the ls> <client># We'll see an example of the null map later in the section "Included Maps" on page 453. Direct and Indirect Maps These maps are used within the master map and contain the actual mount information. The main difference between direct and indirect maps is that direct maps define the mount point as an absolute path name, whereas indirect maps use a relative path instead. Let's look at a few examples to explain this a little more. A common example of a direct map is one used to control the manual pages/usr/share/man. The syntax for the direct map would be as follows: helium# cat /etc/auto_man /usr/share/man -ro oxygen:/usr/share/man helium# Here we have specified that /usr/share/man on oxygen will be mounted, read-only, on the directory /usr/share/man. Because we have used an absolute directory as our mount point, we don't need to put that information in the master map. Instead a special key of "/-" is used in the directory field to signify that the map is a direct map. So, in this case, the corresponding master map entry would be as follows: /- auto_man An indirect map, on the other hand, only uses a relative path for its directory specification and so does need the remainder of its mount point specified in the master map. An often-used example of this would be user directories. The map below contains the directories of each of the users: helium# cat /etc/auto_home msmith helium:/data/users jgreen helium:/data/users helium# The corresponding master map entry for this would be as follows. /home auto_home The relative path of the user would be appended to the directory listed in the master map, which means that the home directory "msmith" would appear as /home/msmith. Map Naming Conventions All maps within Autofs can be put under the control of a naming service. This means that the normal /etc/nsswitch.conf changes will need to be made. It also means that when we refer to a map name, we normally use the filename only, rather than including the directory name as well. This is why in the master maps above we refer to auto_indirect_map and auto_direct_map, rather than /etc/auto_indirect_map and /etc/auto_direct_map. | 
