This column is designed to serve as an open forum where
our readers can exchange information, experiences, and
the limits imposed by the economics of printing, good
taste, and legal
liability, this forum is open to all readers. Please
write. We appreciate
your feedback (both laudatory and critical), and depend
willingness to share your expertise and experience.
You can reach
us at firstname.lastname@example.org. --rlw
The article "UNIX Security in a Networked Environment"
Ms. Laurie Sefton provided an excellent summary of UNIX
Ms. Sefton correctly noted that network security problems
are arrayed along a continuum from mundane to the critical.
We would point out an important omission in the article.
discussed public domain software that addressed certain
Many sys admins in the commercial environment would
prefer to use
software that is developed by a company with technical
long-term commitment to customer satisfaction. Los Altos
co-developed a program called Fortress (TM) that checks
worms, Trojan horses and unsecure passwords in UNIX.
Los Altos Technologies
has also developed UniShred Pro (TM), a government approved
data remnant remover and TermServ (TM), a modem pool
security dialback program. Information on this and other
products can be obtained by contacting Los Altos Technologies
or any large UNIX reseller such as the Qualix Group,
Executive Vice President
Los Altos Technologies, Inc.
346 Costello Court
Los Altos, CA 94024-4707
Thank you for writing, and for the additional information.
To: SysAdmin <email@example.com>
In response to your response to Gary Perratt's letter
in Vol. 1, Issue
4: The term "foobar," I believe, is a variant
on the military
acronym "fubar," which, in very mild terms,
stands for "fouled
up beyond all recognition," (a close relative of
-- "situation normal, all fouled up"). I think
"foo" and "bar" were originally
used in UNIX as common,
nondescript names for temporary variables, usually seen
in C code
examples. Does anybody know where "foo," "bar,"
"foobar" were first used in UNIX? Can we get
to the "root"
Symix Computer Systems
2800 Corporate Exchange Drive
Columbus, OH 43231
World War II started a lot of technical and sarcastic
I have never been able to trace fubar earlier than WWII,
I haven't spent much time searching. Larry Reznick tells
me he has
seen some dictionaries list fubar with unabridged, unabashed
definitions. However, Morris Dictionary of Word and
by William & Mary Morris, makes only a passing reference
and snafu. My favorite dictionary, The American Heritage
Dictionary, really let me down. It doesn't even list
(in any form), but it does give an unabashed explanation
As for the first use in UNIX, I can't claim any knowledge.
Anyone care to nominate a document as candidate for
Subject: Disaster Recovery
In this month's "Publisher's Forum" you write:
>Third, it's not enough to "know" how to
recover from a serious
failure. You must practice the procedure. ...
>From now on we practice major recoveries on a regular
That's an important point, unfortunately it's not necessary
of us. I admin enough different machines in different
labs that disaster
recovery is a fairly common occurrence. As a result
I find that I
take a "defensive posture" from system setup
Most of my labs are diskful Suns with 2+ machines big
enough to handle
at least some server duties. I establish at least 1
slave yp server,
keep 2 copies of common directories (i.e., /usr/local)
on two different
machines, and spread the user accounts over 2 or more
of the machines.
This way, if a disk goes south, at most half of the
users will be
dead and the time to bring common system tools back
I also keep fairly up-to-date copies of the output from
dkinfo, dmesg and df offline to aid in recovery.
It's not enough to just know how to recover, a little
of time can drastically minimize the effort spent after
The MITRE Corp.
Bedford, Ma. 01730
You're right, of course. Admins who manage a large number
of machines probably don't need to make a special effort
to keep their
recover skills honed. We do. It occurs to me that practice
one part of the "little effort ahead of time"
the pain. Practice, unlike planning, is just a little
I'd certainly like to have an article that gives detailed
information about how to configure for, and accomplish,
in a distributed environment. Perhaps you'd like to
Subject: UNIX VIRI
Say, I just wanted to drop a line to say how much I
enjoy your magazines.
I am wondering if you might put the index, or even some
the Usenet. Also, I am trying to find some info on UNIX
Do you have any leads? Keep up the good work. We here
in the trenches
appreciate . . .
Dennis J. Kavanaugh
Thanks for writing. The code listings are available
uucp and ftp. I don't think the articles will be available
-- how would we pay our bills?! How about the virus
anyone out there have some leads? --rlw
I'm one of your many happy subscribers. Fortunately,
I had a chance
to talk to you at UniForum in SF. At the time, I asked
if I can post
a question to you for help and you agreed. Thanks for
your help in
advance. Here it is: I'm trying to set up a HP Laserjet
on my Sparc 2's ttyb port. The printer has 2 meg of
RAM and configuration
seemed to be correct (according to the user's menu).
The printer works
fine if there is only one page to print but displays
error" if there is more than 1 page. The serial
cable that I used
is 50 feet long. The printcap file on my Sparc 2 is
lp|HPLaser jet II-ttyb:lp=/dev/ttyb:br#9600:\
Would you be able to help me on this? I'd like to set
it up so people
on the network can share the printer also. Thanks again,
This sounds like a flow control problem. An "stty
report would be more informative than the printcap entry.
question is: have you enabled xon/xoff flow control?
At both the printer
and the host? Have you disabled hardware flow control
(RTS, CTS, DTR,
DSR, CD)? If so, is the reverse signal channel properly
pin 2 and pin 3 must connect appropriately to pin 2
and pin 3 at the
It wouldn't hurt to put a breakout box on each side
cable and watch the signals during a print job. Pins
2 and 3 (and
7 for ground) are usually all you need for the data,
but to disable
hardware flow control you may need to short several
pins in the connectors
on each end of the comm link. Specifically, you should
short pin 4
to pin 5, and, separately, short pins 6, 8, and 20.
That's my best guess. Anyone else care to contribute?
I have received a number of questions from people asking
like u386mon for DEC RISC Ultrix machines. I only know
of one program,
which is also freely available, called monitor. This
monitor and other
tools are available via anonymous ftp from gatekeeper.dec.com
Thanks for sharing the pointer. I'm certain many will
the information. --rlw