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 saletter@rdpub.com. --rlw
Dear Editor: 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..
Respectfully, Thank you for writing, and for the additional information. --rlw
To: SysAdmin <saletter@rdpub.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 "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 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
To: rdpub.com!saletter 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 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
To: rdpub.com!saletter
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
lp|HPLaser jet II-ttyb:lp=/dev/ttyb:br#9600:\ :ms=-parity,cs8,-cstopb,-tabs,clocal,cread,-echo,ixon,-opost:\ :pw#80:lf=/var/spool/hp/error_log:sd=/var/spool/hp:\ :of=/usr/lib/hplaserjet:
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 -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:
Chris Hare Thanks for sharing the pointer. I'm certain many will appreciate the information. --rlw
|