Managing NFS and NIS, 2nd Edition - Mike Eisler [126]
Let's say a user now accesses /usr/local/bin/emacs. The client kernel follows /usr/local down to the symbolic link, which points to the /stage/local automounter mount point. The automounter picks up the reference to /stage as a reference to the auto_stage map, and it uses the next component — local — as a key in the map. This causes mahimahi:/local/$ARCH to be automounted. If you have several direct mount points, they can all be converted into links sharing a single auto_stage map.
Multiple indirection
So far the only map we've seen that refers to other maps is the auto_master map. Let's collect all of the indirect maps we've added to auto_master in this chapter:
# Directory Map Mount Options
/home auto_home -nobrowse
/net -hosts -nobrowse
/tools auto_tools -ro
/source auto_source -rw
/stage auto_stage -ro
One problem with this approach is that the top-level root ( / ) directory is beginning to get cluttered. Of course, one could simply add another component to the mount directory. If we want to put everything under /auto, then we could change indirect map entries of the master map to:
# Directory Map Mount Options
/auto/home auto_home -nobrowse
/auto/net -hosts -nobrowse
/auto/tools auto_tools -ro
/auto/source auto_source -rw
/auto/stage auto_stage -ro
If you are using the autofs automounter, then there is a more elegant approach: simply treat each indirect map as a map entry in new indirect map called auto_auto. To do this, the master map would look like:
# Directory Map Mount Options
/auto auto_auto
/- auto_direct
The auto_auto map is an indirect map. Like all other indirect maps, its first field has to be a directory relative to /auto, its second field has to be a set of mount options, and its third field has to be the name of the thing we are mounting. Here is what auto_auto looks like:
# Directory Options Map being mounted
home -fstype=autofs,nobrowse auto_home
net -fstype=autofs,nobrowse -hosts
tools -fstype=autofs,ro auto_tools
source -fstype=autofs,rw auto_source
stage -fstype=autofs,ro auto_stage
The second and third fields in auto_auto are basically swapped from what they would be in auto_master. The difference is the presence of the fstype option. This option is needed to unambiguously tell the autofs automounter that this is not map entry referring to an NFS-mounted filesystem.
There is no limit on multiple indirection. This fact allows you to create sensible hierarchies that can be extended ad infinitum. Let's return to the auto_source example, which contains:
sunos5.6 -ro srcserv:/source/sunos5.6
sunos5.7 -ro srcserv:/source/sunos5.7
nfs -ro bigguy:/source/nfs_internals
You've decided to add Linux, BSD, FreeBSD, and System V sources to this map, and you have multiple versions of each. Rather than having a map of contain entries called sunos5.6, sunos5.7, linux1.0, linux2.0, bsd4.3, bsd4.4, sysVr3, sysVr4, etc., you decide that you want a hierarchy that branches first on the name of the operating system and then on the release. So you change auto_source to:
bsd -fstype=autofs auto_bsd
linux -fstype=autofs auto_linux
nfs -ro bigguy:/source/nfs_internals
sunos -fstype=atofs auto_sunos
sysv -fstype=atofs auto_sysv
The auto_bsd map might contain:
4.1c -ro ancient:/export/source/bsd4.1c
4.2 -ro ancient:/export/source/bsd4.2
4.3 -ro ancient:/export/source/bsd4.3
4.4 -ro srcsrv:/source/bsd4.4
This should be enough to get the idea; for brevity, we won't expand on what the other maps might look like.
Note that the auto_source map example contains both entries with fstype=autofs, and an nfs entry referring to bigguy:/source/nfs_internals.
By the way, you probably will want to leave the -hosts and auto_home maps at /net and /home. The reason is that lots of software assumes these mount points exist. So you would want auto_master to look like:
#