news@paris.ics.uci.edu (Mark Nagel) (08/20/88)
I am in the midst of setting up a news server on a Sun 4. After reading
the recent articles about NFS vs. NNTP, I thought it would be best to
make all the other sun servers and clients mount the news spool and
use NFS to read news. This also allows other news readers that don't
know about NNTP, which is nice. I think I understand what needs to be
doe, but I was hoping someone who has done this could give me a few
tips on how to make sure everything is correct. For example, it looks
to me like I'll need a separate news library on each sun server, each
with its own inews, logs, etc. I guess that this is no big deal, since
the main logs will be on the central news server. Anyway, I just wanted
to see if anyone out there had done this and could help me avoid any
traps. Thanks in advance!
Mark
--
Usenet News Administrator
news@paris.ics.uci.edu (ARPA)
ucivax!paris!usenet (UUCP)lamy@ai.toronto.edu (Jean-Francois Lamy) (08/21/88)
We have something like 80 machines in different groups NFS mount a central news server. On clients, inews simply validates a few things and mails to the central server (it could NNTP it, yes). Pnews has been lobotomized not to deal with moderated newsgroups, the inews on the server does it. Our news clients all have this view of the news stuff (we run Sun 2, 3 and 4s) /local/share/news (aka /usr/lib/news :-) looks as follows: active -> /nfs/news-server/news/lib/active (/usr/lib/news/active on server) inews mailpaths -> /nfs/news-server/news/lib/mailpaths (not used by Pnews/inews) newsgroups -> /nfs/news-server/news/lib/newsgroups organization /local/share/rn (often called /usr/local/lib/news/rn) looks like this: (all machines of a group, regardless of architecture, share this) INIT Pnews.header art.help filexp makedir mbox.saver mbox.saver.dateit -> /local/lib/rn/mbox.saver.dateit (machine dependant code) newsnews ng.help norm.saver organization -> /local/share/news/organization pager.help subs.help /local/lib/rn (machine dependent code -- each machine sees the appropriate one) mbox.saver.dateit rn and the rest of the programs people invoke directly are in /local/bin (each machine sees the appropriate one). The news server runs a locally grown mailer that can easily be made to collect all news articles sent in the last n minutes and create a news batch with them. That news batch is put in a single "lpd" queue, along with whatever UUCP batches are waiting to be unpacked. That way, only one news unbatcher ever runs at any one time. We have not found a satisfactory way yet to get NNTP to create, for each connection, a batch containing all articles not received yet. The problem is to deal with many concurrent NNTP transfers with many duplicates without forking an inews per article to keep the history file up to date... We can't afford forking inews like that... Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
parmelee@wayback.cs.cornell.edu (Larry Parmelee) (08/22/88)
I've set up our local hosts to run news via a sun NFS shared file system.
We've got a mixture of vaxen runing MtXinu unix and Sun 2s, 3s, and 4s
running Sun OS 3.5.
The setup here is as follows: One of the vaxen has a /usenet file system,
which it exports. A rough layout of /usenet is:
/usenet/bin/* - News reader programs, shell scripts.
/usenet/lib/news/* - the usual /usr/lib/news stuff
/usenet/spool/news/* - the articles (/usr/spool/news stuff)
We encourage our users to use only Larry Wall's "rn" program for their
news-reading. The advantage of this is that most of the auxillary programs
are shell scripts which run equally well on the vaxen or the suns.
On the systems which import /usenet, /usr/lib/news and /usr/spool/news
are symbolic links which point to the appropriate points on the
/usenet filesystem. In /usr/local (or whereever you usually put your
news executeables) there is a bunch of mini-shell scripts which just
exec the appropriate program from /usenet/bin. I use shell scripts
rather than symbolic links for the executeables because the importers
behave better should the system exporting /usenet be down.
This isn't too much of a burden, since only 2 different scripts are
needed, and hard links can be created between the various names.
For the news shell scripts, like Pnews, Rnmail, newsetup, and newsgroups,
the dummy shell script in /usr/local is just this:
#! /bin/sh
case "$#" in
0) exec /usenet/bin/`/usr/bin/basename $0` ;;
*) exec /usenet/bin/`/usr/bin/basename $0` "$@" ;;
esac
For the rn program itself, since this is an executeable which must be
different for each of the various machine architectures, /usenet/bin
contains several different "rn"s, denoted "rn.{vax,sun{2,3,4}}". The
dummy shell script in /usr/local for "rn" is as follows:
#! /bin/sh
B=/usenet/bin/rn
if ls -l /usr/include/machine | grep -s 'vax' ; then
N="$B".vax
else
N="$B".`arch`
fi
case "$#" in
0) exec "$N" ;;
*) exec "$N" "$@" ;;
esac
Probably I should have just created an "arch" command on the vaxen, which
would have simplified the above.
The above suffices for news reading. The next trick was to get posting
to work. For that, I used nntp. Nntp comes with a dummy
"inews" program, so /usenet/lib/news contains a bunch of versions of
inews, "inews.{real,sun{2,3,4},vax}" Note the addition of "inews.real".
This is the "real" news version of inews, and thus it can be used only
on the machine that owns the /usenet filesystem. All the other inets
are the NNTP dummy inews. In place of "inews", I have the following
shell script, which selects the proper inews to use on a given machine.
Again, creation of an "arch" command on the vaxen would simplify this.
#! /bin/sh
# find echos $B iff $B is not on an NFS filesystem.
B=/usenet/lib/news/inews
N=`find "$B" -fstype 4.2 -print`
if [ "X$N" = "X$B" ] ; then
N="$B".real
else
if ls -l /usr/include/machine | grep -s 'vax' ; then
N="$B".vax
else
N="$B".`arch`
fi
fi
case "$#" in
0) exec "$N" ;;
*) exec "$N" "$@" ;;
esac
I've probably forgotten some (hopefully minor) details. This seems
to work quite well for us. We've been using this setup for about 4
months now. Several things to note: The /usenet file system is huge
(/usr/spool hasn't over-flowed since I set this up!!!) and also used
for uucp. The system exporting /usenet is a microvax II, more-or-less
dedicated to news and uucp purposes, with only a few occasional users.
Nonetheless, loads on the system are usually very reasonable. This
host also feeds news to several other campus news leaf nodes on
an after-hours basis (not via nntp), and exchanges nntp news with
four other sites all the time. The startup delay due to the shell
script indirection, NFS, etc is negligible.
-Larry Parmelee
parmelee@cs.cornell.edu
cornell!parmeleeparmelee@wayback.cs.cornell.edu (Larry Parmelee) (08/24/88)
In my previous article, I quoted several shell scripts.
Steve Hayman <sahayman@watmath.waterloo.edu> pointed out
to me that the shell scripts could be further simplified
by the use of an oft overlooked feature of the Bourne
Shell. For example, the shell script I originally had as:
#! /bin/sh
case "$#" in
0) exec /usenet/bin/`/usr/bin/basename $0` ;;
*) exec /usenet/bin/`/usr/bin/basename $0` "$@" ;;
esac
can be re-written as:
#! /bin/sh
exec /usenet/bin/`/usr/bin/basename $0` ${1+"$@"}
and similiar changes are possible with the other shell scripts
as well. Thanks Steve.
-Larry Parmelee
parmelee@cs.cornell.edu
cornell!parmeleedavid@ms.uky.edu (David Herron -- One of the vertebrae) (09/05/88)
This looks good Larry ...
My only question is what do you do about the history file? Isn't dbm
a host-dependant format? (I've never tested it out, but since it has
things like disk addresses and such it would likely be host dependant).
You can say things like ... users are 'urged' to use rn only, but at
least here we have a couple of stick-in-the-mud's who use vnews.
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- Problem: how to get people to call ...; Solution: Completely reconfigure
<---- your mail system then leave for a weeks vacation when 90% done.