Cover V02, I03


Questions and Answers

Bjorn Satdeva

Old Business

In the January/February issue (vol. 2, no.1), I mentioned that I do not know of any management books specifically for system administrators. I've received replies from several readers pointing out both traditional management books and various types of self-help books and growth programs. I agree that traditional management books -- such as, for example, Peter Drucker's classic Management (New York: Harper & Row) can be of great help. However, most such books address upper management problems; they do not deal with the kind of managing system administrators need to do. Self-help books and groups and personal development groups and seminars can be of great value, but the selection of these is so personal that I can't make a general statement about them.

Joint Venture: Silicon Valley

A new group, Joint Venture:Silicon Valley, has been formed to give a much-needed boost to the high-tech industry located in the area. The board of directors includes representatives from both industry and local government. The group, which is made up of many subgroups, each with a specific charter, will focus on such issues as providing high-speed networking and increased quality of health providers.

Will this work? I am convinced that what this group is setting out to do is badly needed, but, for now, I will follow the development closely, hope for the best, but not expect too much. When sitting through the various presentations, I was reminded all too much of my three years of active involvement in the IEEE POSIX 1003.7 System Administration Group. My experience there gave me firsthand knowledge of how difficult it is to get anything done by committee (as the old saying goes, a camel is a horse designed by committee).

UNIX Power Tools

O'Reilly & Associates have published a new book of special interest to system administrators. The book, UNIX Power Tools, is not aimed specifically at system administrators, but it contains many nifty details on how to use specific tools. What makes the book particularly interesting is that it comes with a CD-ROM containing all programs and configuration file samples. The programs are provided both in source code form, and compiled for several popular platforms.


UniForum is one of the largest of the UNIX-related trade shows (on the West Coast it is rivaled in size only by InterOp). This time, however, size was about the only thing the show had going for it -- in fact, it seems that as the show has grown, the technical quality has diminished. This year, many of the exhibitors presented theatrical shows with very limited technical content. The most elaborate booth included a complete theater with a revolving stage. The result is that I can remember the stupid plot of the small play, but cannot remember anything about the exhibitor's technical product. While this approach may work for people in upper management, who are not concerned with actual technical detail, it was extremely frustrating for me (and others who, like me, need technical information). In fact, in several of the booths, I was unable to find anyone with a technical background!

Remembering UniForum when it was only a trade show, and when the organization behind it was still called /usr/group, I see the current version as a commercial success without any real content. An oddity, and perhaps a sign of where UniForum is going: while the show this year was bigger than ever, it appeared less crowded than it has been in recent years.

The bottom-line question is, Is it still worth attending? The answer is yes, if you are looking for a specific tool or piece of hardware. The difficulty will be in extracting technical fact from the marketing hype that more and more seems to characterize new product presentations.

Request for Injunction against BSDI Dismissed

On March 3, 1993, in the United States District Court for the District of New Jersey, District Judge Dickinson R. Debevoise denied UNIX System Laboratories' request for a preliminary injunction to stop the distribution of BSD/386 from Berkeley Software Design, Inc. BSDI is therefore free to continue to distribute BSD/386, without restriction. This is an important ruling, as BSD/386 is the first commercial release to be based on the Networking Release 2 software developed at the University of California at Berkeley. BSD/386 is of particular interest to individuals and small companies who are looking for a supported version of UNIX with full source code. BSDI charges as little as $995 for the Net 2 release, while I believe USL now charges more than $100,000 for the sources to System 5 release 4.

USL had sought to stop the distribution of BSD/386, alleging that both the University and BSDI had infringed copyrights and trade secrets in the 32V UNIX operating system.

In his ruling, Judge Debevoise based the denial on a finding that USL would be unlikely to succeed in showing that it had a valid copyright in 32V and that USL had not been able show that Networking Release 2, on which BSD/386 is based, contained any trade secrets belonging to USL.

In his summary of the ruling, Judge Debevoise said:

In summary, I find that I am unable to ascertain whether any aspect of Net2 or BSD/386, be it an individual line of code or the overall system organization, deserves protection as Plaintiff's trade secret. Since Plaintiff has failed to provide enough evidence to establish a "reasonable probability" that Net2 or BSD/386 contain trade secrets, I find that Plaintiff has failed to demonstrate a likelihood of success on the merits of its claim for misappropriation of trade secrets. No preliminary injunction will issue.

The ruling, along with other documents related to this case, can be retrieved by anonymous ftp from They are located in the directory bsdi-info/usl.

USL has not commented, and many people fear that they will continue the suit. In my opinion, USL's best course would be to drop the suit and concentrate on shipping a product comparable in quality to Net 2. It seems to me that someone at USL should recognize that they are attempting to kill the goose that lays the golden egg, since the success and popularity of UNIX must be attributed in large part to the work done at CRG.

USENIX in Cincinnati

USENIX will hold its summer conference this year in Cincinnati, June 21 to 25. I do not yet know in detail what the conference will offer to system administrators, but I can do a sneak preview of the some of the relevant tutorials that will be offered.

Dan Geer and Jon Rochlis, who were both deeply involved in the design and implementation of Kerberos, will present "The Kerberos Approach to Network Security." Rob Kolstad will teach a new tutorial, "UNIX Power Tools." A charismatic and well-known person in the UNIX system administration community, Rob has for many years been involved with system administration related tutorials. The power tools tutorial is rumored to include such items as: Backups, COPS, KERBEROS, Ethics, and Non-root Administrators. Bill LeFebvre will teach his half-day tutorial on "Managing the Domain Name System." Bill is well-known to system administrators through his sun-managers mailing list. Trent Hein and Evi Nemeth will present "Topics in System Adminstration." Trent was the 1992 LISA program chair, and Evi is, of course, very well-known as a co-author (with Garth Snyder and Scott Seebass) of the System Administration Handbook. And if you want to know more about sendmail, you will be able learn it from Mr. Sendmail himself, as Eric Allman will teach the tutorial on "Sendmail Inside & Out." If you are interested in security, plan to attend the tutorial by Rob Kolstad and Tina Darmohray on "Internet Security Firewalls." Tina is widely recognized for her InterOp tutorials, and has become a sought-after resource on firewalls here in the Bay area.

The official announcement should be available from USENIX by the time this issue of Sys Admin hits the streets. You can get more information about USENIX conferences, workshops, and tutorials from the USENIX Conference Office, 22672 Lambert Street, Suite 613, El Toro, CA 92630. Telephone is (714) 588-8649; FAX is (714) 588-9706; and e-mail is

Third Conference on Computer Professionals for Social Responsibility

The Third Conference on Computers, Freedom and Privacy took place 9-12 March 1993 at the San Francisco Airport Marriott Hotel. The conference papers and sessions will be available by anonymous ftp access from, as the papers from the previous two conferences already are. The ftp archives at also contain many other items on related topics.

Deadline for LISA VII Paper Proposals

July 2nd, the paper proposal deadline for LISA VII, the USENIX System Administration Conference, is approaching fast. LISA VII takes place November 1-5, in Monterey, just south of Silicon Valley, on the Northern California coast. If you need the Call for Papers, or have any questions about this conference, contact me by sending e-mail to (or call me at my office at 408-241-3111). To submit a proposal, you must e-mail it to me prior to the due data. If you are at a site where e-mail is not available, contact me for an alternate submission method.

This Month's Questions

 Q How can I make contact with other administrators? Are SAGE and USENIX good options and how do I become involved?

 A The best way to establish good contacts with other system administrators is through a local User Group. To my knowledge, however, there are only two such groups actually in existence, although some are in the process of formation. The two currently in place are Bay-LISA, in the San Francisco Bay Area, and Back Bay Lisa, in Boston. (Back Bay Lisa exists only as an electronic mailing list. Send email to Back Bay Lisa at to be added to their mailing list.) If you are interested in starting a local group in your area, your main challenge will be to find other people who are willing to spend the time and effort required to make this happen. Because I have seen how great a resource Bay-LISA has become in our area, I am willing to function as the point of contact to help other local groups form. If you are interested, e-mail your name, address, e-mail address, and the identification letters of the nearest international airport to me. I will use the airport ID as key, so that I can be sure to connect the right people, without being a specialist in the geography of your area.

As for non-local possibilities, the LISA conferences are probably your best chance. At these conferences, system administrators from all over the world get together to talk shop. Be aware that your best opportunities may come outside the formal conference program, at the birds-of-a-feather sessions and, most important, in the bar at night. Don't consider the latter a joke -- the conference offers an important opportunity for system administrators to get together socially. If during the following year, you can even once get help from one of the people you have met, the cost of the conference will have been worthwhile.

In addition to the LISA conference, there are also the main USENIX summer and winter conferences and the SANS conference on the East Coast. The InterOp tutorials can also serve well in this connection.

SAGE is still new, and will have to prove its worth. It now has about 600 members -- one test of its effectiveness will be how many of the 600 renew the membership. SAGE is listed as a sponsor of the LISA and SANS conferences, but it is too early to see any real influence. SAGE has a number of mailing lists, but they are mostly inactive. So far, the organization's greatest success is the SAGE pages in the USENIX newsletter ;login:, where members contribute various articles.

 Q I need to broaden my information base. Where do I go to find as much information as possible on software and hardware packages applicable to my needs?

 A There are several resources available. First, there is SysAdmin magazine, but since you already are reading it, I won't discuss this further.

The foremost resource is USENET, especially the comp.unix.sysadmin newsgroup. However, the noise-to-information relationship here is extremely poor, and seems to get worse all the time. Having a good newsreader, such as, for example, nn, helps a good deal, but cannot completely avoid the problem.

Another source of information is the trade press. However, many of the trade magazines are unwilling to print criticism of products advertised in their pages. As a result, editorial content sometimes is nothing more than a reprint of a press release. Still, reading the advertisements in the trade press is a good way of keeping informed about potentially useful products.

Books on UNIX-related topics are another source of information, and such books are being published with increasing frequency. Unfortunately, it can be difficult to select a good one. Some books are very, very good, while others never should have made it to publication. A very good starting point is Evi Nemeth's System Administration Handbook, mentioned earlier, and several of the O'Reilly NutShell books.

You might also consider using publicly available software. This software is free, but not free of cost with respect to time, as you (or your staff) will have to provide the support. Some of this software is of very high quality; some is almost impossible to use. However, it is often faster to start with such a software piece rather than write the whole project from scratch. Some public domain software is published through the source newsgroups in USENET, but most packages are available only by anonymous ftp. Finding the right package can be a problem; you'll find that using Archie can be a great help.

Yet another alternative is to use a consultant to help you locate what you need. This can be expensive, but can also save you much time and frustration, which can make it cost-effective in the end.

 Q How should I structure my file systems?

 A It's often recommended that file systems be kept large and few to avoid wasting disk space. This argument seems a bit shortsighted to me. Structuring disks into file systems is a tool the system administrator should use to achieve desirable ends.

To illustrate my point, assume your system had only one very large file system. It would give you optimal utilization of the disk space, according to the above argument, but would cause all kind of other problems. For example, if you received a high level of USENET news traffic, it would fill up the disk, and the users would no longer be able to get any work done. While I do not think anybody would recommend going this far, I use the example to show that there are other considerations. On a workstation, you can probably get by with only three or four file systems locally. On the servers, you can use the file systems to enforce disk limits, but if you make the limits too tight, you will find yourself constantly restructuring the file systems -- not a very good option except on AIX, where you can resize file systems on the fly.

Since user needs and requirements differ greatly from site to site, it isn't possible to suggest guidelines. I can, however, offer some suggestions on how to structure the system disks. I like to have separate file systems for root, /tmp, /usr, and /var, where present. Depending on usage of the system, I might add separate filesystems for the spool area ( typically /var/spool or /usr/spool), for the users' system mailboxes (typically /usr/mail, /var/mail, or /usr/spool/mail), and, on uucp systems, for the uucp (/usr/spool/uucp or /var/spool/uucp) and maybe uucppublic directories. If the system supports USENET news, this would require its own large file system. The users' home directories and project directories should be added according to local requirements.

My reasoning is as follows. No system should swap to the root file system -- therefore the separate /tmp file system. If the root is damaged so badly that it cannot boot, fixing it may require either a complete reinstallation or a painful recovery, depending on the type of system. Ideally, the root file system should be mounted "read only," but in reality, this is not yet practical (although recent changes are moving UNIX in that direction). Placing the tmp directory in a separate file system significantly reduces the number of write accesses required to the root file system. On systems where the tmp file system is on disk, I like to place tmp just after the swap partition on the disk (over the years I've had too many system write over the end of the swap partition). On a modern system, tmp will be on a memory file system and will not generate any disk access (which does wonders for the speed of the system). The reason for separating the /tmp file system from root also holds true for the /var file system.

The configuration for the rest of the file systems is intended to minimize the problems that can occur if one or more applications get out of hand and fill up a file system. Thus, the spool file system should be big enough to allow a large print job to be spooled. If the printer is local, you will need to allocate space for several large print jobs. If you use uucp, it is best to have a separate file system just for this application. This way, if you suddenly get a burst of e-mail and news (e.g., from a site that has been down for a while) and your uucp directory fills up, it will stall delivery, but will not harm any other part of the system. Similarly, a large mail partition will ensure that no mail gets lost.

Such strategies require that you be able to move and configure file systems, and this is a skill that should be in every system administrator's toolbox. If not, you will find yourself one morning at 3:00 A.M. working on restoring a lost disk -- and believe me, this is not the time to learn about newfs (or whatever you local equivalent is called).

About the Author

Bjorn Satdeva -- email: /sys/admin, inc. The Unix System Management Experts (408) 241 3111 Send requests to the SysAdmin mailing list to