mangler@cit-vax.Caltech.Edu (System Mangler) (08/12/87)
[4.3 BSD]
Our uucp gateway is overloaded during the daytime, so I want to
limit the times of day that low-grade work such as news can be
transferred, while still allowing mail at any time.
In the time-to-call field, I specified:
Any/c,Night
which has the desired effect when we're doing the calling. But if
the other side initiates the call, *everything* gets transferred,
driving up the load average in mid-afternoon and tying up modems.
Half of our neighbors run binary releases of System V uucp, which
seems to ignore grade letters, so I can't just ask them to put
the above string in their L.sys.
How can I tell slave-mode uucico to defer low-grade work during
those hours?
Don Speck speck@vlsi.caltech.edu {rutgers,amdahl}!cit-vax!speckcsg@pyramid.pyramid.com (Carl S. Gutekunst) (08/12/87)
In article <3572@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: >How can I tell slave-mode uucico to defer low-grade work during >those hours? The intention of grading in 4.3BSD was to keep phone bills down, not to reduce machine load. Hence, if a machine calls you and isn't picky about grade, then everything goes. But you can do what you want: run the slave uucico from a shell script with the appropriate options. We do this for news all the time. Something like: nuucp:xyzzyxyzzyxyz:6:1:UUCP Login:/usr/lib/uucp:/usr/lib/uucp/uugraded where the file /usr/lib/uucp/uugraded contains #!/bin/sh exec /usr/lib/uucp/uucico -gc Of course, the script can be as ellaborate as you like, checking the time and so on. One DANGEROUS security hole: if you run a shell script like this, then make sure that the home directory for the login is *NOT* uucppublic. Otherwise you will have a world-writable directory from which the shell may look for a login startup script. (Actually, I believe 4.3BSD /bin/sh will not run .profile if it is invoked non-interactively as it is here. But /bin/csh definitely runs its .login and .cshrc scripts. And why take unnecessary chances?) <csg>
jr@amanue.UUCP (Jim Rosenberg) (08/13/87)
In article <3572@cit-vax.Caltech.Edu>, mangler@cit-vax.Caltech.Edu (System Mangler) writes: > [4.3 BSD] > > Our uucp gateway is overloaded during the daytime, so I want to > limit the times of day that low-grade work such as news can be > transferred, while still allowing mail at any time. > > Don Speck speck@vlsi.caltech.edu {rutgers,amdahl}!cit-vax!speck This solution is admittedly *extremely* ucky, bit it will work. I'm assuming that most of your unwanted load is coming from mail and news, which are really uux'ing to your system. It *won't* do anything to defer a true uucp, i.e. a transfer carried out by uucico. I don't know about Berkeley, but under System V there seems to be no harm done at all by deferring /usr/lib/uucp/uuxqt and then running it again later. The files sit around in the spool directory, but when uuxqt is really run then the work is performed as normal. You could rename /usr/lib/uucp/uuxqt to /usr/lib/uucp/uuxqt.real, then write a program which you call /usr/lib/uucp/uuxqt. Your program would get the time, and consult a file to see if it was OK to run real uuxqt. If it was OK then it would simply exec /usr/lib/uucp/uuxqt.real. If not it would simply exit, perhaps making an entry in a log file. Note that if you did this, a superuser could fire off the spooled work any time, should your load happen to be light, e.g. during lunch, by simply executing /usr/lib/uucp/uuxqt.real by hand from a shell. I'm running such a "tap" in my own uuxqt. My news link is running a different version of batcher, and I put in the tap in case he changes over to the same one I'm running now, so that I can preserve my spool directory files in case something's broke. My tap links all the spool directory files for a uucp xfer to a /usr/tmp/uucp directory, which is cleaned out by cron. It ain't pretty, but is pretty useful. It lets me go back the last 48 hours and resurrect any transaction which seems to have gotten fouled up. My serious hands-on experience is V7 and System V, so there may be some slight differences to get this to work under BSD, but I'm assuming the same general idea would work. Of course, if news is the only problem, you could just rebuild news and set the SPOOLNEWS option. This does exactly what you want: the incoming news just sits around in a spool directory until rnews -U is invoked, presumably from cron. All the serious cpu/disk load from rnews only happens when you do rnews -U. -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg seismo!cmcl2!cadre! /
chris@nrcvax.UUCP (Chris Grevstad) (08/15/87)
mangler@cit-vax.Caltech.Edu (System Mangler) says: >[4.3 BSD] > >Our uucp gateway is overloaded during the daytime, so I want to >limit the times of day that low-grade work such as news can be >transferred, while still allowing mail at any time. Well, we have the same problem. We also had (still have, actually, but this helps) the problem of running out of disk space, especially when we feed news to multiple sites. My solution was to hack on 4.3BSD UUCP a little to have it check a file in /usr/lib/uucp called EXECFILE for a command to run when there is no more work to be found for the particular site. The command is run via system(). After the command is run and there is still no more work, then uucico exits. Sample file follows: sddmt1 Any /usr/lib/news/sendbatch -O -c -s80000 sddmt1 kosman Any /usr/lib/news/sendbatch -O -c -s60000 kosman marge Any /usr/lib/news/sendbatch -O -c -s60000 marge #mentat Any /usr/lib/news/sendbatch -O -s80000 mentat mutley Any /usr/lib/news/sendbatch -O -b12 -c -s50000 mutley As you can see, all we use it for is news batching. I had a problem with the =batch patch suggested in the news source. I felt it was a little insecure. As suggested by Carl, you might give each of your uucp sites their own home directory. The time field is parsed by the same code that parses the time field in L.sys so you can put all the appropriate/necessary flags that are available. You might note that there is an additional flag to the sendbatch command. That is a hack to sendbatch to make it batch up only one package. This solves one of our disk space problems. We no longer run sendbatch out of crontab since it is now run on demand, resulting in at most one news packet sitting around for any one site, in the event that the UUCP conversation fails or the site fails to call us up for some extended period of time. A couple of improvements that I would like to make (but don't have the time for) would be (1): exec() the command directly, avoiding the problems and time associated with starting up a subshell with system. Another thing I would like to do is to be able to pipe the command directly into uucico, rather than letting the resultant uux command go through the trouble of setting up the appropriate control files and spooling the data. The only problem I have seen with this setup is when the command takes an extraordinarily long to run, the calling UUCP sometines times out. This usually only happens when the calling site is REAL lax about picking up news and has somewhere on the order of 6000 articles to pick up. Usually not a problem, and can be solved by running sendbatch by hand. I would be interested in any security holes that I may have inadvertently opened up. If anyone is interested, please let me know and I will either mail diffs or post them to the net. -- Chris Grevstad hplabs!sdcrdcf!psivax!nrcvax!chris ihnp4!nrcvax!chris Refund? REFUND!? ..... REFUND!?!?!
mangler@cit-vax.UUCP (08/18/87)
In article <3572@cit-vax.Caltech.Edu> I asked how to prevent 4.3bsd slave-mode uucico from sending low-grade work (such as uucp file copies and left-over news batches from the night) during peak hours. The best suggestion was: In article <4780@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > But you can do what you want: run the slave uucico from a shell script with > the appropriate options. We do this for news all the time. Something like: > > nuucp:xyzzyxyzzyxyz:6:1:UUCP Login:/usr/lib/uucp:/usr/lib/uucp/uugraded The "catch" was that uucpd cryptically rejects that shell field with "Login incorrect". It insists that the shell be "/usr/lib/uucp/uucico". So, if you do this, you have to rename the real uucico. Maybe slave-mode uucico should search L.sys for an entry corresponding to the dial-in device in use, to have a way of specifying dial-in grade time restrictions per site? E.g: sysv Any/c,Night DIALUP [unused fields...] with DIALUP defined in L-devices (the inverse of the way L-devices is normally used). Don Speck speck@vlsi.caltech.edu {amdahl,rutgers}!cit-vax!speck