9.4. Key and variable substitutionsThere 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.
9.4.1. Key substitutionsThe 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:
We can rewrite it using key substitution:thud -rw thud:/export/home/thud wahoo -rw wahoo:/export/home/wahoo mahimahi -rw mahimahi:/export/home/mahimahi
With the right-hand side rewritten, the map's regular form can be further condensed using the asterisk (*) wildcard:thud -rw &:/export/home/& wahoo -rw &:/export/home/& mahimahi -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:* -rw &:/export/home/&
This entry is equivalent to a thud-specific entry:thud:/export/home/thud
Special case mappings may be added ahead of the wildcard map entry:thud -rw thud:/export/home/thud
Of course, wildcards can get you into trouble as well. Assume that you are using the following simple indirect map for auto_home_exports:mahimahi2 -rw mahimahi:/export/home/mahimahi2 * -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:* -rw &:/export/home/&
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: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
Adding hostname aliases for mahimahi and thud to the hosts map condenses the auto_home_servers map even further:mahimahi2 -rw mahimahi:/export/home/mahimahi2 thud2 -rw thud:/export/home/thud2 thud3 -rw thud:/export/home/thud3 * -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:NIS hosts map 18.104.22.168 mahimahi mahimahi2 22.214.171.124 thud thud2 thud3 126.96.36.199 wahoo auto_home_servers map * -rw &:/export/home/&
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:thud2:/export/home/thud2
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:jan:K8pLWWc.J4XIY:999:99:Jan Smith:/home_servers/thud2/jan:/bin/csh:
an indirect auto_home map that mounts all users' home directories under /home looks like this:/export/home/thud/stern /export/home/thud2/jan /export/home/mahimahi/johnc /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: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
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:/home auto_home -nobrowse
generate lots of unnecessary network traffic.% ls /home
9.4.2. Variable substitutionsIf 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:
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: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 and key substitution combine to collapse the map in the previous example to another one-liner:/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
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.* -rw srcserv:/source/&.$OPSYS
188.8.131.52. Builtin variablesSome automounters have builtin variables. The builtin variables for Solaris are shown in Table 9-2.
Table 9-2. Solaris automounter variables
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:
Don't do that! Leave the automountd parameters alone, and instead have the map use the $ARCH builtin, instead of the custom $MACHTYPE variable:Automounter daemon invocation /usr/lib/autofs/automountd -D MACHTYPE=`/usr/bin/uname -m'
auto_direct map /usr/local/bin -ro mahimahi:/local/bin.$ARCH
Copyright © 2002 O'Reilly & Associates. All rights reserved.