Questions and Answers

Bjorn Satdeva

Before we go to the questions in this issue, let's look briefly at a number of upcoming events of interest to system administrators. The most important of these is the USENIX LISA VI conference, which will take place in Long Beach, CA, October 19th through 23rd, 1992. If your budget will allow you only one conference trip for this year, this is the one.

The chair of the LISA VI conference is Trent Hein (trent@xor.com) from XOR Computer Systems. Steve Simmons (scs@iti.org) is handling the alternate tracks, and Arch Mott (arch@pei.wpd.sgi.com) is coordinating the BOFs. There will also be a vendor display. For information about this, contact John Donnelly (johnd@alumni.cs.colorado.edu).

In previous years LISA has targeted large installations. This year, however, the scope of the conference is being extended to include system administrators from all UNIX sites. To get more information, please contact Trent Hein or the USENIX Conference office at (714) 588-8649. You can also reach the USENIX Conference Coordinator, Judith DesHarnais, by e-mail at judy@usenix.org.

This year, for the first time, there will be two system administration conferences. The other conference (actually the first, chronologically), is the 1992 World Conference on System Administration and Security, scheduled for July 20 - 23, in Washington, DC. Since this is a new conference, I have very little information about it; however, my impression is that it is targeted toward government installations. For more information, contact the conference chair, Alan Paller (paller@fedunix.org).

A third conference is the USENIX UNIX Security Symposium, which will take place in Baltimore, September 14 - 16. The chair is Edward DeHart from CERT (Computer Emergency Response Team), who can be reached at (412) 268-6179 or by e-mail at ecd@cert.sei.cmu.edu. Information can also be obtained from the USENIX Conference Office mentioned earlier.

Finally, there will be a LISA VII conference next year, to be chaired by yours truly. Ideas and requests for this conference can be e-mailed to bjorn@sysadmin.com

And now to something completely different...

Until recently we have been using Suns exclusively. Now, however, other machines have been introduced. This is a problem, as we rely heavily on NIS. Do you know of any public implementation of NIS?

To my knowledge, no such thing exists. Moreover, my experience with NIS's from vendors other than Sun Microsystems suggests that they do not work as well as could be desired. I recommend that, with the exception of the password file, you use rdist to distribute the files now serviced through NIS. Depending on how you have set up your site, this could generate less network traffic than NIS, and it will eliminate some of the less desirable side effects of NIS.

rdist is a program that distributes files to remote systems. It differs from other file distribution programs, such as rcp, primarily in that it is driven by a control file and that it updates the remote file only if the file is out of date. When you use rdist to distribute system configuration files, local copies of the file are kept on each system. This eliminates network traffic for lookups and provides you with an easy way of ensuring that the dreaded plus sign is not in hosts.equiv. Of course, if you change the system configuration files frequently, the network traffic required for updating these files could rise above the level required to run NIS. In my experience, however, that this has rarely been the case. You will need to decide how often you want to perform the file distribution; for my purposes an hourly distribution has worked well for files of this type.

Unlike NIS, rdist can be used to distribute any type of file, including program files. rdist also has a command option which allows directories to be kept as exact copies of the master. When this option is used, files deleted on the master will automatically be deleted on the rdist slaves. These two capabilities can be used, for example, to keep /usr/local identical across all machines.

As mentioned earlier, rdist cannot be used to distribute the password file, because this file, in a non-NIS environment, is updated on the local machine. If a password file were to be distributed by rdist, any password change a user had made would be lost. Over the years, several solutions to this problem have appeared. My favorite is ACMaint, by David Curry (davy@purdue.edu). A description of this package appears in the LISA IV proceedings. If you are unable to borrow the proceedings from a friend, or from your neighborhood library, you can purchase it from the USENIX conference office.

How do I make changes to the /etc/exports file take effect without rebooting?

As root, type

exportfs -a

I am looking for a good network-wide backup program. Any suggestions?

Over the years I have seen many such backup programs, their most common characteristic being that they do not work. The two basic requirements for a backup program are (1) that it work well all the time, and, especially, (2) that it perform appropriate actions when something goes wrong. Therefore, for anything much bigger than a home computer, if the standard UNIX dump (or cpio if your box is brain-damaged and does not have dump) will not do, I would recommend a commercial backup program.

There are currently three packages available which amount to more than just a replacement for an existing UNIX command or a front-end shell script to tar. These are the Legato Networker, BackupUNet for System Center, and Budtools from Delta Microsystems.

The Legato Networker uses its own proprietary archive format, which results in better performance, but creates problems for the system administrator. The improved performance will do you no good if you are unable to reclaim the data from the tape -- if, for example, the archive indexes have been damaged (a situation I have encountered with this product). In addition, the "touch and feel" of the graphical user interface is MacIntosh-like and, therefore, counterintuitive to me as an experienced UNIX system administrator.

The other two products, BackupNet and Budtools, have rather similar graphical user interfaces, but are very different in their underlying design and in their licensing structure. BackupUNet, like Legato Networker, uses a proprietary backup program, but the archive format written to the tape is that of a standard UNIX utility (tar), which allows for a fallback to a manual restore using that utility if the tape index is lost or damaged. Budtools uses the existing backup utilities (dump, tar, cpio) and can easily be extended to any other backup utility, such as GNUtar.

You must do your own evaluation of these three products in order to find the one that fits your requirements best. I strongly suggest that, as part of the evaluation, you run Elizabeth Zwicky's Backup Torture test. This test does awful things to your backup program and has found bugs in every backup utility it has been tested on so far (including my old friend dump). Be forewarned: do this only on a machine that can be allowed to crash on a regular basis, and only on a file system you do not mind subjecting to newfs afterwards. A paper describing this test and the findings for various backup utilities on a number of vendor platforms can be found in the LISA V conference proceedings from last year. The test program is available by anonymous ftp from ftp.erg.sri.com. Elizabeth can be reached by e-mail at zwicky@erg.sri.com.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.