9.3. Integration with NIS
If maps are maintained on each client machine,
then the administrative benefits
of using the automounter are lost; the burden of maintenance is
shifted away from the
vfstab file and onto the
new map files. To solve the administrative problem, all three types
of maps may be distributed using NIS.
To add an automounter map to the NIS database, insert
a set of clauses for it in the NIS master
server's
Makefile in /var/yp:
In definition of target all:
all: passwd hosts ..... auto.tools
auto.tools: auto.tools.time
auto.tools.time: $(DIR)/auto_tools
-@if [ -f $(DIR)/auto_tools ]; then \
sed -e "/^#/d" -e s/#.*$$// $(DIR)/auto_tools | \
$(MAKEDBM) - /var/yp/$(DOM)/auto.tools;\
touch auto.tools.time; \
echo "updated auto.tools"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) auto.tools; \
echo "pushed auto.tools"; \
fi \
else \
echo "couldn't find $(DIR)/auto_tools"; \
fi
The new map name must be added to the list of targets built by
default when
make is issued with no arguments. A
dependency linking the map name
auto.tools to
the timestamp file
auto.tools.time is added, and
the large section defines how to rebuild the map and the timestamp
file from the map source file. The
makefile
actions strip out all lines beginning with a comment
(
#) marker, and strip comments from the ends of
lines. The
makedbm program builds an NIS map
from the input file. The input file should not have blank lines in
it.
The key in an automounter map becomes the NIS map key, and the mount
options and server and directory names are the data values. Dumping a
map with
ypcat requires the
-k option to match up map keys and server
information:
% ypcat auto.tools
-ro,intr thud:/epubs/deskset
jetstar:/usr/Bugview
-ro,intr mahimahi:/tools2/deskset1.0
% ypcat -k auto.tools
sundesk -ro,intr thud:/epubs/deskset
bugview jetstar:/usr/Bugview
deskset -ro,intr mahimahi:/tools2/deskset1.0
NIS-managed maps are specified by map name rather than by absolute
pathname:
Master map
/tools auto_tools -ro
/source auto_source -rw
9.3.1. Mixing NIS and files in the same map
As with the password NIS map, it is sometimes necessary to have
variations in the configuration on a per-machine basis. Using the
notation
+mapname, it is possible to include an
NIS map in a local automounter map. For example, as mentioned
earlier in this chapter,
/etc/auto_master file can have an entry in it
like:
+auto_master
This is useful if you want more control over the order with which map
information from the
/etc/auto_master file
versus the name service gets processed. The appearance of this entry
causes map information from the NIS
auto.master
map to read in as if it were where the
+auto_master entry was. For example, let's
say
nsswtch.conf has an
automount: entry that specifies
files to be processed before
nis. The
auto.master map in
NIS might contain:
/docs auto_temporary -ro
The
/etc/auto_master file might contain:
/tools auto_tools -ro
+auto_master
/docs auto_docs
/src auto_source
/- auto_direct
The effect is that the accesses to
/docs/XXX are
satisfied from the
auto_temporary map and not
from the
auto_docs map.
The use of entries with leading plus signs
is not limited to
auto_master entries. Any of the maps that
auto_master refers to can contain
+mapname entries if they are local files.
Suppose, for example, that client machines on your network share a
common set of source trees, but some clients are allowed to access
operating system source code as well. On those machines without
source code rights, the
/etc/auto_source map
contains a single reference to the NIS map:
+auto_source
However, on clients that have more privileges, the operating system
source code mount points can be included
with the NIS map:
sunos5.7 -ro srcserv:/source/sunos5.7
sunos5.8 -ro srcserv:/source/sunos5.8
nfs -ro bigguy:/source/nfs_internals
+auto_source
9.3.2. Updating NIS-managed automount maps
The automounter reads indirect NIS maps for each
mount request it must handle. A change
in one of these maps is reflected as soon as the map is built and
pushed to the NIS servers. New tools get installed in
/tools by inserting a new map entry in
auto_tools rather than editing the
/etc/vfstab files on each client machine. The
automounter sees map updates the next time it has to perform a mount.
The only way to change the mount parameters for a currently mounted
filesystem is to unmount the filesystem manually. Some automounters
will also require that you send the automounter daemon a SIGHUP (kill
-1). When the automounter receives this signal, it parses the
mnttab file and notices that some of its mounted
filesystems were unmounted by someone else. It invalidates the links
for those mount points; the next reference through the same entry
remounts the filesystem with the new parameters.
Direct maps are subject to an
update
restriction. While the maps may be updated with the automounter
running, changes are not made visible through the automounter until
it is restarted. Under Solaris, re-running the
automount command suffices. The automounter
creates a mount table entry for each direct mount point, so they
cannot be added or removed without the automounter's
intervention. If a direct mount point is removed from a direct map
maintained by NIS, attempts to reference the mount point return
"file not found" errors: the mount point is still listed
in the
mnttab file but the automounter's
direct map no longer has a corresponding entry for it.
Using NIS to manage the automounter maps makes administration of a
large number of NFS clients much simpler: all of the work that
formerly went into
/etc/vfstab file maintenance
is eliminated. In a large environment with hundreds of users, the
task of map management can become quite complex as well. If new users
are added to the system, or filesystems are shuffled to meet
performance goals, then the automounter maps must be modified to
reflect the new configurations. The benefits of using the automounter
are significantly increased when the maps are simplified using key
and
variable
substitutions.
 |  |  |
| 9.2. Invocation and the master map |  | 9.4. Key and variable substitutions |
