Sidebar: I Can't Run NIS and NIS+!

Although the NFS automounter was designed to work in an NIS environment, it does not require NIS. In the ridiculous extreme, if you can't run NIS, you could edit automounter maps from scratch on each NFS client. Before you do that, take a look at some of the alternative ways to push automounter maps and other administrative information around. The trick is to get the automounter maps, user information (/etc/passwd), and group information (/etc/group) out to the client machines. Since you probably want your users to be able to change their password on any machine, your NIS replacement should include a way to get user information flowing in both directions.

So in traditional UNIX style, if you can't use NIS, you could build your own network information system. To start with, ask a few important questions. What do you need to distribute? How often do changes need to be distributed? How fast must they be distributed? If speed and scalability are not deciding factors, the simplest way to push automounter maps may be to use rdist. rdist (remote distribution) is a program to maintain identical copies of files over multiple hosts. It ships with almost all UNIX operating systems, and it is simple to use. To make use of rdist, you could create a set of automounter maps on a central trusted host. When you wanted to propagate a changed map, you would edit the central copy and invoke rdist to push the changes out. (Your changes, however, won't take effect until the next time the machine is rebooted.) There is a version of rdist that has been completely rewritten by Michael Cooper (see ftp://usc.edu/pub/rdist.) It includes several extensions to the classic rdist, and does not need to run from a trusted host as root. For more on rdist, see Judith Ashworth's "rdist to the Rescue," Sys Admin 1.4, Nov/Dec 1992.)

While you're connected to the ftp server at UCS, pick up your replacement for the password portion of NIS. Michael Cooper has also written a drop-in replacement for the NIS password system; "System for Password Management (SPM)," pronounced "spam" (ftp://usc.edu/pub/spm). His system includes a demon for centralized password management, and a set of client programs for changing passwords. For some shops, a combination of rdist and SPM may be a good fit, if all you need to do is push automounter maps and manage user passwords. NIS can be a great asset, but it can be overkill if your needs are modest.

A work-alike to rdist is Carnegie Mellon's SUP (Software Upgrade Protocol). SUP has traditionally been used to keep software developers synchronized, but is an excellent candidate for synchronizing automounter maps. Take a look at

ftp://ftp.cs.cmu.edu/project/mach/sup.

For the Cadillac of password and user information systems, you might try Hesiod and kerberos. Hesiod is a generic distributed information system based on the Domain Name Service (DNS). It was created as part of project ATHENA at MIT. It can be used for all kinds of data, including user names and passwords. Kerberos is a "network authentication system." Kerberos is too big a product to discuss here. To find out more about it take a look at

ftp://athena-dist.mit.edu/pub/kerberos

Kerberos is also available commercially. If you have not seen kerberos since version 4, you might want to take another look at version 5.