gnb@bby.oz (Gregory N. Bond) (11/10/89)
I am in the process of installing Cnews on our system, and have run
into a few bugs. We have an obscure system setup, but some of the
bugs might be biting others.
We have (basically) 2 machines - melba and leo. Melba is a sun 3/260
running SunOs 3.5. Leo is a Solbourne (Sun 4 clone) running OS/MP
4.0A (basically SunOS 4.0.1+). Melba is the coms machine, it has the
modems and runs the comms software (we don't use UUCP, but use SUN-III
aka ACSnet - that's Sydney Uni network, not Sun Microsystems). The
news disk is on leo (along with most of the other disk - it's our
file and compute server). Melba mounts /usr/lib/news and
/usr/spool/news from leo, and of course has a private /usr/lib/newsbin
because it is a diferent architecture. Due to the cost of news across
NFS (which is e-bloody-normous) we run the main Cnews stuff on leo,
with nntp for the newsreaders. We are a leaf node, and have plenty of
spool space for our networking.
Hence our setup is for server=leo, but the rnews runs on melba. There
are two cripling bugs with this setup that cause batches to dissapear
down a black hole with no warnings, errors or failures.
1) The newsrun script assumes that the login shell for news is
/bin/sh, as the non-server machines run a command like
rsh $server "PATH=$PATH relaynews -n -r" < article
When news uses csh then this rsh command fails , silently. The
batch is then dropped. The spacefor command handles this properly.
I fixed the problem by doing something like
rsh $server "/bin/sh -c \"PATH=$PATH relaynews -n -r\"" < article
This is only a problem if you use rnews.immed, which I chose not to
do in the end as the rsh was pointless - the in.coming directory was
shared between the client and the server. Instead, newsrun is run
every 20 minutes from crontab on leo.
2) THIS IS A FATAL bug: rnews is run on the client, and it calls
spacefor to see if in.coming has enough room for a batch. If you do
a spacefor on a client, then that is converted into an rsh to the
server. Unfortunatly, the rsh command then gobbles the (first part
of) the input article batch as it is NOT run with the -n flag.
This means that the batch that newsspool reads is truncated or zero
length. Again, news dissapears silently (if your batches are
smaller than the input buffering in the rsh command) as newsspool
and newsrun ignore zero-length batches.
My fix was to comment out the bit in spacefor that does the rsh as
the answer will be the same on either machine (as the filesystems
are NFS mounted on the client). An alternative fix might be to run
rsh with the -n option. I haven't tried this.
As I write, it seems to be working, but I haven't been up for all that
long. I'll forward any more info that I get.
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbhenry@utzoo.uucp (Henry Spencer) (11/16/89)
In article <GNB.89Nov10181703@baby.bby.oz> gnb@bby.oz (Gregory N. Bond) writes: >1) The newsrun script assumes that the login shell for news is > /bin/sh, as the non-server machines run a command like > rsh $server "PATH=$PATH relaynews -n -r" < article > When news uses csh then this rsh command fails , silently... Frankly, we consider this a botch in rsh. If we wanted the C Shell [he says, suppressing the great temptation to expand "C" into some suitable adjective], we'd have said "rcsh". Yet another case of misguided attempts at "user friendliness" resulting in programmer-hostile software. Fixed in next patch. >2) THIS IS A FATAL bug: rnews is run on the client, and it calls > spacefor to see if in.coming has enough room for a batch. If you do > a spacefor on a client, then that is converted into an rsh to the > server. Unfortunatly, the rsh command then gobbles the (first part > of) the input article batch as it is NOT run with the -n flag. Now this is a *BUG* in rsh. Period. It's simply not acting the way a Unix command is supposed to. Yes, I realize it's difficult to fix, but if I wanted an operating system that a 14-year-old could write, I'd run MSDOS. :-) Programmers should not be forced to constantly work around bugs like this. Sigh. Fixed in next patch. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu