Questions and Answers

Bjorn Satdeva

SAGE Jobs

The SAGE small working group on Job Descriptions, headed by Tina Darmohray, has completed its work, and the result is a core template description of the skills required of administrators at organizations of various sizes and types. The template divides the skills into four levels: Novice System Administrator, Junior System Administrator, Intermediate/Advanced System Administrator, and Senior System Administrator. For each category, the document lists required skills, required background, desirable background, and appropriate responsibilities. There is also a checklist for each category that includes local environment experience, heterogeneity experience, programming skills, networking skills, security, site specialties, documentation, databases, hardware, and management.

The Job Description template is too large to print in its entirety here, but an excerpt from the introduction is shown in the sidebar. The template will undoubtedly help organizations define the type of system administration staff they need at any given time. A very big thanks to Tina Darmohray and her working group for the very large amount of work they put into this effort. I hope to see it get a wide distribution and usage.

SAGE Elections

The election for the SAGE Board of Directors will be coming up this fall. SAGE's success in its first year has resulted more from the widespread recognition that such an organization is badly needed than from its actual accomplishments.

In a volunteer organization of this type, the proper role of the president and the Board of Directors is to provide a vision and a direction for the organization, and to guide and encourage the activities of its volunteer workforce accordingly. In my view, SAGE currently suffers from a lack of such leadership. In particular, instead of encouragement and appreciation for the effort of the working group chairs, there has been a tendency toward mistrust and in some cases a demand for increased control over their work. As a result, many of the working groups have virtually ceased to exist.

I think think it is critical that we, as members of the organization, ensure the election of a Board able to provide the vision and guidance necessary for continued growth and success. Therefore, if you are eligible to vote in the election this year, I encourage you to vote for people who have the ability to develop this organization into the professional society I think we all would like to see.

New Book on sendmail

The long-awaited O'Reilly book on sendmail is finally ready for printing. The book had been on Tim O'Reilly's wish list for many years, but sendmail and sendmail configuration being what it is, finding people both qualified and capable of writing the book proved to be a major obstacle. O'Reilly persevered, however, and now Bryan Costales, Eric Allman, and Neil Ricket have produced a book that presents an in-depth description of both standard sendmail (V8) and the IDA variant of sendmail. The authors treat the many aspects of sendmail in great detail, from the very basic (what is a delivery agent) to the highly complex (an explanation of the configuration file, including the purpose and testing of each of the rule sets). The book is expected to be published in time for LISA VII, so you should be able to get it at the conference; otherwise gang up on your local bookstore right now. The title of the book is just sendmail and it is from O'Reilly and Associates.

Call for Papers for SANS III

The third international conference combining system administration, network management, and security (SANS-III) will be held at the Stouffer Concourse Hotel in Arlington, Virginia, April 5 through 9, 1994. The SANS conferences focus on tutorials that are primarily geared towards UNIX used for business applications.

The 1994 conference will cover management of heterogeneous environments, management of commercial UNIX, and programs for new system administrators and network managers. For further information, contact SANS III organizers at 301-229-1062, or send email to sans@fedunix.org.

Correction to Last Issue's Column

In the September/October column, with a slip of my fingers on the keyboard, I said that SMTP stood for Small Mail Transfer Protocol. This is incorrect: the "S" stands for "Simple," not "Small." Unfortunately, this mistake managed to go undetected through the proofreading process.

Questions

We suspect that some of our systems would benefit from additional memory. Is there anyway we can know for sure before investing $$ into this?

The "vmstat" command can provide you the information you need. If you execute the command

vmstat 5

it will give you a report every five seconds on the status of memory usage in the system. In the report, the two columns you should pay attention to are "Memory," which shows how much memory is available, and, especially, "PO" (for Page Out), which shows how often the system is paging out. The latter column should typically be zero; if it isn't, the system is paging, and possibly swapping, and will gain greatly from more memory. The perfmeter graphical interface looks neat, but it doesn't give you much useful information, as it combines the "page out" with the "page in" operations. Of the two, the latter is normal, and occurs each time you start a new process; combining it with the "page out" data introduces too much noise to make the perfmeter useful.

Other similar commands are netstat, which gives information about the network, and iostat, which gives information about the disk activity. All three commands are very useful in determining problems and possible bottlenecks. If you run them on a regular basis on your important systems, they will give you an idea of the systems' normal behavior patterns, which will be helpful when you have to diagnose a problem somewhere in the network.

I have been told that I can create one single printcap file that can be used on all my systems, including both clients and printer servers. Is this true?

This is indeed true, but it does have a few minor drawbacks. The method is based on keeping the actual printer names "secret," and using only the network names. The "secret" name is of course not secret in any traditional sense, only in that it is never used by anybody other than lpd itself, when spooling a print job. When I use this method, I derive the "secret" name by combining the name of the host and the network name for the printer. For example, if the name of the printer is "lp2," and it is connected to a machine named "donald," then the secret entry in printcap will be "donald-lp2." I then let "lp2" point to the printer "donald-lp2" on the on remote host "donald" (see Listing 1). On most machines, this will work as usual. On the host "donald," it will cause the machine to connect over the network to itself, and then resubmit the printjob, this time for the printer "donald-lp2."

The drawback I mentioned is the fact that any print job originating on "donald" will actual be submitted twice by the system, and that all systems will have an entry in their printcap file named "donald-lp2." The former represents such a small overhead for most systems that it is not worth bothering about. The second issue can be dealt with primarily by ensuring that all users understand that a printer with a name containing a dash ("-") is for the system's internal use only and the status of such a printer may change at any time, without notice; and, secondarily, by making sure that only the real server host has the necessary spool directory. All in all, the advantage of having one single printcap file distributed to all systems is that it is much simpler than maintaining a printcap file on each individual host or distributing it in an ad hoc fashion.

We are now required to run system accounting on our systems. Do you know of any public software package which can do this?

If you are running System V or SunOS with the System V option installed, you can run the System V accounting programs. This package may not do exactly what you need, but it is a starting point. Another alternative is to check the LISA V proceedings from 1991, where John Simonson from the University of Rochester Computing Center presented a system accounting package they have developed to be used on BSD-based systems. The few commercial packages I have come across have been buggy and cumbersome to deal with.

For commercial-style system resource accounting, used for billing, you probably will have to write your own, although the system from Rochester may be a reasonable foundation. In general, system resource accounting for the purpose of charging for the service, is best avoided, if possible. While it may be useful within a large organization to charge projects or departments for system administration services, it is very often simpler to use another metric for the calculation of the provided services. This is not to say that you should not run system accounting where available. The reports generated nightly by System V's system resource accounting system provide useful insights into the how the system is being used, so the system should be enabled on all servers where it is available.

We have a modem pool at our site, and I would like to be able to set up tip to choose any free modem. Is there any way to do this?

The standard tip program can do this without any kind of modification. You just need to write the tip modification file, /etc/remote, accordingly. You can list all the available devices as a comma-separated list in the "dv" device specification, as for example:

:dv=/dev/tty00,/dev/tty01:

Unfortunately, the documentation for setting up "/etc/remote" could be clearer, and the samples shipped by vendors that I have seen are all equally awful. However, it is possible to write the configuration file in a relatively straightforward manner. I have included a copy from one of the systems here at /sys/admin (with system names changed, of course) in Listing 2. The file lists the various systems, each with the definition of the kind of modem required. Following the systems are the normal modem definitions, and then come the hardwired connections, used when talking directly to the modem. It is likely that if you try to copy this, the "telebit" dialer will be absent. If you drop me an e-mail messages, I will be happy to send you a copy of the one I wrote for this purpose (supports telebit T1000 and Q-blazer; has never been tested with other telebit modems).

On our office LAN I get the following message;

% ypmatch -k ftp services
Can't match key ftp in map services.byname. Reason: no such key in map.

% ypmatch -k 21/tcp services
21/tcp: ftp       21/tcp

Here it is obvious that "key" for services.byname is "21/tcp." Is this a correctly built services.byname database?

The message you're getting is normal. If you need an NIS map, which can give you just the service and not the port number, you can always add such a map on your own. Other similar databases can be added, for example, for the location of computers and printers, CPU types, or the phone book for the organization. I am not a fan of NIS, however; I much prefer to use simple text files for such information and distribute them with "rdist" (or rather "fdist," a domain-oriented front end for "rdist," which handles all the tedious details).

We have started to convert a few machines to Polaris, but have had major problems with the lp print spooler. Any suggestions?

The lp line printer spooler used in Solaris (and all other System V, release 4-based systems) is a holdover from early System V, dating back to a time when postscript printers were not common. The early printer spooler was designed to be used in standalone systems (or rather, for an environment, where the idea of networking was entirely based on UUCP).

It is a very powerful system, in terms of handling a variety of different printers, printer queues, and paper types. However, its method of configuration, using programs to maintain a myriad of files in a complex directory structure, is not at all suited to the networked environment we all have to deal with today. In addition, not all vendors' systems will support the Berkeley line printer protocol, which makes lp completely incompatible with the BSD lpr system. In addition, Solaris, and probably other versions of SVr4 as well, had several bugs; as a result, at one client site, we abandoned lp in favor of the BSD lpr. If you decide to do likewise, you can get the lpr sources from the BSD Net2 distribution, or use the publicly available plp (Volume 16, September 1988) from the USENET archives at the University of Minnesota. This alternative eliminates the problem of maintaining a large number of lp spoolers, allowing you to use just one (or a few) printcap files, but it requires that you maintain the software yourself.

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.