Integrating Automounter into NIS across Two Subnets
Mark Baker In large sites where many systems share common data, the automounter provides a convenient mechanism. Automounter ensures that only required filesystems are mounted. Many books and articles have been written on this subject, but little documentation seems to exist on setting up automounter for multiported hosts. The following article assists those people who, like me, have a system connected to multiple Ethernet segments and wish to nominate which NFS traffic will use which segment. SunOS 4.1.4 is the base for the text and examples. Some differences between SunOS and other UNIX flavors may well exist. Automounter is common to many UNIX systems, providing ad hoc NFS filesystem mounting. Ad hoc mounting is particularly useful in an environment where distributed data is infrequently accessed. However, increased network traffic, especially from diskless clients, can reduce file I/O efficiency. Typically, this can be solved by using bridges and routers or by setting up subnetting. Instead, I decided to use spare Ethernet ports on SCSI cards to create a second network between those systems that require data access. This method delivers a system that effectively has two or more network connections with relatively little capital outlay. All you'll need is a fan-out box and a few cables. Configuring Configuration is simple. Just specify a second Class C network on the hosts. For example, System 1 has a hostname of vindaloo (193.0.9.50) on the le0 port and bulldog (193.0.8.50) on the le1 port. /etc/hostname.le0 contains vindaloo and /etc/hostname.le1 contains bulldog (curries and dogs are used here to enable simple differentiation). Having configured the hosts we have two networks:
Simply running the ifconfig command as specified in the boot script brings up the interface, provided that the respective hostnames are defined in your NIS hosts map and/or your etc/hosts file, and that you have correctly connected up your fan-out box and cables. Use ifconfig -a to check that your two networks are up and running. Referencing a particular filesystem as belonging to a host on the le1 network ensures that the filesystem will be mounted across the desired network. For example, the filesystem /export/home on vindaloo could be mounted on madras as follows:
mount bulldog:/export/home /export/home
Any NFS traffic for /export/home between vindaloo and madras will now use the le1 network. Accessing All this is simple enough, but it creates problems for the automounter. Unfortunately, automounter relies on determining the hostname of a system when mounting filesystems. When automounter receives a request to mount a locally owned filesystem, it creates a symbolic link. Consider the auto.master and auto.vindaloo indirect maps shown in Figure 1. Accessing /vindaloo/Archive on vindaloo makes the automounter create a link in /vindaloo to point to /bulldog/Archive. But accessing /vindaloo/contracts on vindaloo makes the automounter mount its own exported /bulldog/contracts onto /vindaloo/contracts -- clearly a waste of NFS bandwidth. The key to solving this is to remove from the local map any reference to a system's own filesystems, creating the necessary links manually. Remove the entry for contracts in the auto.vindaloo map. Any system with multiple Ethernet ports that needs to make selective use of these networks should not reference any of its own filesystems by their le1 hostnames in any of their maps. This moves away from having all maps incorporated into NIS, but the benefits and ease of administration make it worthwhile. Consider the maps in Figure 2. In this figure, auto.madras is an NIS map (more about this later). Whenever /madras/scsi* is referenced, the system mounts the desired filesystem across the le1 network. On the madras system, auto.madras is removed from the local auto.master map. Again, creating a link of /madras that points to the exported /alsatian directory ensures that the local host can see the filesystems as the others do. Mapping In the example system's final configuration, vindaloo has its own auto.master.local and makes no reference to auto.vindaloo; madras has its own auto.master.local and makes no reference to auto.madras; and so on for all other systems. This means that each system that exports filesystems and mounts others must have its own auto.master map. Having created the maps, the next step is to incorporate into NIS those maps that specify exported data filesystems. Remember that a host will have no reference to its own file systems in its auto.master.local file and will therefore not reference its own map. To use a local master map, start the automounter as follows;
automount -v -m -f /etc/auto.master.local
The -v option ensures that automount posts errors and info to the console. The -m option prevents automount from creating NIS directory map pairs. Build the NIS entry for this map on the NIS master, then edit the makefile found in /var/yp. Modify the make group all to include your new map: for example,
all: passwd group hosts ethers networks rpc services protocols \ netgroup bootparams aliases publickey netid netmasks c2secure \ timezone auto.master auto.vindaloo
Note that auto.master in the dependency list provides a global automount map for those systems that mount filesystems but do not export any of their own. Next, add a specific make entry for this map lower down in the makefile, as shown in Figure 3. Having done this, create the NIS master map:
cd /var/yp; make NOPUSH=1 auto.vindaloo
The NOPUSH=1 prevents make from calling yppush to propagate the map. As the next step to building these maps into NIS, ensure that each NIS slave has a copy of the map. Execute ypxfr on each slave as follows:
/usr/etc/yp/ypxfr -h NISmasterName mapname
where NISmasterName is the name of your sole NIS master and mapname is your automount map, such as auto.vindaloo. After running make and ypxfr successfully, test NIS by touching your /etc/auto.master or auto.vindaloo map and then running make from /var/yp. If all is okay, your map should propagate to all NIS slaves. Try using ypcat on an NIS client to check the map's visibility. Centralizing the NIS Auto Master Files At a site where only a few systems export or mount each other's filesystems, the need to go out to each system has little impact. However, in a larger site the burden of logging in to each server or host is onerous. Keep a copy of each host's auto.master.local file on a central system, using an appropriate naming convention, such as auto.`hostname`.master.local. Automounter has an option for specifying the master file to be used. Changing this option on each host ensures that future updates to the automount master maps could be handled centrally if you could distribute these maps from a central server. Integrating these into NIS does not seem possible, as automount only allows an alternate file, not an alternate NIS map, to be specified instead of the default NIS auto.master map. I suggest solving this by using rdist, which allows files to be centrally administered and distributed across systems. A simple Distfile to do this could look as follows:
HOSTS = ( madras vindaloo korma )
FILES = ( /etc/auto.madras.master.local
/etc/auto.vindaloo.master.local
/etc/auto.korma.master.local )
#
${FILES} -> ${HOSTS}
install;
One drawback to rdist is that all hosts would have a copy of all other hosts' auto.master files. rdist could be modified to overcome this, but for the sake of this article, I will leave that for individual attention.
About the Author
Mark Baker has been using UNIX systems for the past 10 years. During the last five years he administered Sun systems and IBM workstations as the Computer Operations Manager for a seismic data processing company in England. Mark's latest project integrates an IBM SP2 parallel system into a Sun-hosted NIS domain. Send e-mail to him at markb@ensign.co.uk.
|