Managing NFS and NIS, 2nd Edition - Mike Eisler [127]
/auto auto_auto
/home auto_home -nobrowse
/net -hosts -nobrowse
/- auto_direct
Executable indirect maps
The autofs automounter contains another feature known as executable maps. If permissions on an indirect map file are marked as executable, then the autofs automounter assumes it is an executable program or shell script, and executes it, passing the key as the first and only argument to the program or script. The program or script must then display an indirect map entry, which can be hierarchal. For example, suppose /etc/auto_master has:
# Directory Map Mount Options
/auto auto_auto
/home auto_home -nobrowse
/net -hosts -nobrowse
/net2 /etc/auto_exec
/- auto_direct
Examine /etc/auto_exec:
% ls -l /etc/auto_exec
-rwxr-xr-x 1 root sys 76 Oct 26 09:58 /etc/auto_exec
% cat /etc/auto_exec
#!/bin/sh
/usr/sbin/showmount -e $1 | \
awk 'NR > 1 {print $1 "'$1':"$1 " \\"}' | sort
This script takes the key value as if it is a hostname, and asks the NFS server, via the showmount command, which filesystems are exported. The output of showmount is then formatted by the awk command to produce a hierarchical map entry. You can test the script manually by doing:
% /etc/auto_exec foo
/export1 foo:/export1 \
/export2 foo:/export2 \
Thus, the script implements functionality similar to /net, with one difference. Note that the -nobrowse mount option isn't included in the /net2 entry of auto_master. This is because executable maps can't be browsed. There doesn't seem to be any reason why the enhanced autofs automounter couldn't have been implemented to support it, perhaps by having a browse= option that referred to yet another program or script to do the browsing.
If, for some reason, the executable program or script cannot resolve the key to a map entry, then it should display zero bytes of output to standard output. Any output displayed to standard error will be logged by the automounter onto the system console.
* * *
Tip
Make sure that if you have an automounter map file with the executable permission bit set that you actually want it to be executed.
* * *
* * *
[2] If a directory pathname has a length of x characters, then any of its subdirectory's pathnames have length > x. Sorting by pathname length puts a parent directory ahead of all paths to its subdirectories.
Side effects
The automounter has several side effects that cause confusion in both processes and users that encounter its emulated directories. This section uncovers some utilities that are disturbed by the automounter.
Long search paths
If you have many directories listed in your search path, logging into a system using the automounter for some of these directories increases your login time significantly. Instead of listing the directories in your search path, create "wrappers" for the utilities of interest and put them in /usr/local/bin. The wrappers can set environment variables and execute the appropriate utility, causing the automounter to mount the necessary filesystem when you use it instead of when you log in.
For example, you can include Frame 6.0 in your search path in your .cshrc file:
set path = ( /tools/deskset/frame6.0/bin $path )
If /tools is managed by the automounter, your shell causes /tools/deskset to be mounted when it builds the command hash table after setting your search path. Instead of listing all directories in /tools, create a wrapper in /usr/local/bin for the maker utility in /tools/deskset/frame6.0/bin so that you don't have to list any subdirectory of /tools in your search path:
Wrapper for maker
#!/bin/sh
PATH=/tools/deskset/frame6.0/bin:$PATH
exec /tools/deskset/frame6.0/bin/maker
This wrapper sets the search path as well, so that any executables invoked by maker will be able to find related utilities in its executable directory. By putting this wrapper in /usr/local/bin, you avoid having to automount /tools/frame6.0 when you log in. For just a few directories, the automounter overhead isn't that large, but with ten or more software packages loaded, logging