Explain how to configure AutoFS using automount maps.
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 automatically, only when they are being used. AutoFS, a client-side service, is a file system structure that provides automatic mounting.
When a user or an 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 via AutoFS. AutoFS is initialized by automount, which is run automatically when a system is started. The automount daemon, 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 does not need to know the superuser password to mount a directory (normally file system mounts require superuser privilege). 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 any intervention on the part of the user.
However, some file systems still need to be mounted by using the mount command with root privileges. For example, on a diskless computer you must mount / (root), /usr, and /usr/kvm by using the mount command, and you cannot take advantage of AutoFS.
Two programs support the AutoFS service: automount and automountd. Both are run when a system is started by the svc:/system/filesystem/autofs:default service identifier.
The automount service sets up the AutoFS mount points and associates the information in the /etc/auto_master files with each mount point. The automount command, which is called at system startup time, reads the master map file /etc/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 following is the syntax for automount:
automount -t <duration> -v
Table 9.11 describes the syntax options for the automount command.
If it is 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 decrease the duration value. In particular, if a server has many users, active checking of the automounted file systems every 10 minutes can be inefficient. Checking AutoFS every 300 seconds (5 minutes) might be better. You can edit the /etc/default/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 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 this command is as follows:
automountd < -Tnv > < -D name=value >
Table 9.12 describes the syntax options for the automountd command.
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.
When AutoFS runs, automount and automountd initiate at startup time from the svc:/system/filesystem/autofs service identifier. If a request is made to access a file system at an AutoFS mount point, the system goes through the following steps:
Automatic, Not Manual, Mounts 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, and this can result in possible inconsistency. A restart clears all AutoFS mount points.
The options for the showmount command are described in Table 9.13.
The following example illustrates the use of showmount to display file systems currently mounted from remote systems. On the NFS server named neptune, you could enter the following command:
The system would display the following information:
The behavior of the automounter is governed by its configuration files, called maps. AutoFS searches maps to navigate its way through the network. Map files contain information, such as the location of other maps to be searched or the location of a user's home directory, for example.
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
This example shows the default auto_master file. The lines that begin with # are comments. The line that contains +auto_master specifies the AutoFS NIS table map, which is explained in Chapter 12, "Naming Services." Each line thereafter in the master map, /etc/auto_master, has the following syntax:
<mount-point> <map-name> <mount-options>
Each of these fields is described in Table 9.14.
Map Format A line that begins with a pound sign (#) is a comment, and everything that follows it until the end of the line is ignored. To split long lines into shorter ones, you can 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 shown in Table 9.14. Without any 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, named zeus, exists on the network. This system has the default /etc/auto_master file; by default, it has a directory named /net. If you type the following, the command comes back showing that the directory is emptynothing is in it:
Now type this:
The system responds with this:
Why was the /net directory 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 filein this case, /etc/hostsand 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 table:
-hosts /net/apollo/export autofs nosuid,nobrowse,ignore,nest,\ dev=2b80005 941812769
The system responds with this:
/ on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on \ Mon Aug 8 09:45:21 2005 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \ Mon Aug 8 09:45:21 2005 /proc on /proc read/write/setuid on Mon Aug 8 09:45:21 2005 /dev/fd on fd read/write/setuid on Mon Aug 8 09:45:21 2005 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 2005 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 \ 2005 /tmp on swap read/write on Mon Aug 8 09:45:24 2005
Now type this:
You should have a bit of a delay while automountd mounts the file system. The system then responds with this:
The files listed are files located on apollo, in the /export directory. If you enter mount, you see a file system mounted on apollo that wasn't listed before:
mount / on /dev/dsk/c0t3d0s0 read/write/setuid/largefiles on \ Mon Aug 8 09:45:21 2005 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \ Mon Aug 8 09:45:21 2005 /proc on /proc read/write/setuid on Mon Aug 8 09:45:21 2005 /dev/fd on fd read/write/setuid on Mon Aug 8 09:45:21 2005 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 2005 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 \ 2005 /tmp on swap read/write on Mon Aug 8 09:45:24 2005 /net/apollo/export on apollo:/export nosuid/remote on \ Fri Aug 12 09:48:03 2005
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:
Because the automounter lets all users mount file systems, root access is not required. AutoFS also provides for automatic unmounting of file systems, so there is no need to unmount them when you are done.
A direct map lists a set of unrelated mount points that might be spread out across the file system. A complete path (for example, /usr/local/bin, /usr/man) is listed in the map as a mount point. A good 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 the automounter complete mounts on a single directory entry such as /usr/man, and these mounts appear as links 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. A direct map has a full pathname and indicates the relationship explicitly. This is a typical /etc/auto_direct map:
/usr/local -ro /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
Map Naming The direct map name /etc/auto_direct is not a mandatory name; it is used here as an example of a direct map. The name of a direct map must be added to the /etc/auto_master file, but it can be any name you choose, although it should be meaningful to the system administrator.
Lines in direct maps have the following syntax:
<key> <mount-options> <location>
The fields of this syntax are described in Table 9.15.
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 it 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 any 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 man 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 could 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 the following example, you set up a direct map for /usr/local on zeus. Currently, zeus has a directory called /usr/local with the following directories:
The following local directories are displayed:
bin etc files programs
If you set up the automount direct map, you can see how the /usr/local directory is overwritten by the NFS mount. Follow the procedure shown in Step by Step 9.6.
Overlay Mounting 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.
If you enter 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 Aug 8 09:45:21 2005 /usr on /dev/dsk/c0t3d0s6 read/write/setuid/largefiles on \ Mon Aug 8 09:45:21 2005 /proc on /proc read/write/setuid on Mon Aug 8 09:45:21 2005 /dev/fd on fd read/write/setuid on Mon Aug 8 09:45:21 2005 /export on /dev/dsk/c0t3d0s3 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 2005 /export/swap on /dev/dsk/c0t3d0s4 setuid/read/write/largefiles on \ Mon Aug 8 09:45:24 2005 /tmp on swap read/write on Mon Aug 8 09:45:24 2005 /usr/local on zeus:/usr/local read/write/remote on \ Sat Aug 13 08:06:40 2005
Indirect maps are the simplest and most useful AutoFS maps. 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:
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 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:
Lines in indirect maps have the following syntax:
<key> <mount-options> <location>
The fields in this syntax are described in Table 9.16.
For example, say an indirect map is being used with user home directories. As users log in to several different systems, their home directories are not always local to the system. It's convenient for the users to use the automounter to access their home directories, regardless of what system they're logged in to. 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
Indirect Map Names As with direct maps, the actual name of an indirect map is up to the system administrator, but a corresponding entry must be placed in the /etc/auto_master file, and the name should be meaningful to the system administrator.
Now assume that the /etc/auto_home map is on the host oak. If user neil has an entry in the password database that specifies his home directory as /home/neil, whenever he logs in to computer oak, AutoFS mounts the directory /export/home/neil, which resides on the computer peach. Neil's 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 that is to be common across all workstations at the site. Step by Step 9.7 shows how to do this.
Directory Creation There is no need to create the directory /data/compiler to be used as the mount point. AutoFS creates all the necessary directories before establishing the mount.
You 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 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 AutoFS tables are reloaded, as follows:
Direct Versus Indirect Maps Remember the difference between direct and indirect maps. The /- entry in /etc/auto_master signifies a direct map because there is no mount point specified. This means that an absolute pathname is specified in the map. Indirect maps contain relative addresses, so the starting mount point, such as /home, appears in the /etc/auto_master enTRy for an indirect map.
When to Use automount
The most common and most advantageous use of automount is for mounting infrequently used file systems on an NFS client, such as online reference man pages. Another common use is accessing user home directories anywhere on the network. This works well for users who do not have a dedicated system and who tend to log in from different locations. Without the AutoFS service, to permit access, a system administrator has to create home directories on every system that the user logs in to. Data has to be duplicated everywhere, and it can easily become out of sync. You certainly don't want to create permanent NFS mounts for all user home directories on each system, so mounting infrequently used file systems on an NFS client is an excellent use for automount.
You also use automount if a read-only file system exists on more than one server. By using automount instead of conventional NFS mounting, you can configure the NFS client to query all the servers on which the file system exists and mount from the server that responds first.
You should avoid using automount to mount frequently used file systems, such as those that contain user commands or frequently used applications; conventional NFS mounting is more efficient in this situation. It is quite practical and typical to combine the use of automount with conventional NFS mounting on the same NFS client.