.
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 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.
9.4.2. 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.
9.4.2.1. 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
