Advanced AutoFS Administration

This section presents advanced AutoFS concepts that enable you to improve mounting efficiency and also help make map building easier. This section addresses:

Automounting Multiple Directories (Hierarchical Mounts)

AutoFS enables you to automount multiple directories simultaneously.

Use an editor to create an entry with the following format in a direct or indirect map, and if needed, create the auto_master entry:

local_dir   /local_subdirectory
[-options] \ server:remote_directory \
/local_subdirectory [-options] 
server:remote_directory \
...

Adding these map entries does not automatically mount them. The listed remote directories are mounted only when referenced. For example, the following entry from a direct map mounts the source code and the data files for a project whenever anyone requests access to both of them:

/our_project   /source   -ro    basil:/opt/proj1/src  \
               /datafiles    thyme:/opt/proj1/samples/data

The following is another example from an indirect map.

chap2 -nosuid   /text       thyme:/our_book/chap2  \
                /graphics   basil:/our_book/artwork/chap2 \
                 /old         thyme:/our_book/oldfiles/chap2

The nosuid mount option applies to all three automounted directories. For more information on the nosuid mount option, see automount(1M).

Configuring Replicated Servers for an AutoFS Directory

This section describes how to configure multiple replicated servers for an AutoFS directory.

Modify the entry that mounts the remote directory to list multiple servers in the appropriate map, as follows:

If the remote directories have the same name on every server, use a syntax such as the following from an indirect map:
man -ro broccoli,cabbage,cauliflower:/usr/share/man
You can assign a weighting factor to the servers by specifying a number in parentheses after each server name. If the server has a lower weighting number specified, it is likely to be selected. Servers that have no weight factor specified have a default weight of zero and are most likely to be selected.
man -ro broccoli(1),cabbage(2),cauliflower(3):/usr/share/man
However, server proximity is more important than the weighting factor you assign. A server on the same network segment as the client is more likely to be selected, than a server on another network segment, regardless of the weight you assign. The weighting factor is taken into account only when deciding between servers with the same network proximity.
If the remote directory has a different name on different servers, use a syntax such as the following from a direct map:
/nfs/proj2/schedule -ro \ broccoli:/export/proj2/schedule, \ cauliflower:/proj2/FY07/schedule

To configure multiple replicated servers for a directory, follow these steps:

Create and configure the /etc/netmasks file. AutoFS requires the /etc/netmasks file to determine the subnets of local clients in a replicated multiple server environment.
The /etc/netmasks file contains IP address masks with IP network numbers. It supports both standard subnetting as specified in RFC-950, and variable-length subnetting as specified in RFC-1519. For standard subnetting, the file must contain a single line for each network. This provides the network number and the network mask to be used on that network. Specify the network number and the mask using the conventional IP dot (.) notation. The network number must be either a class A, B, or C network number. For example:
network number netmask
128.32.0.0 255.255.255.0
For variable length subnetting, the /etc/netmasks file must contain a line for each subnet, where the first field refers to the subnet and the second field refers to the netmask. The format for specifying these fields is the same as that of standard subnetting.

Example of using the /etc/netmasks File

The following example shows how AutoFS uses the /etc/netmasks file to determine the local client subnets in a multiple-server environment. In this example, servers basil and thyme export/nfs/mount. The IP address for server basil is 15.43.232.30, and the IP address for the server, thyme is 15.244.10.20:

# /etc/auto_direct file

/nfs_mount basil,thyme:/nfs/mount

#/etc/netmasks file on the client sage:

#network number netmask

15.43.234.210 255.255.248.0

AutoFS uses the /etc/netmasks file to determine that the masked value for the subnet of basil and the network number is the same (15. 42. 232. 0). This shows that the client is on the same network as basil. AutoFS then mounts /nfs/mount from basil on the local subnet.

Notes on Configuring Replicated Servers

Directories with multiple servers must be mounted as read-only to ensure that the versions remain the same on all servers.

The server selected for the mount is the one with the highest preference, based on a sorting order. The sorting order used gives highest preference to servers on the same local subnet. Servers on the local network are given the second strongest preference. As a result, if you configure multiple servers on both sides of a gateway, a server on the same side of the gateway as the NFS client is always preferred. For multiple servers outside the local network, and with no weighting factors assigned, the server with the lowest response time is used for the mount.

Multiple servers provide users with reliable access to a mounted directory. If one server is down, the directory can be mounted from another. Moreover, multiple servers provide some load balancing across the network; a server that is not busy responds more quickly to an AutoFS poll than one that is heavily loaded. The directory is mounted from the server that is not busy.

If the list of multiple servers contains a combination of servers that includes all versions of the NFS protocol, then AutoFS selects a subset of servers with the highest NFS protocol version configured. For example, a list contains a number of servers configured with the NFSv4 protocol, and a few servers configured with the NFSv2 protocol. AutoFS will use the subnet of servers configured with the NFSv4 protocol, unless a server configured with the NFSv2 protocol is closer.

Including a Map in Another Map

If you want your map to refer to an external map, you can do so by including the external map in your map. The entries in the external map are read as if they are part of your map.

To include the contents of an AutoFS map in another AutoFS map, add a plus (+) sign before the map name, as in the following example:

# /etc/auto_home file
# local mount-point mount options remote server:directory

basil -nosuid         basil:/export/home/basil
+auto_new

Assume that the /etc/auto_home map is listed in the master map with the following line:

/home /etc/auto_home

If a user, whose home directory is in /home/basil, logs in, AutoFS mounts the /export/home/basil directory, from the host, basil.

If a user, whose home directory is in /home/sage, /home/thyme, or any subdirectory of /home other than basil, logs in, AutoFS consults the auto_home map for information on mounting the user’s home directory.

The plus (+) sign instructs AutoFS to look up a different map for the information it needs to mount the directory. If the map name following the plus sign begins with a slash, AutoFS assumes that it is a local file. If the map name contains no slashes, AutoFS uses the Name Service Switch to determine whether it is a file, NIS map, or an LDAP map.

You can include an AutoFS map inside a local file, but not inside an NIS or LDAP map.

For more information on including a map in another map, see automount(1M).

Creating a Hierarchy of AutoFS Maps

Hierarchical AutoFS maps provide a framework that enables you to organize large exported filesystems. Together with NIS, which allows you to share information across administrative domains, hierarchical maps enable you to decentralize the maintenance of a shared namespace.

Sample Map Hierarchy

In the following example, an organization consisting of many departments, wants to organize a shared automounted directory structure. The shared top-level directory is called /org. The /org directory contains several subdirectories, which are listed in the auto_org map. Each department administers its own map for its subdirectory.

The AutoFS master map needs only a single entry for /org as in the following example:

# auto_master map
# Directory           Map Name
/org                  auto_org

The auto_org map appears similar to the following:

finance    -fstype=autofs    auto_finance
marketing  -fstype=autofs    auto_marketing
legal      -fstype=autofs    auto_legal
research   -fstype=autofs    auto_research
eng        -fstype=autofs    auto_eng

The engineering department map, auto_eng, appears similar to the following:

releases                      bigiron:/export/releases
tools                         mickey,minnie:/export/tools
source      -fstype=autofs    auto_eng_source
projects     -fstype=autofs     auto_eng_projects

A user in the blackhole project within engineering can use the following path:

/org/eng/projects/blackhole

Starting with the AutoFS mount at /org, the evaluation of this path dynamically creates additional AutoFS mounts at /org/eng and /org/eng/projects. No action is required for the changes to take effect on the user's system because the AutoFS mounts are created only when required. You need to run the automount command only when you make changes to the master map or to a direct map.