dce@mips.COM (David Elliott) (06/08/88)
I'm sorry if this subject has already come up, but I've been out of
touch with this group for a month or so.
We are in the process of implementing a shared news system for our
in-house systems using NFS. We have one machine we use for the news
server, the news binary/data disk server, and we want it to be the only
machine to actually post the news.
The first part is easy, since we just point all of the machines at the
proper /usr/spool/news. Also, the last part is easy, since we will run
NFSCLIENT-compiled code on all machines except the server.
The second part is tougher. It's simple to set up each machine to have
the BINDIR binaries point to the right place, but harder to share the
LIBDIR stuff, since some of it is portable ASCII data and some is
nonportable binary data.
For now, we'll make do with setting up a BINDIR and LIBDIR for each
OS/hardware combination, and having symlinks for the sharable files.
Still, it would be nice if the implementors of B News 3.0 and C News
took this into account, and had a "sharable" library and a "nonsharable"
library.
Also, it would be nice to have site-specific things like NFSCLIENT,
GENERICPATH, GENERICFROM, and MYDOMAIN obtained from a configuration
file instead of having to compile it into the code.
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcehenry@utzoo.uucp (Henry Spencer) (06/15/88)
> The second part is tougher. It's simple to set up each machine to have > the BINDIR binaries point to the right place, but harder to share the > LIBDIR stuff, since some of it is portable ASCII data and some is > nonportable binary data... > ...it would be nice if the implementors of B News 3.0 and C News > took this into account, and had a "sharable" library and a "nonsharable" > library. To some degree we're ahead of you: C news keeps the programs and the control files completely separate. (This was a fairly late addition to the alpha release, and I think it wasn't quite right in places, but it's been cleaned up since.) There is one nasty problem that we know of no easy solution for: the dbm database format is machine-specific. If you're willing to use the dbm file *only* during posting -- which means, for example, that your news readers can't do lookup by Message-ID efficiently -- then this is not an issue. Otherwise I think everything in C news's /usr/lib/news is fully machine-independent. -- Man is the best computer we can | Henry Spencer @ U of Toronto Zoology put aboard a spacecraft. --Von Braun | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
shields@ists.yorku.ca (Paul Shields) (06/17/88)
In article <2320@quacky.mips.COM>, dce@mips.COM (David Elliott) writes: > We are in the process of implementing a shared news system for our > in-house systems using NFS. We have one machine we use for the news > server, the news binary/data disk server, and we want it to be the only > machine to actually post the news. We solved this problem on our Suns by installing nntp, which obsoletes the LIBDIR stuff on the clients. If you have tcp/ip you can do it, and it prevents a lot of headaches. Paul Shields, shields@ists.yorku.CA, shields@yunccn.UUCP (...utzoo!yunexus!ists, ...mnetor!ontmoh!yunccn)!shields It's amazing just how long it takes to get nothing done.
bob@tut.cis.ohio-state.edu (Bob Sutterfield) (06/25/88)
(Sorry if this discussion has become old - I'm trying to catch up on a few groups that I've let lie unread for a few days.) In article <147@ists> shields@ists.yorku.ca (Paul Shields) writes: >In article <2320@quacky.mips.COM>, dce@mips.COM (David Elliott) writes: >> We are in the process of implementing a shared news system for our >> in-house systems using NFS. We have one machine we use for the >> news server, the news binary/data disk server, and we want it to be >> the only machine to actually post the news. > >We solved this problem on our Suns by installing nntp, which >obsoletes the LIBDIR stuff on the clients. If you have tcp/ip you >can do it, and it prevents a lot of headaches. We have melded the two approaches: We NFS-mount /usr/spool/news and /usr/lib/news from a central server (a Pyramid 98x). /usr/lib/news/inews on each machine is a symbolic link to a private /usr/lib/newsbin/inews, which is either a local inews (on that Pyramid only), or an NNTP "fake inews" (on all the clients). This way, the server is the only machine to actually post the news. Also, /usr/lib/news/rn is a symbolic link to the directory /usr/lib/newsbin/rn, which contains all of rn's support shell scripts and help files. It turns out that inews and the rn directory are the only machine-private things that needed to be linked to something outside of /usr/lib/news for individual machines. The main reason we needed to use NFS-mounted filesystems for reading is because we have a few private newsgroups (e.g. for tenure-track faculty) that are kept private by normal file mode protection mechanisms and Yellow Pages distribution of the group file. We read news using all sorts of user front-ends, none of which need to know that they live in any sort of special world, like they would if we had to graft NNTP client code into them. The reason we needed to use an NNTP inews for posting was to avoid lock conflicts on the active and history files. A secondary reason why I personally prefer to use NFS to read news is because it's actually faster than using the NNTP protocol. I have run a "local" rn and a NNTP rrn side-by-side and rn comes up observably better in user responsiveness and feel. -- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob