karl@kant.cis.ohio-state.edu (Karl Kleinpaste) (09/08/89)
Don't do that. OSU Computer Science was down for two days this week for major machine room hardware hacking. During the downtime period, an incredible $#!+load of news and mail piled up behind osu-cis. When we brought our machines up late yesterday afternoon after hacking completion, the load on ALL of our Pyramids (we have 4) soared solidly into the teens and higher. So osu-cis has been fighting like the dickens to catch up on it all, and he's not being especially successful up to this point (he's only a "little" Pyr 90x). The problem has been severely exacerbated by the fact that CompuServe announced the mail gateway, which also flows through osu-cis. And of course there's a blortful of people wanting to get archive stuff as well. And then someone out there had the unmatched _gall_ to request the whole of GNU Emacs source with uucico running -x9. For those of you not familiar, the -x option to uucico invokes debugging. It tells uucico to babble incessantly about what it's doing. Higher digits means more verbose levels of debugging. The max is -x9, which is a packet-level trace of uucico's activity. This usually means that more data gets dumped about what's being transferred than actually gets transferred down the port. Most importantly, invoking -x9 at YOUR end also puts MY end into -x9, dumping to /usr/spool/uucp/.Admin/audit. This evening, osu-cis simply stopped, with sendmails having blown out the swap area, and the relevant spool filesystem completely swamped because of an audit file well in excess of 18Mbytes. We are another 5 hours behind the flow of news and mail as a result. DON'T DO THAT. It's in extremely bad taste. If you must, use -x9 long enough to prove that a connection works, or to find a problem. Don't leave it on when you do large software transfers from a public archive site such as osu-cis. --Karl
perry@ccssrv.UUCP (Perry Hutchison) (09/09/89)
In article <KARL.89Sep7225153@kant.cis.ohio-state.edu> karl@kant.cis.ohio-state.edu (Karl Kleinpaste) writes: > And then someone out there had the unmatched _gall_ to request the > whole of GNU Emacs source with uucico running -x9. > > For those of you not familiar, the -x option to uucico invokes debugging ... > invoking -x9 at YOUR end also puts MY end into -x9 ... [it generated] > an audit file well in excess of 18Mbytes. > > DON'T DO THAT. ... If you must, use -x9 long enough to prove that a > connection works, or to find a problem. Don't leave it on when you do > large software transfers from a public archive site such as osu-cis. OUCH!! I trust it was unintentional, or at worst the consequences were unforseen. By way of preventing such incidents in the future, it sounds to me like uucico could be patched such that setting -x does _not_ automagically put the _remote_ end into -x mode.
karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) (09/09/89)
perry@ccssrv.uucp writes:
OUCH!! I trust it was unintentional, or at worst the consequences were
unforseen.
Probably so. "Never attribute to malice what can be adequately
explained by stupidity" and other trite thoughts apply.
uucico could be patched such that setting -x does _not_ automagically put
the _remote_ end into -x mode.
Probably. However, I am unimpressed with hacking UUCP source. Unless
I think of some better solution, I will leave it as I have currently
made it, with the relevant dirs/files chmod'd to prevent them being
opened for write. Other archive admins might wish to do the same.
--Karlshaw@paralogics.UUCP (Guy Shaw) (09/10/89)
In article <KARL.89Sep7225153@kant.cis.ohio-state.edu>, karl@kant.cis.ohio-state.edu (Karl Kleinpaste) writes: > And then someone out there had the unmatched _gall_ to request the > whole of GNU Emacs source with uucico running -x9. > > For those of you not familiar, the -x option to uucico invokes > debugging. It tells uucico to babble incessantly about what it's > doing. Higher digits means more verbose levels of debugging. The max > is -x9, which is a packet-level trace of uucico's activity. This > usually means that more data gets dumped about what's being > transferred than actually gets transferred down the port. Most > importantly, invoking -x9 at YOUR end also puts MY end into -x9, > dumping to /usr/spool/uucp/.Admin/audit. > DON'T DO THAT. It's in extremely bad taste. If you must, use -x9 I didn't do that, but I could have. The only reason I wouldn't have used -x9 is because *I* wouldn't want to see all that much prattle about something the size of GNU Emacs on *MY* system, not because I suspected that I could affect your system with my -x option. I sure didn't know that -x causes the remote system to do debugging, as well. I have sympathy for whoever did that, and I am not an overly sympathetic person. I poured over all the great documentation I have on UUCP, and I couldn't find anything about that. Of course, the documentation for UUCP was one the things that inspired the F in RTFM. I don't have an ".Admin" directory. I would guess you are using HDB UUCP. Sorry to be such a pleb; all I have is a Sun machine. I looked in the Nutshell manuals on UUCP, which supposedly cover HDB, as well as old UUCP, but they don't say anything about -x's effect on remote machines, nor do they mention .Admin. Is this behavior of UUCP new to HDB, or has been in OLD UUCP all along? If an old UUCP talks to your machine with -x, will your UUCP turn on debugging? I am glad you posted this article. I will add it to my much needed supplemental documentation on UUCP. > Summary: ...and I think I want to kill him. I think your hit list should be a bit more comprehensive. :-) In article <609@ccssrv.UUCP>, perry@ccssrv.UUCP (Perry Hutchison) writes: > By way of preventing such incidents in the future, it sounds to me like > uucico could be patched such that setting -x does _not_ automagically put > the _remote_ end into -x mode. I think this is your only hope. Posting an article telling people what the consequences are will help some. But I don't think you can overcome this problem with an education campaign. Besides, there is something not quite right about a system that behaves that way. Even if it were well documented, I think it is a mistake. If you ever have need for allowing remote control -x mode, demand that someone ask for it, with a separate option. I think the principle, "if you want it, you must ask for it", should apply to a feature like that. The book, "The Psychology of Everyday Things", by Donald A. Norman, comes to mind. (diverting all power to flame shields) -- Guy Shaw Paralogics paralogics!shaw@uunet.uu.net or uunet!paralogics!shaw
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/10/89)
> uucico could be patched such that setting -x does _not_ automagically put > the _remote_ end into -x mode. > >Probably. However, I am unimpressed with hacking UUCP source. Karl, if that's a Pyramid, then you are running 4.3BSD, which means you can cleanly disable auditing by rm'ing the /usr/spool/uucp/AUDIT directory. uucico actually checks to see if the directory exists, and if not it just ignores the debugging request. Auditing on other UUCP's is erratic. On most versions prior to 4.3BSD and HDB, it doesn't really work at all. <csg>
karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) (09/10/89)
csg@pyramid.pyramid.com writes:
Karl, if that's a Pyramid,
Rather a silly question, donchathink, Carl? It's osu-cis - of
_course_ it's a Pyramid...:-) (Well, OK, so it's Saqqara...but his
Secret Identity is still osu-cis.)
then you are running 4.3BSD,
Nope. I used TFM's advertised mechanism for going to a single version
of UUCP, and I run HDB exclusively. (That is, /usr/.ucblib/uucp ->
../.attlib/uucp.)
Auditing on other UUCP's is erratic. On most versions prior to
4.3BSD and HDB, it doesn't really work at all.
True enough. But it works just bloody _marvelously_ in HDB. I turned
off the audit file The Hard Way, and I won't be similarly bothered again.
--Karlallbery@NCoast.ORG (Brandon S. Allbery) (09/10/89)
As quoted from <248@paralogics.UUCP> by shaw@paralogics.UUCP (Guy Shaw): +--------------- | I don't have an ".Admin" directory. I would guess you are using HDB UUCP. | Sorry to be such a pleb; all I have is a Sun machine. +--------------- Yes, he's using HDB. When remote logging works on older versions (a rare occurrence...) it logs to /usr/spool/uucp/AUDIT, so you can't use the same trick to stop it. (ln -s /dev/null /usr/spool/uucp/AUDIT should work, though.) +--------------- | remote machines, nor do they mention .Admin. Is this behavior of UUCP | new to HDB, or has been in OLD UUCP all along? If an old UUCP talks to +--------------- It's been in old UUCP all along, but it usually doesn't work. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp, 161-7070 BALLBERY (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie) Is that enough addresses for you? no? then: allbery@uunet.UU.NET (c.s.misc)
al@escom.com (Al Donaldson) (09/11/89)
In article <248@paralogics.UUCP>, Guy Shaw writes: > In article <KARL.89Sep7225153@kant.cis.ohio-state.edu>, Karl Kleinpaste writes: > > For those of you not familiar, the -x option to uucico invokes debugging. > > Most importantly, invoking -x9 at YOUR end also puts MY end into -x9, > > Of course, the documentation for UUCP was one > the things that inspired the F in RTFM. I've often found it frustrating that Sun OS 3.5 (maybe others) doesn't have a man page for uucico. I asked someone about this once, and they told me there was no man page because uucico (as opposed to uucp) was not intended to be used DIRECTLY by administrators. Probably though it just got swept under the rug and forgotten. Some months ago (while trying to debug uucp/Trailblazer) I cobbled together a skeleton man page for uucico that gave the synopsis, etc, just so I wouldn't have to thumb through the book. Does anyone have a REAL man page for old uucico (not HDB) that they can share? Al Donaldson al@escom.com (703) 620-4823
mem@zinn.MV.COM (Mark E. Mallett) (09/13/89)
In article <KARL.89Sep9121610@godiva.cis.ohio-state.edu> karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) writes: >perry@ccssrv.uucp writes: > OUCH!! I trust it was unintentional, or at worst the consequences were > unforseen. > >Probably so. "Never attribute to malice what can be adequately >explained by stupidity" and other trite thoughts apply. I'd say that they apply to whoever made the "x" option affect both ends without a) documenting it and b) giving an option that didn't do this. NOT to the user of uucp who simply thought that the x option would simply turn on local debugging output. I have long been unimpressed with this feature of uucp; I too occasionally find large audit files, and I too grouse at the inability to run a -x9 uucico connection because of what it will do to the other end. -mm-