Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!fluke!pwl From: pwl@fluke.UUCP Newsgroups: news.admin Subject: Re: NNTP vs. remote NFS mounts Message-ID: <564@tc-pwl.tc.fluke.COM> Date: Wed, 11-Mar-87 17:05:02 EST Article-I.D.: tc-pwl.564 Posted: Wed Mar 11 17:05:02 1987 Date-Received: Fri, 13-Mar-87 00:19:03 EST References: <918@smeagol.JPL.NASA.GOV> <3311@rsch.WISC.EDU> Sender: pwl@fluke.COM Organization: John Fluke Mfg. Co., Inc., Everett, WA Lines: 87 In article <3311@rsch.WISC.EDU>, dave@rsch.wisc.edu (Dave Cohrs) writes: > There's one major point *against* just using NFS to access news. > > There is no easy way to separate the binaries et al in > /usr/lib/news. So what? Well, what if your server is a Gould and > the workstations are all uvaxen. The Gould version of inews doesn't > work too well on a vax :-) I guess this is OK if you never want to > *post* news. > > This problem caused me to go the NNTP route. We used to use NFS > when the server was a (really slow) vax. This article brings up one of my pet peeves with the layout of the news system. News has always had the notion that it was reasonable to take files which describe the news database and lump them with binaries of news maintenance programs, shell scripts for house cleaning, etc. This is tolerable when the news is isolated to a particular machine or architecture, but it causes no end of problems when one decides to distribute news using NFS or some other form of remote access. At our site we have five vaxen running 4.2bsd and almost forty Sun workstations, with six Sun file servers. About a year ago we decided to make a news server out of a single Sun system for all the other Sun systems. The NFS made this look like a reasonable goal. We could just ship the news to our news server and every client could NFS mount the news database. Unfortunately, the database administration files (active, history, sys, log, errlog) all lived in /usr/local/news, rather than somewhere in /usr/spool/news. Each file server has its own copy of /usr/local/news, so the database admin files had to somehow be moved out of the binary directory to someplace where they could be accessed as easily as the news database itself. Now I realize that symbolic links could be used as a bandage to fix this problem. However, we decided that we really wanted to repair the underlying problem. Our solution was to move the administration files to /usr/spool/news/.admin, which is a sub-directory within the news database. We then modified the news software by adding a new #define called "ADMIN". Anyplace there was a reference to "LIB/active" was replaced with "ADMIN/active". This was done for all of the database admin files. ADMIN was defined to be /usr/spool/news/.admin. The result is that a client machine merely does an NFS mount of /usr/spool/news from the news server. The news binaries (inews, rnews, etc.) reside on each of the file servers, in the various flavors needed by the clients (MC68010 and MC68020, Sun 2.2 and 3.2). To read news, the client just fires up the news reader of his choice. When a client posts an article, it is spooled in /usr/spool/news/.rnews through the services of the SPOOLNEWS option in 2.11 news. The news server checks this directory once an hour for news articles to be processed. This scheme has been working successfully for over a year now. Now for the good news/bad news. We are in the process of switching our vaxen over to MORE/bsd with NFS support. I had originally hoped that we could just NFS mount news from the news server on all the vaxen. It turns out that reading news in this manner is no problem. Unfortunetly, posting news is a different matter. When inews gets an article that should be batched for the news server, it first goes out to the history DBM database to see if it is a duplicate article. The DBM database is in a binary format, which is architecturally dependent. The vax dbm reading routines choke on the Sun generated database. So much for vax posting! There seem to be a couple of work-arounds for this problem. The one I am seriously considering is a scheme that was suggested recently by Chuq Von Rospach of Sun. He described their system, which uses NFS mounts to support news reading. News posting is done by using the Berkeley NNTP to transmit articles to the news server. This means that all article processing is done at the news server, which is where it belongs anyway. The nice thing about this approach is that you don't need a special version of the news readers. Also, installing and maintaining the NNTP code to just do posting looks like a reasonable task. So there you have it. I plan to implement the NNTP approach in the coming months. Please keep the ideas flowing. I have gotten many valuable ideas from these discussions. -- Paul Lutt KE7XT (206) 356-5059 new: pwl@tc.fluke.COM John Fluke Mfg. Co. old: uw-beaver!fluke!pwl P.O. Box C9090 Everett WA 98206 or: allegra!fluke!pwl