• Choose a category
• All
• Classic-Fiction

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