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
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 bsdi.com.
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 conference@usenix.org.
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 cpsr.org, as the papers from the previous two conferences
already are. The ftp archives at cpsr.org 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 bjorn@sysadmin.com
(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
How can I make contact with other administrators? Are
SAGE and USENIX good options and how do I become involved?
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 bblisa-request@inset.com 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.
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?
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.
How should I structure my file systems?
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: bjorn@sysadmin.com /sys/admin,
inc. The Unix
System Management Experts (408) 241 3111 Send requests
to the SysAdmin
mailing list to sysadm-list-request@sysadmin.com
|