[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System Management Guide: Communications and Networks

NIS and Automounting

Using automount Maps

The use of automount maps involves map formats, replicated file systems, comments in maps, directory patterns, multiple mounts, included maps, maps for the automount command, and the auto_master (or, when necessary for compatibility, auto.master) map file.

Map Entry Format

A simple map entry (mapping) follows:

key [-mount-options] location ...

where

key
Is the full path name of the directory to mount when used in a direct map. In an indirect map, key represents a simple name.
mount-options
Is a list separated by commas.
location
Specifies a file system from which the directory can be mounted. In the example case, location takes the form:
hostname:pathname 

where hostname is the server name where the file system will mount and pathname is the directory path to mount.

Replicated File Systems

Multiple location fields can be specified for replicated NFS file systems, in which case automount and the kernel will each try to use that information to increase availability. If the read-only flag is set in the map entry, automount mounts a list of locations that the kernel may use, sorted by several criteria. If a server does not respond, the kernel will switch to an alternative server. Sort ordering is used by automount to determine how the next server is chosen. If the read-only flag is not set, automount will mount the best single location, chosen by the same sort ordering, and new servers are chosen only when an unmount has been possible and a remount is done. Servers on the same local subnet are given the strongest preference, and servers on the local net are given the second strongest preference. Among servers equally far away, response times determine the order (if no weighting factors are used).

If the list includes server locations using both Versions 2 and 3 of the NFS protocol, automount chooses only a subset of the server locations on the list to ensure all entries are the same protocol level. It gives preference to Version 3 servers unless Version 2 servers on a local subnet would be ignored.

If each location in the list shares the same path name, a single location can be used with a list of host names, separated by commas.

hostname,hostname...:pathname 
able prime:/home/prime/able
baker prime:/home/prime/baker
Weighting Factor

Requests for a server can be weighted by appending the weighting factor (as an integer within parentheses) to the server name. A weighting factor of zero is the highest priority. Servers without a weighting factor are assumed to have a weighting factor of zero. Progressively higher values decrease a server's chance of being selected. In the following example,

man -ro austin,powers,mystery(1),person(4):/usr/man

hosts austin and powers have the highest priority; host person , the lowest.

Note: In the selection process, server proximity takes higher priority than weighting. In the previous example, if server person were on the same network as the user and the other servers were on different network segments, then person would be selected and the weighting value would be ignored.

When each server has a different export point, you can still apply weighting. For example:

man -ro austin:/usr/man powers,mystery(1):/usr/share/man person(3):/export/man

Mapping can be continued across input lines by escaping the newline character with a backslash (\). Comments begin with a pound sign (#) and end at the subsequent newline character.

Map Key Substitution

The ampersand (&) character is expanded to the value of the key field for the entry in which it occurs. In the following example,

baby
      austin:/groovy/&

the ampersand expands to baby .

Wildcard Key

When used in the key field, the asterisk (*) is recognized as a catch-all entry. The asterisk will match any key not previously matched. For instance, if the following entry appears in the indirect map for /powers:

*
      &:/austin/powers/&

the entry would allow automatic mounts in /powers of any remote file system whose location was specified as

hostname:/austin/powers/hostname

Multiple Mounts

A multiple mount entry takes the form:

key [-mount-options] [ [/mountpoint] [-mount-options] location ...  ] ... 

The initial /[mountpoint] is optional for the first mount and mandatory for all subsequent mounts. The optional mountpoint is taken as a pathname relative to the directory named by key. If mountpoint is omitted in the first occurrence, a mountpoint of / (root) is implied. Given an entry in the indirect map for /src:

beta -ro\

    /          svr1,svr2:/export/src/beta \
    /1.0       svr1,svr2:/export/src/beta/1.0 \
    /1.0/man   svr1,svr2:/export/src/beta/1.0/man

All offsets must exist on the server under beta.automount, which will automatically mount /src/beta, /src/beta/1.0, and /src/beta/1.0/man, as needed, from either svr1 or svr2 (whichever is nearer and responds more quickly).

Other File System Types

The automounter assumes NFS mounts as a default file system type. Other file system types can be described using the fstype mount option. Other mount options specific to this file system type can be combined with the fstype option. The location field must contain information specific to the file system type. If the location field begins with a slash (/), a colon (:) must be prepended. For instance, to mount a CD file system:

cdrom -fstype=cdrfs,ro      :/dev/cd0

or to perform an autofs mount:

src   -fstype=autofs      auto_src

Indirect Maps

An indirect map allows you to specify mappings for the subdirectories you wish to mount under the directory indicated on the command line. In an indirect map, each key consists of a simple name that refers to one or more file systems that are to be mounted as needed.

Direct Maps

Entries in a direct map are associated directly with autofs mount points. Each key is the full pathname of an autofs mount point. The direct map, as a whole, is not associated with any single directory.

Special Maps

There are two special maps available: -hosts and null. The -hosts map is used with the /net directory and assumes that the map key is the host name of an NFS server. The automountd daemon dynamically constructs a map entry from the server's list of exported file systems. For instance, a reference to /net/shag/usr would initiate an automatic mount of all exported file systems from shag that are mountable by the client. References to a directory under /net/shag would refer to the corresponding directory relative to the shag root.

The -null map, when indicated on the command line, cancels a previous map for the directory indicated. This is most useful in the /etc/auto_master map for canceling entries that would otherwise be inherited from the +auto_master include entry. To be effective, the -null entries must be inserted before the included map entry.

Executable Maps

Note: Local maps that have the executable bit set in their file permissions will be executed by the automounter and provided with a key to be looked up as an argument.

The executable map is expected to return the content of an automounter map entry in its stdout or return no output if the entry cannot be determined.

Configuration and the Master (auto_master or auto.master) Map

When initiated without arguments, automount consults the master map for a list of autofs mount points and their maps. It mounts any autofs mounts that are not already mounted and unmounts autofs mounts that have been removed from the master map or direct map. The automount command may be initiated to establish mounts by specifying the map information on the command line. This information can be lost if the automount command is invoked a second time. For the sake of administration and debugging, the automount command will write a reference map file that reflects the map information specified on the command line. The file is generated on each invocation of the command and is called /etc/autofs_cmdline.

Note: The master map can be called auto_master or and auto.master. If auto_master isn't found, NIS looks for auto.master.

Included Maps

The contents of another map can be included within another map by entering:

+mapname

The mapname can be a file name or the name of a Network Information Service (NIS) map. Or, the mapname can be one of the special maps described in the following section. If the key being searched for is not located in an included map, the search continues with the next entry.

Managing NIS automount Maps

Prerequisites

NIS must be configured on your network.

Procedure

  1. Edit the /etc/auto.master file. The automount daemon, by default, reads the NIS /etc/auto.master map to find which directories to watch for mounts. The auto.master map has the following format:
    DirectoryPath     AutomountMapName

    The AutomountMapName field specifies a file containing the automount map for the directory specified by the DirectoryPath field. For example, the contents of the /etc/auto.master file on the NIS server might be as follows:

    /home/home     /etc/auto.home
    /usr/lpp       /etc/auto.direct

    The above auto.master file entries will direct the automount daemon to use the /etc/auto.home automount map for the /home/home directory and the /etc/auto.direct automount map for the /usr/lpp directory.

  2. Create the AutomountMapName files. The AutomountMapName files have the following format:
    Subdirectory   MountOptions   ServerName:ServerDirectory

    The Subdirectory field specifies a subdirectory of the DirectoryPath field directory of the auto.master file. For example, the contents of the /etc/auto.home file on the NIS client might be as follows:

    john            -rw,hard,intr    host1:/home/john
    bill            -rw,hard,intr    host3:/home/bill
    sally           -rw,hard,intr    host5:/home/sally
    fred            -rw,hard,intr    host9:/home/fred
    jane            -rw,hard,intr    host1:/home/jane

    The contents of the /etc/auto.direct file on the NIS client might be as follows:

    X11             -ro,hard,intr    lppserver:/usr/lpp/X11
    bsmEn_US        -ro,hard,intr    lppserver:/usr/lpp/bsmEn_US
    gnuemacs        -ro,hard,intr    lppserver:/usr/lpp/gnuemacs
    info            -ro,hard,intr    lppserver:/usr/lpp/info
  3. Update the /var/yp/Makefile file. The following must be added to the Makefile file:
    1. Add auto.master to the all: listing.
    2. Add an entry for $(DIR)/auto.master: at the appropriate point in the file.
    3. Add the following stanza to the Makefile file:
      auto.master.time: $(DIR)/auto.master
              -@if [ -f $(DIR)/auto.master ] ; then \
                      $(MAKEDBM) $(DIR)/auto.master $(YPDBDIR)/$(DOM)/auto.master; \
                      touch auto.master.time ; \
                      echo "updated auto.master" ; \
                      if [ ! $(NOPUSH) ] ; then \
                               $(YPPUSH) auto.master ; \
                               echo "pushed auto.master" ; \
                      else \
                               : ; \
                      fi \
              else \
                      echo "couldn't find $(DIR)/auto.master" ; \
              fi
    4. Add an entry for auto.master: auto.master.time at the appropriate point in the Makefile file.

    In general, the same format that is used for the netmasks entry in the Makefile file can be used for the auto.master entry.

  4. Build the auto.master map by executing the following command:
    make auto.master

    If errors are generated, check for improper configuration of NIS, errors in the Makefile file, or errors in the syntax of the /etc/auto.master file.

  5. Start the automount daemon by executing the following command:
    /usr/sbin/automount

    This starts the automount daemon, which reads the auto.master NIS map.

    In the preceding examples, when these procedures are completed, a user on the client can issue the cd /home/home/bill command and have the /home/bill directory mounted from the host3 system onto the /home/home/bill directory.

Maintaining All of the automount Maps with NIS

In the first example, the /etc/auto.home and /etc/auto.direct were local files on the client that contained all of the automount map needed. The contents of the automount maps can also be maintained by NIS. The files would still exist on the client, but the contents would be different. For example, the /etc/auto.home file would contain the following:

+auto.home

And the /etc/auto.direct file would contain the following:

+auto.direct

This directs the automount daemon to consult the NIS maps auto.home and auto.direct when it reads the local files. The NIS server would contain two new NIS maps. The maps would be auto.home and auto.direct . They would be added to the /var/yp/Makefile in the same way that the auto.master NIS map was added. This makes them available for use by the NIS clients running the automount daemon.

This facility can also be used to define local portions of the automount maps and then refer to the NIS maps for the rest of the automount map. For example, the /etc/auto.home file could contain the following:

sandy          -rw,hard,intr             host10:/home/sandy
james          -rw,hard,intr             host2:/home/james
bill           -rw,hard,intr             host20:/home/bill
+auto.home

This automount map has three local entries and then it contains the NIS map auto.home . This way, local definitions can be maintained while taking advantage of the NIS map for the /home/home directory. The entry bill in the local map would appear in the auto.home NIS map. The local map entry will override the NIS map entry.


[ Previous | Next | Contents | Glossary | Home | Search ]