Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!pleasant
From: pleasant@rutgers.rutgers.edu (Mel Pleasant)
Newsgroups: news.admin
Subject: Re: NFS news - problem ??
Message-ID: <4972@rutgers.rutgers.edu>
Date: Sun, 4-Oct-87 12:57:12 EDT
Article-I.D.: rutgers.4972
Posted: Sun Oct  4 12:57:12 1987
Date-Received: Wed, 7-Oct-87 05:46:33 EDT
References: <1396@osiris.UUCP> <228@tut.cis.ohio-state.edu> <1748@ho95e.ATT.COM> <21078@ucbvax.BERKELEY.EDU>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 63
To: fair@ucbarpa.Berkeley.EDU


In article <21078@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes:

> The other way to handle posting in a distributed filesystem
> environment for news is to run the NNTP protocol on the server,
> and provide the client systems with the fake inews that the
> distribution has in it (it looks like inews, acts like inews, but
> contacts the server to hand off the article to a real inews, in
> much the way that Bill Stewart suggested, but without the attendant
> authentication problems).
> 
> I think that Rutgers is doing this.
> 
> 	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu


Well, close.  What I've done at Rutgers is modify the client inews code (and
associated functions) heavily, mostly by not allowing certain sections of
code to run at all on the client.  There are just too many places where the
current file locking mechanisms won't work well in a distributed
environment.  Most solutions posted thus far simply ignore these problem
areas in the code.  The folks from Apollo are right though.  Unless you have
many client systems using the same server, it is unlikely that you'll be
bitten.  Unfortunately when it happens, the symptoms can be so obscure that
you have no idea how to attack the problem.

The model I use is conceptually simple.  I want the client inews to do as
much consistency checking as possible so it needs to be based on the
original code.  A parameterized version of the original seemed best.  Via
NFS the client has access to the server's lib and spool directories.
However, in my model, the only system to write to these directories is the
server.  Essentially, I went through line by line making sure that the
client never writes to the disk.  Various versions of my code have existed
since version 2.10.3.  My current version is based on 2.11.8.  Keeping in
step with the distributed version has been relatively painless.  By the way,
we use NNTP, but only as an IP server-to-server transfer mechanism.  At the
moment, the version of inews running on a client uses rsh to send the
article over to the server.  The client-to-server transfer mechanism used
can be easily changed.  ALL OF THIS CODE IS COMPLETELY PARAMETERIZED right
down through the installation scripts.

Another feature that I've implemented in the Rutgers news system is the old
M.I.T. "mail to BUGS" concept on TOPS-20.  On TOPS-20, one could mail to
BUGS-xxxx where xxxx was the name of a program or system that you were
reporting a bug on.  If a bulletin board by that name existed on the system,
the bug report would be placed there.  If no such bulletin board existed,
the report would be placed in the BUGS bulletin board.  In my version of
news, one can declare a newsgroup "x" to be at the top of a hierarchy of
newsgroups which will catch any message posted to a non-existent "x.a".  The
`catch-all' group can exist anywhere within the overall news hierarchy e.g.
it does not have to be a toplevel group.  One can also declare "x" and "x.b"
to be `catch-all' groups wherein articles posted to a non-existent x.y will
be caught in newsgroup x.  Likewise, articles posted to a non-existent x.b.z
will be caught in newsgroup x.b.  In other words, one can have many
`catch-all' groups within the same hierarchy.

Future Plans: Rick Adams and I have talked about including this code into
the official release.  I'm told that patch #10, which hasn't even made it
out the door yet, is already quite large.  So, we're shooting for patch #11.
-- 

-Mel Pleasant
uucp:   {ames, cbosgd, harvard, moss, seismo}!rutgers.edu!pleasant
arpa:   PLEASANT@RUTGERS.EDU