Managing NFS and NIS, 2nd Edition - Mike Eisler [111]
mahimahi:/tools2/desket - /tools/deskset nfs - - ro
mahimahi:/tools2/string - /tools/sting nfs - -
thud:/tools3/news - /tools/news nfs - -
jetstar:/usr/bugview - /tools/bugview nfs - -
Notice that the server-side mount points have no common pathname prefixes, but that the client's vfstab and automounter map establish a regularly named view of filesystems.
There are basically two kinds of automounters: older ones that use symbolic links and newer ones that don't. Using the auto_tools map, older implementations of the automounter emulate tools in a directory of symbolic links. When any process on the client makes a reference to something in /tools, the automounter completes the appropriate NFS mount and makes a symbolic link in /tools pointing to the actual mount point for the filesystem. Suppose you go to execute /tools/news/bin/rn. Using the automounter effectively breaks this pathname up into three components:
The prefix /tools picks an automounter map. (We will see in the section Section 9.2.1 just how /tools refers to the auto_tools map.) In this case, the map for the /tools directory is the auto_tools map.
The next pathname component is the key within this map. news selects the server filesystem thud:/tools3/news ; the automounter mounts this filesystem and makes a link to it in /tools on the client.
The remainder of the path, bin/rn, is passed to the NFS server thud since it is relative to the directory from which the news toolset is mounted.
Keep in mind that this list applies to older automounters that use symbolic link map entries to NFS mount points. There are problems with using symbolic links, and newer automounters solve them. The newer automounters don't use symbolic links and effectively put the NFS mounts "in place." The next section will explain in more detail.
Note that the automounter map doesn't contain any information about the /tools directory itself, only about the subdirectories in it that are used for mount points. This makes it extremely easy to relocate a set of mount points — you simply change the master map that associates the directory /tools with the map auto_tools. We'll come back to the master map later on.
Inside the automounter
At this point, it's useful to take a look under the hood of the automounter. This background makes the operation of indirect maps a little clearer and will make direct maps much easier to understand.
As mentioned before, automounter implementations come in two designs. The first one is a purely user-level approach that relies heavily on symbolic links. The second is a hybrid user-level and kernel-level approach called the autofs automounter, which eschews symbolic links.
User-level automounters
The original automounters were strictly user-level daemons that required no support in the kernel. SunOS 4.x automounters were all user-level, as were the automounters in Solaris 2.0 through Solaris 2.3. As many automounters were derived from SunOS 4.x or Solaris code, you'll find that several non-Solaris implementations are still user-level.
Before walking through the sequence of automounter operations in detail, some knowledge of mount information is necessary. The mount( ) system call takes the filesystem type (ufs, nfs, hsfs, etc.) and mount point from the /etc/vfstab table, and a packet of parameters that are type-specific. For NFS mounts, the argument vector passed to mount( ) includes the server's hostname and a socket address (IP host address and port number pair) to be used for sending requests to that server. For normal NFS mounts, the remote server's hostname and IP address are used, and the IP port number is the well-known NFS port number 2049. The kernel uses this information to put together an RPC client handle for calling the remote NFS server.
User-level automounters capitalize on this architecture by creating a set of mount arguments that points to itself, a process on the local host, with a different