[net.news] Turning off news and uucp for a period of time

nancy@resonex.UUCP (Nancy Blachman) (02/21/85)

When we are running experiments where we are collecting huge amounts
of data, we would prefer not to have news or uucp running because
they slow down the system.  

Do you have any recommendations on how to block news and uucp?

At the moment, I have a routine called block_calls, which disables
write permission on /usr/spool/uucp, so files can't be written 
to the spool directory.  After the experiment is done, we turn
write permission back on.  

Is there a better way of handling this?  By the way, I do not want 
to disconnect the modems because I want users to be able to dial up 
the computer remotely.
-- 

/\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\/
Nancy Blachman 		UUCP: {allegra,hplabs,ihnp4,ucbvax!sun}!resonex!nancy  
(408)720 8600 x37 	ARPA: sun!resonex!nancy@ucbvax.ARPA

dave@uwvax.UUCP (Dave Cohrs) (02/22/85)

> When we are running experiments where we are collecting huge amounts
> of data, we would prefer not to have news or uucp running because
> they slow down the system.  
> 
> Do you have any recommendations on how to block news and uucp?

How about changing the password for 'uucp' or changing the login name to
something else temporarily?  This way, you can guarantee that uucp can't
even log in.  You could easily make a shellscript to do this, and also
fix things so your uucp can't run either (turn off polling or whatever is
necessary).  It seems that if you stop up the queue directory, there could
easily be lossage of news/mail.  When we lose things here, especially mail,
I get very redfaced, and I feel you would also.
-- 
dave cohrs
...!{allegra,harvard,ihnp4,seismo}!uwvax!dave
dave@wisc-rsch.arpa

    (bug?  what bug?  that's a feature!)

chuqui@nsc.UUCP (The Phantom) (02/23/85)

In article <233@resonex.UUCP> nancy@resonex.UUCP (Nancy Blachman) writes:
>
>Do you have any recommendations on how to block news and uucp?

The easiest/cleanest way I've seen is simply turn off the execute bits on
/usr/lib/uucp/uucico. when a uucp system logs in, it will get a message
back something like 'no login shell' and time out. the break is clean, no
information is lost, chances of screwups (if you have to do and undo
multiple operations you can either miss something or get hit by a
vulnerability window) is minimal, and the loading of a login that fails is
minimal.

chuq


-- 
From behind the eight ball:                       Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc!chuqui@decwrl.ARPA

We'll be recording at the Paradise Friday night. Live, on the Death label.

roy@phri.UUCP (Roy Smith) (02/23/85)

> When we are running experiments [...] we would prefer not to have news
> or uucp running because they slow down the system.  
> 
> Do you have any recommendations on how to block news and uucp?

Instead of having /usr/lib/uucp/uucico in the shell field of /etc/passwd
for your uucp logins, put in /usr/lib/uucp/checktime, which appears
below.  I don't actually have this running here; I made this up just
now, so please don't flame me if I messed up a few details.  And, yes,
I'm sure this can be done just a simply with a shell file.

main ()
{
	if (open ("/usr/spool/uucp/shutup", FIO_READ) < 0)
		exec ("/usr/lib/uucp/uucico");
	else
	{
		printf ("sorry -- we're closed\n");
		exit (1);
	}
}

This attempts to open the "shutup" file for reading.  If the file DOES NOT
EXIST, open returns an error, and you just run uucico like you usually do.
If you can open the file, it exists, and you just exit.  The uucico at the
other end will get either a HANDSHAKE or TIMEOUT error and will give up.
All you have to do when you don't want uucp's to call you up is to create
this file; when you want to allow incoming uucp's again, just remove it.
You might want to warn you uucp partners about this; if they happen to
run uucico in debug mode, they will see the "sorry -- we're closed" message
and get confused as hell.  You can expand on this, I'm sure.
-- 

The opinions expressed herein do not necessarily reflect
the views of the Public Health Research Institute.

{decvax,ihnp4}!vax135!timeinc\
                              >!phri!roy (Roy Smith)
     {allegra,rocky2}!cubsvax/