Autofs
When a network contains even a moderate number of systems, all trying to mount file systems from each other, managing NFS can quickly become a nightmare. The Autofs facility, also called the automounter, is designed to handle such situations by providing a method by which remote directories are mounted only when they are being used.
When a user or application accesses an NFS mount point, the mount is established. When the file system is no longer needed or has not been accessed for a certain period, the file system is automatically unmounted. As a result, network overhead is lower, the system boots faster because NFS mounts are done later, and systems can be shut down with fewer ill effects and hung processes.
File systems shared through the NFS service can be mounted using Autofs. Autofs, a client-side service, is a file system structure that provides automatic mounting. The Autofs file system is initialized by automount, which is run automatically when a system is started. The automount daemon, named automountd, runs continuously, mounting and unmounting remote directories on an as-needed basis.
Mounting does not need to be done at system startup, and the user no longer needs to know the superuser password to mount a directory. With Autofs, users do not use the mount and umount commands. The Autofs service mounts file systems as the user accesses them and unmounts file systems when they are no longer required, without intervention on the part of the user.
However, some file systems still need to be mounted using the mount command with root privileges. For example, a diskless computer must mount / (root), /usr, and /usr/kvm using the mount command and cannot take advantage of Autofs.
Two programs support the Autofs service: automount and automountd. Both are run when a system is started by the /etc/init.d/autofs script.
The automount service sets up the Autofs mount points and associates the information in the auto_master files with each mount point. The automount command, called at system startup time, reads the master map file named auto_master to create the initial set of Autofs mounts. These mounts are not automatically mounted at startup time. They are trigger points, also called trigger nodes, under which file systems are mounted in the future. The syntax for automount is shown here:
automount -t <duration> -v -t <duration> sets the time, in seconds, that a file system is to remain mounted if it is not being used.
-v selects verbose mode. Running this command in verbose mode allows easier troubleshooting.
If not specifically set, the value for duration of an unused mount is set to 10 minutes. In most circumstances, this value is good; however, on systems that have many automounted file systems, you might need to increase the duration value. In particular, if a server has many users, active checking of the automounted file systems every 10 minutes can be inefficient. By unmounting the file systems every five minutes, it is possible that /etc/ mnttab, which is checked by df, can become large. Checking the Autofs file systems every 1,800 seconds (30 minutes) could be more optimal. Edit the /etc/init.d/ autofs script to change the default values.
If Autofs receives a request to access a file system that is not currently mounted, Autofs calls automountd, which actually mounts the requested file system under the trigger node.
The automountd daemon handles the mount and unmount requests from the Autofs service. The syntax of the command is as follows:
automountd < -Tnv > < -D name=value >
-T displays each Remote Procedure Call (RPC) to standard output. Use this option for troubleshooting.
-n disables browsing on all Autofs nodes.
-v logs all status messages to the console.
-D <name>=<value> substitutes value for the automount map variable indicated by name . The default value for the automount map is /etc/auto_master.
The automountd daemon is completely independent from the automount command. Because of this separation, it is possible to add, delete, or change map information without first having to stop and start the automountd daemon process.
To illustrate Autofs in action, here is what happens:
automount and automountd initiate at startup time from the /etc/init.d/ autofs script. If a request is made to access a file system at an Autofs mount point, the system goes through the following steps:
1. |
Autofs intercepts the request. |
2. |
Autofs sends a message to the automountd daemon for the requested file system to be mounted. |
3. |
automountd locates the file system information in a map and performs the mount. |
4. |
Autofs allows the intercepted request to proceed. |
5. |
Note
Mounts managed through the Autofs service should not be manually mounted or unmounted. Even if the operation is successful, the Autofs service does not check that the object has been unmounted, resulting in possible inconsistency. A restart clears all Autofs mount points.
To see who might be using a particular NFS mount, use the showmount command. The syntax for showmount is shown here:
showmount <options> The options are described in Table 22.7.
The following example illustrates the use of showmount to display file systems currently mounted from remote systems. On the NFS server named neptune, I typed the following command:
showmount –a
The system displays the following information:
apollo:/export/home/neil
showmount tells you that the remote host, apollo, is currently mounting /export/home/neil on this server.
Autofs Maps
The behavior of the automounter is governed by its configuration files, called maps. Autofs searches these maps to navigate its way through the network. Map files contain information, such as the password entries of all users on a network or the names of all host computers on a network.
Master Map
To start the navigation process, the automount command reads the master map at system startup. This map is what tells the automounter about map files and mount points. The master map lists all direct and indirect maps and their associated directories.
The master map, which is in the / etc/auto_master file, associates a directory with a map. The master map is a list that specifies all the maps that Autofs should check. The following example shows what an auto_master file could contain:
# Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn –xfn
This example shows the default auto_master file. The lines beginning with # are comments. The line that contains +auto_master specifies the Autofs NIS table map, which is explained in Chapter 23, “Name Services.” Each line thereafter in the master map, /etc/auto_master, has the following syntax:
<mount-point> <map-name> <mount-options>
Each field is described in Table 22.8.
| Field | Description |
|---|---|
| mount-point | The full (absolute) pathname of a directory that is used as the mount point. If the directory does not exist, Autofs creates it, if possible. If the directory does exist and is not empty, mounting it hides its contents. In this case, Autofs issues a warning. Using the notation /- as a mount point indicates that a direct map with no particular mount point is associated with the map. |
| map-name | The map that Autofs uses to find directions to locations or mount information. If the name is preceded by a slash (/), Autofs interprets the name as a local file. Otherwise, it searches for the mount information using the search specified in the name-service switch configuration file (/etc/nsswitch.conf). Name service switches are described in Chapter 23. |
| mount-options | An optional comma-separated list of options that apply to the mounting of the entries specified in map-name , unless the entries list other options. Options for each specific type of file system are listed in Table 22.3 under the mount command syntax. For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply. |
Note
A line beginning with a number sign (#) is a comment, and everything that follows it until the end of the line is ignored. To split long lines into shorter ones, put a backslash () at the end of the line. The maximum number of characters in an entry is 1,024.
Every Solaris installation comes with a master map, called /etc/auto_master, that has the default entries just shown. Without changes to the generic system setup, clients should be capable of accessing remote file systems through the /net mount point. The following entry in /etc/auto_master allows this to happen:
/net -hosts -nosuid,nobrowse
For example, let’s say that you have an NFS server named apollo that has the /export file system exported. Another system exists on the network named zeus. This system has the default /etc/auto_master file; by default, it has a directory named /net. If you type this, the command comes back showing that the directory is empty—nothing is in it:
ls /net
Now type this:
ls /net/apollo
The system responds with this:
export
Why was it empty the first time you issued the ls command? When you issued ls /net/apollo, why did it find a subdirectory? This is the automounter in action. When you specified /net with a hostname, automountd looked at the map file—in this case, /etc/hosts—and found apollo and its IP address. It then went to apollo, found the exported file system, and created a local mount point for /net/apollo/export. It also added this entry to the /etc/ mnttab file:
-hosts /net/apollo/export autofs nosuid,nobrowse,ignore,nest,dev=2b80005 941812769
This entry in the / etc/mnttab file is referred to as a trigger node.
If you type mount, you won’t see anything mounted at this point:
mount
The system responds with this:
/ on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /proc on /proc read/write/setuid on Mon Nov 1 06:05:46 2001 /dev/fd on fd read/write/setuid on Mon Nov 1 06:05:46 2001 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on Mon Nov 1 06:05:49 2001 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on Mon Nov 1 06:5:49 2001 /tmp on swap read/write on Mon Nov 1 06:05:49 2001
Now type this:
ls /net/apollo/export
You’ll notice a bit of a delay while automountd mounts the file system; the system then responds with this:
files lost+found
The files listed are files located on apollo in the /export directory. If you type mount, you’ll see a file system mounted on apollo that wasn’t listed before:
mount / on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /proc on /proc read/write/setuid on Mon Nov 1 06:05:46 2001 /dev/fd on fd read/write/setuid on Mon Nov 1 06:05:46 2001 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on Mon Nov 1 06:05:49 2001 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on Mon Nov 1 06:05:49 2001 /tmp on swap read/write on Mon Nov 1 06:05:49 2001 /net/apollo/export on apollo:/export nosuid/remote on Fri Nov 5 09:48:03 2001
The automounter automatically mounted the /export file system that was located on apollo. Now look at the /etc/mnttab file again, and you see additional entries:
more /etc/mnttab /dev/dsk/c0t3d0s0 / ufs rw,suid,dev=800018,largefiles 941454346 /dev/dsk/c0t3d0s6 /usr ufs rw,suid,dev=80001e,largefiles 941454346 /proc /proc proc rw,suid,dev=2940000 941454346 fd /dev/fd fd rw,suid,dev=2a00000 941454346 /dev/dsk/c0t3d0s3 /export ufs suid,rw,largefiles,dev=80001b 941454349 /dev/dsk/c0t3d0s4 /export/swap ufs suid,rw,largefiles,dev=80001c 941454349 swap /tmp tmpfs dev=1 941454349 -hosts /net autofs ignore,indirect,nosuid,nobrowse,dev=2b80001 941454394 auto_home /home autofs ignore,indirect,nobrowse,dev=2b80002 941454394 -xfn /xfn autofs ignore,indirect,dev=2b80003 941454394 sparcserver:vold(pid246) /vol nfs ignore,noquota,dev=2b40001 941454409 -hosts /net/apollo/export autofs nosuid,nobrowse,ignore,nest,dev=2b80005 941812769 apollo:/export /net/apollo/export nfs nosuid,dev=2b40003 941813283
If the /net/apollo/export directory is accessed, the Autofs service completes the process with these steps:
Direct Map
A direct map lists a set of unrelated mount points that might be spread out across the file system. A complete path (that is, /usr/local/bin or /usr/man) is listed in the map as a mount point. The best example of where to use a direct mount point is for /usr/man. The /usr directory contains many other directories, such as /usr/bin and /usr/local; therefore, it cannot be an indirect mount point. If you used an indirect map for /usr/man, the local /usr file system would be the mount point, and you would cover up the local /usr/ bin and /usr/etc directories when you established the mount. A direct map lets automounter complete mounts on a single directory entry such as /usr/ man, appearing as a link with the name of the direct mount point.
A direct map is specified in a configuration file called /etc/auto_direct. With a direct map, there is a direct association between a mount point on the client and a directory on the server. Direct maps have a full pathname and indicate the relationship explicitly. This is a typical /etc/auto_direct map:
/usr/local -ro
/bin ivy:/export/local/sun4
/share ivy:/export/local/share
/src ivy:/export/local/src
/usr/man -ro apollo:/usr/man
zeus:/usr/man
neptune:/usr/man
/usr/game -ro peach:/usr/games
/usr/spool/news -ro jupiter:/usr/spool/news
saturn:/var/spool/news Note
A backslash at the end of a line splits it into two shorter lines. The operating system sees it as one line.
Lines in direct maps have the following syntax:
<key> <mount-options> <location>
The fields are described in Table 22.9.
| Field | Description |
|---|---|
| key | Indicates the pathname of the mount point in a direct map. This pathname specifies the local directory on which to mount the NFS file system. |
| mount-options | Indicates the options you want to apply to this particular mount. They are required only if they differ from the map default options specified in the /etc/auto_master file. Options are listed in Table 22.3 under the mount command syntax. There is no concatenation of options between the automounter maps. Any options added to an automounter map override all the options listed in previously searched maps. For instance, options included in the auto_master map would be overwritten by corresponding entries in any other map. |
| location | Indicates the remote location of the file system specified as server:pathname. More than one location can be specified. The pathname should not include an automounted mount point; it should be the actual absolute path to the file system. For instance, the location of a home directory should be listed as server:/ export/home/username, not as server:/home/username. |
In the previous example of the /etc/auto_direct map file, the mount points, /usr/man and /usr/spool/news, list more than one location:
/usr/man -ro apollo:/usr/man
zeus:/usr/man
neptune:/usr/man
/usr/spool/news -ro jupiter:/usr/spool/news
saturn:/var/spool/news Multiple locations, such as those shown here, are used for replication, or failover. For the purposes of failover, a file system can be called a replica if each file is the same size and is the same type of file system. Permissions, creation dates, and other file attributes are not a consideration. If the file size or the file system types are different, the remap fails and the process hangs until the old server becomes available.
Replication makes sense only if you mount a file system that is read-only because you must have some control over the locations of files that you write or modify. You don’t want to modify one server’s files on one occasion and, minutes later, modify the “same” file on another server. The benefit of replication is that the best available server is used automatically without effort required by the user.
If the file systems are configured as replicas, the clients have the advantage of using failover. Not only is the best server automatically determined, but, if that server becomes unavailable, the client automatically uses the next-best server.
An example of a good file system to configure as a replica is the manual (man) pages. In a large network, more than one server can export the current set of manual pages. Which server you mount them from doesn’t matter, as long as the server is running and exporting its file systems. In the previous example, multiple mount locations are expressed as a list of mount locations in the map entry. With multiple mount locations specified, you can mount the man pages from the apollo, zeus, or neptune servers. The best server depends on a number of factors, including the number of servers supporting a particular NFS protocol level, the proximity of the server, and weighting. The process of selecting a server goes like this:
With failover, the sorting is checked once at mount time, to select one server from which to mount, and again if the mounted server becomes unavailable. Failover is particularly useful in a large network with many subnets. Autofs chooses the nearest server and therefore confines NFS network traffic to a local network segment. In servers with multiple network interfaces, Autofs lists the hostname associated with each network interface as if it were a separate server. It then selects the nearest interface to the client.
In this example, you set up a direct map for /usr/local on zeus. Currently, zeus has a directory called /usr/local with the following directories:
ls /usr/local
The following local directories are displayed:
bin etc files programs
If you set up the automount direct map, you’ll see how the /usr/local directory is overwritten by the NFS mount.
First, you need to add the following entry in the master map file called /etc/auto_master:
/- /etc/auto_direct
Next, create the direct map file called /etc/auto_direct with the following entry:
/usr/local zeus:/usr/local
Because you’re modifying a direct map, you need to stop and restart automount as follows:
/etc/init.d/autofs stop /etc/init.d/autofs start
Now, if you have access to the /usr/local directory, the NFS mount point is established using the direct map you have set up. The contents of /usr/local have changed because the direct map has covered up the local copy of /usr/local:
ls /usr/local
You’ll see the following directories listed:
fasttrack answerbook
Note
The local contents of /usr/local have not been overwritten. After the NFS mount point is unmounted, the original contents of /usr/local are redisplayed.
By typing the mount command, you see that /usr/local is now mounted remotely from zeus:
mount / on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on Mon Nov 1 06:05:46 2001 /proc on /proc read/write/setuid on Mon Nov 1 06:05:46 2001 /dev/fd on fd read/write/setuid on Mon Nov 1 06:05:46 2001 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on Mon Nov 1 06:05:49 2001 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on Mon Nov 1 06:05:49 2001 /tmp on swap read/write on Mon Nov 1 06:05:49 2001 /usr/local on zeus:/usr/local read/write/remote on Sat Nov 6 08:06:40 2001
Indirect Map
Indirect maps are the simplest and most useful automounter conventions. An indirect map uses a key’s substitution value to establish the association between a mount point on the client and a directory on the server. Indirect maps are useful for accessing specific file systems, such as home directories, from anywhere on the network. The following entry in the /etc/auto_master file is an example of an indirect map:
/share /etc/auto_share
With this entry in the /etc/auto_master file, / etc/auto_share is the name of the indirect map file for the mount point /share. For this entry, you also need to create an indirect map file named /etc/auto_share, which would look like this:
# share directory map for automounter # ws neptune:/export/share/ws
If the /share directory is accessed, the Autofs service creates a trigger node for /share/ws, and the following entry is made in the /etc/mnttab file:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###
If the /share/ws directory is accessed, the Autofs service completes the process with these steps:
1. |
It pings the server’s mount service to see if it’s alive. |
2. |
Lines in indirect maps have the following general syntax:
<key> <mount-options> <location>
The fields in this line are described in Table 22.10.
| Field | Description |
|---|---|
| key | A simple name (no slashes) in an indirect map. |
| mount-options | The options you want to apply to this particular mount. Described in Table 22.3, these options are required only if they differ from the map default options specified in the /etc/ auto_master file. |
| location | The remote location of the file system, specified as server:pathname. More than one location can be specified. The pathname should not include an automounted mount point; it should be the actual absolute path to the file system. For instance, the location of a directory should be listed as server:/usr/local, not as server:/net/ server/usr/local. |
An example of an indirect map is when using user home directories. As users log into several different systems, their home directories are not always local to the system. It’s convenient to use automounter to access their home directories regardless of the system to which they log in. To accomplish this, the default /etc/auto_master map file needs to contain the following entry:
/home /etc/auto_home -nobrowse
/ etc/auto_home is the name of the indirect map file that contains the entries to be mounted under /home. A typical /etc/auto_home map file might look like this:
more /etc/auto_home dean willow:/export/home/dean william cypress:/export/home/william nicole poplar:/export/home/nicole glenda pine:/export/home/glenda steve apple:/export/home/steve burk ivy:/export/home/burk neil -rw,nosuid peach:/export/home/neil
Now let’s assume that the /etc/auto_home map is on the host oak. If user neil has an entry in the password database specifying his home directory as /home/neil, whenever he logs in to computer oak, Autofs mounts the directory /export/home/neil residing on the computer peach. His home directory is mounted read/write, nosuid. Anyone, including Neil, has access to this path from any computer set up with the master map referring to the /etc/ auto_home map in this example.
Under these conditions, user neil can run login, or rlogin, on any computer that has the /etc/auto_home map set up, and his home directory is mounted in place for him.
Another example of when to use an indirect map is when you want to make all project-related files available under a directory called /data. This directory is to be common across all workstations at the site.
Exercise 22.3 Setting Up an Indirect Map
Follow these steps to set up the indirect map:
1. |
Add an entry for the /data directory to the /etc/auto_master map file: /data /etc/auto_data -nosuid The auto_data map file, named /etc/auto_data, determines the contents of the /data directory. |
2. |
Add the -nosuid option as a precaution. The -nosuid option prevents users from creating files with the setuid or setgid bit set. Refer to Chapter 16 if you’re unfamiliar with setuid/setgid. |
3. |
Create the /etc/auto_data file and add entries to the auto_data map. The auto_data map is organized so that each entry describes a subproject. Edit /etc/auto_data to create a map that looks like the following: compiler apollo:/export/data/& window apollo:/export/data/& files zeus:/export/data/& drivers apollo:/export/data/& man zeus:/export/data/& tools zeus:/export/data/& Note The ampersand (&) at the end of each entry is an abbreviation for the entry key. For instance, the first entry is equivalent to compiler apollo:/export/data/compiler. |
4. | |
5. |
Type mount to see the mount point that was established: mount The system shows that /data/compiler is mapped to the apollo:/export/ data/ compiler as follows: /data/compiler on apollo:/export/data/compiler read/write/remote on Fri Nov 5 17:17:02 2001 If the user changes to /data/tools, the mount point to zeus:/export/data/ tools is created under the mount point /data/tools. |
Note
There is no need to create the directory /data/compiler to be used as the mount point. Automounter creates all the necessary directories before establishing the mount.
The system administrator can modify, delete, or add entries to maps to meet the needs of the environment. As applications (and other file systems that users require) change their location, the maps must reflect those changes. You can modify Autofs maps at any time. However, changes do not take place until the file system is unmounted and remounted. If a change is made to the auto_master map or to a direct map, those changes do not take place until the automounter is restarted, as follows:
/etc/init.d/autofs stop /etc/init.d/autofs start
Another method is to force auto_master and direct map changes to be recognized immediately by running automount from the command line, as follows:
automount –v