Questions and Answers
The SAGE small working group on Job Descriptions, headed
by Tina Darmohray,
has completed its work, and the result is a core template
of the skills required of administrators at organizations
sizes and types. The template divides the skills into
Novice System Administrator, Junior System Administrator,
System Administrator, and Senior System Administrator.
For each category,
the document lists required skills, required background,
background, and appropriate responsibilities. There
is also a checklist
for each category that includes local environment experience,
experience, programming skills, networking skills, security,
specialties, documentation, databases, hardware, and
The Job Description template is too large to print in
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
amount of work they put into this effort. I hope to
see it get a wide
distribution and usage.
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
for the organization, and to guide and encourage the
its volunteer workforce accordingly. In my view, SAGE
from a lack of such leadership. In particular, instead
and appreciation for the effort of the working group
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
ensure the election of a Board able to provide the vision
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
the professional society I think we all would like to
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
sendmail and sendmail configuration being what it is,
both qualified and capable of writing the book proved
to be a major
obstacle. O'Reilly persevered, however, and now Bryan
Allman, and Neil Ricket have produced a book that presents
description of both standard sendmail (V8) and the IDA
sendmail. The authors treat the many aspects of sendmail
detail, from the very basic (what is a delivery agent)
to the highly
complex (an explanation of the configuration file, including
and testing of each of the rule sets). The book is expected
published in time for LISA VII, so you should be able
to get it at
the conference; otherwise gang up on your local bookstore
The title of the book is just sendmail and it is from
Call for Papers for SANS III
The third international conference combining system
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
UNIX used for business applications.
The 1994 conference will cover management of heterogeneous
management of commercial UNIX, and programs for new
and network managers. For further information, contact
SANS III organizers
at 301-229-1062, or send email to email@example.com.
Correction to Last Issue's Column
In the September/October column, with a slip of my fingers
keyboard, I said that SMTP stood for Small Mail Transfer
This is incorrect: the "S" stands for "Simple,"
"Small." Unfortunately, this mistake managed
to go undetected
through the proofreading process.
We suspect that some of our systems would benefit from
additional memory. Is there anyway we can know for sure
$$ into this?
The "vmstat" command can provide you the
you need. If you execute the command
it will give you a report every five seconds on the
of memory usage in the system. In the report, the two
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
should typically be zero; if it isn't, the system is
paging, and possibly
swapping, and will gain greatly from more memory. The
interface looks neat, but it doesn't give you much useful
as it combines the "page out" with the "page
Of the two, the latter is normal, and occurs each time
you start a
new process; combining it with the "page out"
too much noise to make the perfmeter useful.
Other similar commands are netstat, which gives information
the network, and iostat, which gives information about
the disk activity.
All three commands are very useful in determining problems
bottlenecks. If you run them on a regular basis on your
systems, they will give you an idea of the systems'
patterns, which will be helpful when you have to diagnose
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
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
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.
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
(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
The drawback I mentioned is the fact that any print
on "donald" will actual be submitted twice
by the system,
and that all systems will have an entry in their printcap
"donald-lp2." The former represents such a
for most systems that it is not worth bothering about.
issue can be dealt with primarily by ensuring that all
that a printer with a name containing a dash ("-")
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
All in all, the advantage of having one single printcap
to all systems is that it is much simpler than maintaining
file on each individual host or distributing it in an
ad hoc fashion.
We are now required to run system accounting on our
Do you know of any public software package which can
If you are running System V or SunOS with the System
V option installed, you can run the System V accounting
This package may not do exactly what you need, but it
is a starting
point. Another alternative is to check the LISA V proceedings
1991, where John Simonson from the University of Rochester
Center presented a system accounting package they have
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
you probably will have to write your own, although the
Rochester may be a reasonable foundation. In general,
accounting for the purpose of charging for the service,
is best avoided,
if possible. While it may be useful within a large organization
charge projects or departments for system administration
it is very often simpler to use another metric for the
of the provided services. This is not to say that you
should not run
system accounting where available. The reports generated
System V's system resource accounting system provide
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
be able to set up tip to choose any free modem. Is there
any way to
The standard tip program can do this without any kind
of modification. You just need to write the tip modification
/etc/remote, accordingly. You can list all the available
a comma-separated list in the "dv" device
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
file in a relatively straightforward manner. I have
included a copy
from one of the systems here at /sys/admin (with system
of course) in Listing 2. The file lists the various
with the definition of the kind of modem required. Following
are the normal modem definitions, and then come the
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
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
can be added, for example, for the location of computers
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
a domain-oriented front end for "rdist," which
the tedious details).
We have started to convert a few machines to Polaris,
but have had major problems with the lp print spooler.
The lp line printer spooler used in Solaris (and all
other System V, release 4-based systems) is a holdover
System V, dating back to a time when postscript printers
common. The early printer spooler was designed to be
used in standalone
systems (or rather, for an environment, where the idea
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
we all have to deal with today. In addition, not all
will support the Berkeley line printer protocol, which
makes lp completely
incompatible with the BSD lpr system. In addition, Solaris,
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
the USENET archives at the University of Minnesota.
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.,
firm which specializes in large installation system
Bjorn is also co-founder and former president of Bay-LISA,
a San Francisco
Bay Area user's group for system administrators of large
can be contacted at /sys/admin, inc., 2787 Moorpark
Ave., San Jose,
CA 95128; electronically at firstname.lastname@example.org; or by
at (408) 241-3111.