Resource Management and Network Services) (2024)

Autofs is a client-side service that automatically mounts the appropriatefile system. When a client attempts to access a file system that is not presentlymounted, the autofs file system intercepts the request and calls automountd to mount the requested directory. The automountd daemon locates the directory, mounts it within autofs, and replies.On receiving the reply, autofs allows the waiting request to proceed. Subsequentreferences to the mount are redirected by the autofs. No further participationis required by automountd until the file system is automaticallyunmounted by autofs after a period of inactivity.

The components that work together to accomplish automatic mounting arethe following:

• The automount command

• The autofs file system

• The automountd daemon

The automount command, which is called at systemstartup time, reads the master map file auto_master tocreate the initial set of autofs mounts. These autofs mounts are not automaticallymounted at startup time. These mounts are points under which file systemsare mounted in the future. These points are also known as trigger nodes.

After the autofs mounts are set up, these mounts can trigger file systemsto be mounted under them. For example, when autofs receives a request to accessa file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system.

After initially mounting autofs mounts, the automountcommand is used to update autofs mounts as necessary. The command comparesthe list of mounts in the auto_master map with the listof mounted file systems in the mount table file /etc/mnttab(formerly /etc/mtab). automount thenmakes the appropriate changes. This process allows system administrators tochange mount information within auto_master and havethose changes used by the autofs processes without having to stop and restartthe autofs daemon. After the file system is mounted, further access does notrequire any action from automountd until the file systemis automatically unmounted.

Unlike mount, automount does notread the /etc/vfstab file (which is specific to eachcomputer) for a list of file systems to mount. The automountcommand is controlled within a domain and on computers through the namespaceor local files.

The following is a simplified overview of how autofs works.

The automount daemon automountd starts at boot timefrom the /etc/init.d/autofs script (see Figure 16–1).This script also runs the automount command, which readsthe master map and installs autofs mount points. See How Autofs Starts the Navigation Process (Master Map)for more information.

Figure 16–1 /etc/init.d/autofs Script Starts automount

Autofs is a kernel file system that supports automatic mounting andunmounting.

When a request is made to access a file system at an autofs mount point,the following occurs:

1. Autofs intercepts the request.

2. Autofs sends a message to the automountd for the requestedfile system to be mounted.

3. automountd locates the file system informationin a map, creates the trigger nodes, and performs the mount.

4. Autofs allows the intercepted request to proceed.

5. Autofs unmounts the file system after a period of inactivity.

Note –

Mounts that are managed through the autofs service should notbe manually mounted or unmounted. Even if the operation is successful, theautofs service does not check that the object has been unmounted, resultingin possible inconsistencies. A reboot clears all of the autofs mount points.

How Autofs Navigates Through the Network (Maps)

Autofs searches a series of maps to navigate through the network. Mapsare files that contain information such as the password entries of all userson a network or the names of all host computers on a network. Effectively,the maps contain network-wide equivalents of UNIX administration files. Mapsare available locally or through a network name service such as NIS or NIS+.You create maps to meet the needs of your environment by using the SolsticeSystem Management Tools. See Modifying How Autofs Navigates the Network (Modifying Maps).

How Autofs Starts the Navigation Process (Master Map)

The automount command reads the master map at systemstartup. Each entry in the master map is a direct map name or an indirectmap name, its path, and its mount options, as shown in Figure 16–2.The specific order of the entries is not important. automountcompares entries in the master map with entries in the mount table to generatea current list.

Figure 16–2 Navigation Through the Master Map

Autofs Mount Process

What the autofs service does when a mount request is triggered dependson how the automounter maps are configured. The mount process is generallythe same for all mounts. However, the final result changes with the mountpoint that is specified and the complexity of the maps. Starting with theSolaris 2.6 release, the mount process has also been changed to include thecreation of the trigger nodes.

Simple Autofs Mount

To help explain the autofs mount process, assume that the followingfiles are installed.

$ cat /etc/auto_master# Master map for automounter#+auto_master/net -hosts -nosuid,nobrowse/home auto_home -nobrowse/xfn -xfn/share auto_share$ cat /etc/auto_share# share directory map for automounter#ws gumbo:/export/share/ws

When the /share directory is accessed, the autofsservice creates a trigger node for /share/ws, which canbe seen in /etc/mnttab as an entry that resembles thefollowing entry:

-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###

When the /share/ws directory is accessed, the autofsservice completes the process with these steps:

1. Pings the server's mount service to see if the service isalive.

2. Mounts the requested file system under /share.Now, the /etc/mnttab file contains the following entries:

   
   

   -hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####

Hierarchical Mounting

When multiple layers are defined in the automounter files, the mountprocess becomes more complex. Suppose that you expand the /etc/auto_shared file from the previous example to contain the following:

# share directory map for automounter#ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr

The mount process is basically the same as the previous example whenthe /share/ws mount point is accessed. In addition, a triggernode to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if itis accessed. In this example, /export/share/ws/usr mustexist on the NFS server in order for the trigger node to be created.

Caution –

Do not use the -soft option when specifyinghierarchical layers. Refer to Autofs Unmounting for an explanationof this limitation.

Autofs Unmounting

The unmounting that occurs after a certain amount of idle time is fromthe bottom up (reverse order of mounting). If one of the directories at ahigher level in the hierarchy is busy, only file systems below that directoryare unmounted. During the unmounting process, any trigger nodes are removedand then the file system is unmounted. If the file system is busy, the unmountfails and the trigger nodes are reinstalled.

Caution –

Do not use the -soft option when specifyinghierarchical layers. If the -soft option is used, requeststo reinstall the trigger nodes can time out. The failure to reinstall thetrigger nodes leaves no access to the next level of mounts. The only way toclear this problem is to have the automounter unmount all of the componentsin the hierarchy. The automounter can complete the unmount either by waitingfor the file systems to be automatically unmounted or by rebooting the system.

How Autofs Selects the Nearest Read-Only Files for Clients (MultipleLocations)

The example direct map contains the following:

/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src/usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man/usr/games -ro peach:/usr/games/usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news 

The mount points /usr/man and /usr/spool/news list more than one location, three locations for the first mountpoint, two locations for the second mount point. This means any of the replicatedlocations can provide the same service to any user. This procedure is sensibleonly when you mount a file system that is read-only, as you must have somecontrol over the locations of files that you write or modify. You don't wantto modify files on one server on one occasion and, minutes later, modify the “same”file on another server. The benefit is that the best available server is usedautomatically without any effort that is required by the user.

If the file systems are configured as replicas (see What Is a Replicated File System?),the clients have the advantage of using failover. Not only is the best serverautomatically determined, but if that server becomes unavailable, the clientautomatically uses the next-best server. Failover was first implemented inthe Solaris 2.6 release.

An example of a good file system to configure as a replica is man pages.In a large network, more than one server can export the current set of manpages. Which server you mount the man pages from does not matter if the serveris running and exporting its file systems. In the previous example, multiplemount locations are expressed as a list of mount locations in the map entry.

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man 

In this example, you can mount the man pages from the servers oak, rose, or willow. Whichserver is best depends on a number of factors, including the following:

• The number of servers that support a particular NFS protocollevel

• The proximity of the server

• The weighting

During the sorting process, a count is taken of the number of serversthat support the NFS version 2 and NFS version 3 protocols. Whichever protocolis supported on the most servers becomes the protocol that is supported bydefault. This selection provides the client with the maximum number of serversto depend on.

After the largest subset of servers with the same protocol version isfound, that server list is sorted by proximity. Servers on the local subnetare given preference over servers on a remote subnet. The closest server isgiven preference, which reduces latency and network traffic. Figure 16–3illustrates server proximity.

Figure 16–3 Server Proximity

If several servers that support the same protocol are on the local subnet,the time to connect to each server is determined and the fastest server isused. The sorting can also be influenced by using weighting (see Autofs and Weighting).

If version 3 servers are more abundant, the sorting process becomesmore complex. Normally, servers on the local subnet are given preference overservers on a remote subnet. A version 2 server can complicate matters, asa version 2 server might be closer than the nearest version 3 server. If aversion 2 server is on the local subnet and the closest version 3 server ison a remote subnet, the version 2 server is given preference. This preferenceis only checked if more version 3 servers exist than version 2 servers. Ifmore version 2 servers exist, only a version 2 server is selected.

With failover, the sorting is checked once at mount time to select oneserver from which to mount, and again anytime the mounted server becomes unavailable.Multiple locations are useful in an environment where individual servers mightnot export their file systems temporarily.

This feature is particularly useful in a large network with many subnets.Autofs chooses the nearest server and therefore confines NFS network trafficto a local network segment. In servers with multiple network interfaces, listthe host name that is associated with each network interface as if the interfacewere a separate server. Autofs selects the nearest interface to the client.

Autofs and Weighting

You can influence the selection of servers at the same proximity levelby adding a weighting value to the autofs map. For example:

/usr/man -ro oak,rose(1),willow(2):/usr/man

The numbers in parentheses indicate a weighting. Servers without a weightinghave a value of zero and, therefore, are most likely to be selected. The higherthe weighting value, the lower the chance that the server is selected.

Note –

All other server selection factors are more important than weighting.Weighting is only considered when selecting between servers with the samenetwork proximity.

Variables in a Map Entry

You can create a client-specific variable by prefixing a dollar sign($) to its name. The variable helps you to accommodatedifferent architecture types that are accessing the same file-system location.You can also use curly braces to delimit the name of the variable from appendedletters or digits. Table 16–3 shows the predefined mapvariables.

Table 16–3 Predefined Map Variables

You can use variables anywhere in an entry line except as a key. Forinstance, suppose that you have a file server that exports binaries for SPARCand x86 architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively. The clients can mount througha map entry such as the following:

/usr/local/bin -roserver:/usr/local/bin/$CPU

Now the same entry for all clients applies to all architectures.

Note –

Most applications that are written for any of the sun4 architecturescan run on all sun4 platforms, so the -ARCH variable is hard-codedto sun4 instead of sun4m.

Maps That Refer to Other Maps

A map entry +mapname that is used in a filemap causes automount to read the specified map as if it were included in thecurrent file. If mapname is not preceded by a slash,autofs treats the map name as a string of characters and uses the name-serviceswitch policy to find the map name. If the path name is an absolute path name, automount checks a local map of that name. If the map name startswith a dash (-), automount consultsthe appropriate built-in map, such as xfn or hosts.

This name service switch file contains an entry for autofs that is labeledas automount, which contains the order in which the nameservices are searched. The following file is an example of a name serviceswitch file.

## /etc/nsswitch.nis:## An example file that could be copied over to /etc/nsswitch.conf;# it uses NIS (YP) in conjunction with files.## "hosts:" and "services:" in this file are used only if the /etc/netconfig# file contains "switch.so" as a nametoaddr library for "inet" transports.# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.passwd: files nisgroup: files nis# consult /etc "files" only if nis is down.hosts: nis [NOTFOUND=return] filesnetworks: nis [NOTFOUND=return] filesprotocols: nis [NOTFOUND=return] filesrpc: nis [NOTFOUND=return] filesethers: nis [NOTFOUND=return] filesnetmasks: nis [NOTFOUND=return] filesbootparams: nis [NOTFOUND=return] filespublickey: nis [NOTFOUND=return] filesnetgroup: nisautomount: files nisaliases: files nis# for efficient getservbyname() avoid nisservices: files nis 

In this example, the local maps are searched before the NIS maps. Therefore, you can have a few entries in your local /etc/auto_homemap for the most commonly accessed home directories. You can then use theswitch to fall back to the NIS map for other entries.

bill cs.csc.edu:/export/home/billbonny cs.csc.edu:/export/home/bonny

After consulting the included map, if no match is found, automount continues scanning the current map. Therefore, you can add moreentries after a + entry.

bill cs.csc.edu:/export/home/billbonny cs.csc.edu:/export/home/bonny+auto_home 

The map that is included can be a local file or a built-in map. Remember,only local files can contain + entries.

+auto_home_finance # NIS+ map+auto_home_sales # NIS+ map+auto_home_engineering # NIS+ map+/etc/auto_mystuff # local map+auto_home # NIS+ map+-hosts # built-in hosts map 

Note –

You cannot use + entries in NIS+ or NIS maps.

Executable Autofs Maps

You can create an autofs map that executes some commands to generatethe autofs mount points. You could benefit from using an executable autofsmap if you need to be able to create the autofs structure from a databaseor a flat file. The disadvantage to using an executable map is that the mapneeds to be installed on each host. An executable map cannot be included ineither the NIS or the NIS+ name service.

The executable map must have an entry in the auto_masterfile.

/execute auto_execute

Here is an example of an executable map:

#!/bin/ksh## executable map for autofs#case $1 in src) echo '-nosuid,hard bee:/export1' ;;esac

For this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set. Set permissions to 744. Under these circ*mstances, running the following command causesthe /export1 file system from bee tobe mounted:

% ls /execute/src

Modifying How Autofs Navigates the Network (Modifying Maps)

You can modify, delete, or add entries to maps to meet the needs ofyour environment. As applications and other file systems that users requirechange their location, the maps must reflect those changes. You can modifyautofs maps at any time. Whether your modifications are effective the nexttime automountd mounts a file system depends on which mapyou modify and what kind of modification you make.

Default Autofs Behavior With Name Services

Booting invokes autofs by using the /etc/init.d/autofsscript and checks for the master auto_master map. Autofsis subject to the rules that are discussed subsequently.

Autofs uses the name service that is specified in the automount entryof the /etc/nsswitch.conf file. If NIS+ is specified,as opposed to local files or NIS, all map names are used as is. If NIS isselected and autofs cannot find a map that autofs needs, but finds a map namethat contains one or more underscores, the underscores are changed to dots.This change allows the old NIS file names to work. Then autofs checks themap again, as shown in Figure 16–4.

Figure 16–4 How Autofs Uses the Name Service

The screen activity for this session would resemble the following example.

$ grep /home /etc/auto_master/home auto_home$ ypmatch brent auto_homeCan't match key brent in map auto_home. Reason: no such map inserver's domain.$ ypmatch brent auto.homediskus:/export/home/diskus1/&

If “files” is selected as the name service, all maps areassumed to be local files in the /etc directory. Autofsinterprets a map name that begins with a slash (/) as localregardless of which name service autofs uses.