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


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


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.