Cover V02, I03


New Messages

This column is designed to serve as an open forum where our readers can exchange information, experiences, and opinions. Within 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 upon your willingness to share your expertise and experience. You can reach us at --rlw

Dear Editor:
The article "UNIX Security in a Networked Environment" by Ms. Laurie Sefton provided an excellent summary of UNIX security issues. Ms. Sefton correctly noted that network security problems and solutions are arrayed along a continuum from mundane to the critical.

We would point out an important omission in the article. The article discussed public domain software that addressed certain security issues. Many sys admins in the commercial environment would prefer to use software that is developed by a company with technical support and long-term commitment to customer satisfaction. Los Altos Technologies co-developed a program called Fortress (TM) that checks for viruses, worms, Trojan horses and unsecure passwords in UNIX. Los Altos Technologies has also developed UniShred Pro (TM), a government approved security data remnant remover and TermServ (TM), a modem pool management and security dialback program. Information on this and other UNIX security products can be obtained by contacting Los Altos Technologies at 1-800-999-UNIX or any large UNIX reseller such as the Qualix Group, Inc..

Gary Kremen
Executive Vice President
Los Altos Technologies, Inc.
346 Costello Court
Los Altos, CA 94024-4707

Thank you for writing, and for the additional information. --rlw

To: SysAdmin <>
Subject: foobar

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 "snafu" -- "situation normal, all fouled up"). I think the terms "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," and "foobar" were first used in UNIX? Can we get to the "root" of this?

Chris Harting
Systems Engineer
Symix Computer Systems
2800 Corporate Exchange Drive
Columbus, OH 43231

World War II started a lot of technical and sarcastic acronyms. I have never been able to trace fubar earlier than WWII, although 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 Phrase Origins, by William & Mary Morris, makes only a passing reference to fubar and snafu. My favorite dictionary, The American Heritage Dictionary, really let me down. It doesn't even list fubar (in any form), but it does give an unabashed explanation of snafu's roots.

As for the first use in UNIX, I can't claim any knowledge. Anyone care to nominate a document as candidate for "first usage"? --rlw

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 schedule.

That's an important point, unfortunately it's not necessary for all 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 time.

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 is minimized. I also keep fairly up-to-date copies of the output from commands like dkinfo, dmesg and df offline to aid in recovery.

It's not enough to just know how to recover, a little effort ahead of time can drastically minimize the effort spent after the disaster.

Dean Cookson
The MITRE Corp.
Burlington Rd.
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 is simply one part of the "little effort ahead of time" that reduces the pain. Practice, unlike planning, is just a little less cerebral.

I'd certainly like to have an article that gives detailed information about how to configure for, and accomplish, recoveries in a distributed environment. Perhaps you'd like to write something? --rlw

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 articles on the Usenet. Also, I am trying to find some info on UNIX virus scanners. 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 via uucp and ftp. I don't think the articles will be available for downloading -- how would we pay our bills?! How about the virus scanners? Does anyone out there have some leads? --rlw

Hi, Robert
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 II printer 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 "protocol 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 as follows:

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,
David Yang

This sounds like a flow control problem. An "stty -a" report would be more informative than the printcap entry. The main 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 cabled? (Both pin 2 and pin 3 must connect appropriately to pin 2 and pin 3 at the host.)

It wouldn't hurt to put a breakout box on each side of the 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? --rlw

Dear Robert:
I have received a number of questions from people asking about programs 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

Chris Hare

Thanks for sharing the pointer. I'm certain many will appreciate the information. --rlw