Key and variable substitutions

There are two forms of substitutions that are performed in automounter maps: variable substitution and key substitution. Variables are useful for hiding architecture or operating system dependencies when maintaining a uniform naming scheme, while key substitutions impress a degree of regularity on the automounter maps.

Key substitutions

The ampersand (&) expands to the matched key value in a map; it is used in the server:directory path pair to copy key values into directory path component names. Let's say you have a map that lists all the exported directories on your network that exist for the purpose storing users' home directories. Let's call this map auto_home_exports. Initially, this map looks like: 

thud -rw thud:/export/home/thud wahoo -rw wahoo:/export/home/wahoo mahimahi -rw mahimahi:/export/home/mahimahi


We can rewrite it using key substitution: 

thud -rw &:/export/home/& wahoo -rw &:/export/home/& mahimahi -rw &:/export/home/&


With the right-hand side rewritten, the map's regular form can be further condensed using the asterisk (*) wildcard: 

* -rw &:/export/home/&


The asterisk is a default case. Nothing after it will ever be matched, so it should be the last (or only) entry in the map. It matches all keys, providing a value for the & substitutions that fill in the right-hand side of the map information. For example, assume that the clients are using the auto_home_exports map for the /home_exports mount point. Every reference through /home_exports matches the wildcard map entry. When a lookup of /home_exports/thud/jan is performed, the automounter gets an RPC request to look up thud in the /home_exports directory. Referring to the indirect map, the automounter finds the wildcard, which matches the key thud. The automounter makes thud the default key, and expands the server:directory component as: 

thud:/export/home/thud


This entry is equivalent to a thud-specific entry: 

thud -rw thud:/export/home/thud


Special case mappings may be added ahead of the wildcard map entry: 

mahimahi2 -rw mahimahi:/export/home/mahimahi2 * -rw &:/export/home/&


Of course, wildcards can get you into trouble as well. Assume that you are using the following simple indirect map for auto_home_exports: 

* -rw &:/export/home/&


and a user tries to access /home_exports/foo. The automounter then tries to mount foo:/export/home/foo, but it's probable that no host named foo exists. In this case, the user will get a somewhat puzzling "No such host" error message when the automounter cannot find the server's name in the NIS hosts map. The concise wildcard-based naming scheme is useful for machines exporting a single home directory, but when multiple home directories are exported from several disks on a server, the one-to-one mapping of home directory names to server names breaks down. If naming conventions permit, you can create hostname aliases in the NIS hosts map that match the additional home directory names, allowing the wildcard map to be used. To see how this works, let's simplify the following auto_home_exports map for the three servers mahimahi, thud, and wahoo: 

mahimahi -rw mahimahi:/export/home/mahimahi mahimahi2 -rw mahimahi:/export/home/mahimahi2 thud -rw thud:/export/home/thud thud2 -rw thud:/export/home/thud2 thud3 -rw thud:/export/home/thud3 wahoo -rw wahoo:/export/home/wahoo


Applying wildcard key matching substitution to the regularly named directories shortens the auto_home_exports map so that only the secondary and tertiary home directories are listed: 

mahimahi2 -rw mahimahi:/export/home/mahimahi2 thud2 -rw thud:/export/home/thud2 thud3 -rw thud:/export/home/thud3 * -rw &:/export/home/&


Adding hostname aliases for mahimahi and thud to the hosts map condenses the auto_home_servers map even further: 

NIS hosts map  192.9.201.5 mahimahi mahimahi2 192.9.201.6 thud thud2 thud3 192.9.201.7 wahoo auto_home_servers map  * -rw &:/export/home/&


When a reference to /home_exports/thud2/jan is seen by the automounter, the wildcard map turns it into the server:directory pair: 

thud2:/export/home/thud2


Because thud2 is a hosts database alias for thud, the mount request is sent to the right server. This trick simply perpetuates the existing naming scheme but it does not help subsume all home directories under a single mount point. Users tend to like the C shell's tilde expansion mechanism, which locates a user's home directory from the NIS or local password files. Using a tilde reference such as ~jan causes the correct mount to be completed as long as the /etc/passwd file or passwd NIS map contains an entry like: 

jan:K8pLWWc.J4XIY:999:99:Jan Smith:/home_servers/thud2/jan:/bin/csh:


But there is no obvious, consistent absolute path to every user's home directory, because the paths contain a hostname-specific component. To make a completely uniform naming scheme, you need to build a fairly verbose map that hides the hostname dependencies in the home directory paths. Given the set of home directories: 

/export/home/thud/stern /export/home/thud2/jan /export/home/mahimahi/johnc /export/home/wahoo/kenney


an indirect auto_home map that mounts all users' home directories under /home looks like this: 

stern -rw thud:/export/home/thud/stern jan -rw thud:/export/home/thud2/jan johnc -rw mahimahi:/export/home/mahimahi/johnc kenney -rw wahoo:/export/home/wahoo/kenney


Users can find any user through the /home switchboard, without having to know their home directory server. This scheme is useful where hard coded, absolute pathnames are required. You can juggle user's home directories to distribute free disk space without having to search for all occurrences of absolute pathnames; changing the automounter map effects the change. To make this switchboard available, the following would appear in the auto_master map: 

/home auto_home -nobrowse


The nobrowse option is there because there is one entry in auto_home for every home directory, and unless your organization is quite small, you'll find that users that do the following: 

% ls /home


generate lots of unnecessary network traffic.

Variable substitutions

If you are managing automounter maps through NIS, you may end up using the same map on machines running different releases of the operation system or having different CPU architectures. Directories with utilities or source code frequently need to be distinguished based on operating system release and machine architecture. Presenting these directories with a uniform naming scheme eliminates ugly pathnames, user confusion, and potentially dangerous actions, for example, a user building an object tree in the wrong subdirectory for that operating system release. The automounter allows variables to be substituted into the right-hand components of map entries. The following example shows how to mount /usr/local/bin from a set of architecture-specific directories: 

Automounter daemon invocation  /usr/lib/autofs/automountd -D MACHTYPE=`/usr/bin/uname -m' auto_direct map  /usr/local/bin -ro mahimahi:/local/bin.$MACHTYPE


Variable substitutions apply equally well to indirect maps. The following example shows how source code for a project is mapped out based on operating system release: 

/usr/lib/autofs/automountd -D OPSYS="SunOS5.6" notes -rw srcserv:/source/notes.$OPSYS news -rw srcserv:/source/news.$OPSYS chem -rw srcserv:/source/chem.$OPSYS


Variable and key substitution combine to collapse the map in the previous example to another one-liner: 

* -rw srcserv:/source/&.$OPSYS


A source code automounter map is useful when there are one or more levels of dependencies in the source tree, or when the source trees themselves live on several different servers. The automounter ensures that the developers mount only those servers containing source code that they are currently using.

Builtin variables

Some automounters have builtin variables. The builtin variables for Solaris are shown in Table 9-2.

Table 9-2. Solaris automounter variables

Variable Meaning
ARCH output of uname -m
CPU output of uname -p
HOST output of uname -n
OSNAME output of uname -s
OSREL output of uname -r
OSVERS output of uname -v
NATISA output of isainfo -n

If you can use builtin variables, then you should use them instead of specifying the value of variables with the -D option to automountd. The reason is that editing the script that starts the automountd process is going to be very tedious as your site grows. So in the previous section, we had the example: 

Automounter daemon invocation  /usr/lib/autofs/automountd -D MACHTYPE=`/usr/bin/uname -m'


Don't do that! Leave the automountd parameters alone, and instead have the map use the $ARCH builtin, instead of the custom $MACHTYPE variable: 

auto_direct map  /usr/local/bin -ro mahimahi:/local/bin.$ARCH