mjr@osiris.UUCP (Marcus J. Ranum) (09/27/87)
Is there any reason why one system, that supports spooled news files, can't export /usr/spool/news to other systems under NFS ? Since nothing would be changed, it seems to be that the only hacks needed would be to postnews, rather than vnews. Have I overlooked something obvious ? --mjr(); -- If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness... -Johnny Mnemonic
mikel@flmis06.UUCP (09/28/87)
> Is there any reason why one system, that supports spooled > news files, can't export /usr/spool/news to other systems under > NFS ? Since nothing would be changed, it seems to be that the only > hacks needed would be to postnews, rather than vnews. Have I overlooked > something obvious ? We do this over RFS. The idea is simple, and you don't really need hacks into any of the software. The only problem arrises when you export /usr/lib/news and the remote system doesn't see itself in the sys file when you post something. This is easily overcome by having a "fake" NEWSLIB directory that gets exported, where everything is liked back to the real one, except for the sys file, which has a whole bunch of dummy entries for the remote systems to forward their stuff to the gateway, and not keep it for themselvs. So if I have systems aa, ab, ac, ad ... that read news over RFS from system codas, the sys file should look like this: aa:none ab:none ac:none ad:none codas:all:L:/usr/bin/uux - codas!rnews Which will feed it back to the net... Note that "none" is just a dummy which doesn't really mean anything unless you have a newsgroup or distribution that matches that. -- Mikel Manitius @ AT&T Network Operations mikel@codas.att.com.uucp | attmail!mikel
myers@orange.qtp.ufl.edu (John G. Myers) (09/28/87)
In article <271@flmis06.ATT.COM> mikel@flmis06.ATT.COM (Mikel Manitius) writes: >> Is there any reason why one system, that supports spooled >> news files, can't export /usr/spool/news to other systems under >> NFS ? Since nothing would be changed, it seems to be that the only >> hacks needed would be to postnews, rather than vnews. Have I overlooked >> something obvious ? > >We do this over RFS. The idea is simple, and you don't really need hacks >into any of the software. The only problem arrises when you export >/usr/lib/news and the remote system doesn't see itself in the sys file >when you post something. We do this over NFS. We have both /usr/spool/news and /usr/lib/news exported under NFS and we define HIDDENNET to be "orange", our mail guru. The only hack necessary is in our sys file, the contents of which are given below: orange:world,comp,sci,(...),fl,uf,to::/bin/true bikini:world,comp,sci,(...),fl,uf,to.bikini:F When a system other than orange posts, it uses the value of HIDDENNET to look for itself in the sys file, so it finds itself. When deciding which hosts to deliver the post to, however, it uses its own hostname to look through the sys file. Thus, we tell it to use /bin/true to "deliver" its post to orange. We actually store the news spool file on another host, "red", so we had to modify nntpd to setuid() itself to "news" in order to get around the NFS "root" --> "nobody" mapping. John G. Myers News Administrator UUCP: ...!inhp4!codas!ufcsv!ufqtp!myers Quantum Theory Project ARPA: myers%orange.qtp.ufl.edu@relay.cs.net University of Florida myers@[128.227.16.1]
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (09/28/87)
In article <1396@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: > Is there any reason why one system, that supports spooled >news files, can't export /usr/spool/news to other systems under >NFS ? Since nothing would be changed, it seems to be that the only >hacks needed would be to postnews, rather than vnews. Have I overlooked >something obvious ? What hacks? You just do it ... don't forget to export /usr/lib/news also. -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- E-Mail hacks get to talk about Spanish Cows whenever they want.
karl@tut.cis.ohio-state.edu (Karl Kleinpaste) (09/28/87)
I've been debating doing just that, but one of the problems is that I'd also want to export /usr/lib/news. The problem arises that our news machine is a Pyramid and this box on my desk is a Sun3. As one might guess, I can't use the Pyramid binaries, so I can't remote-mount /usr/lib/news. However, it might be possible to mount /usr/lib/news if all the binaries in the directory were made into symlinks to real binaries in (say) /usr/lib/newsbin on each machine. I think that would work. I haven't decided yet. It's something I'd really like to do. Another possible conflict is that you need to tell the real news machine (our Pyramid) enough so that it will uux a copy to the next link up the line. That won't happen directly without some substantial changes. -- Karl
wcs@ho95e.ATT.COM (Bill.Stewart) (09/29/87)
[ Various discussion about machines NFS-sharing /usr/spool/news and /usr/lib/news, and how the machines know to post both within the cluster and outside. ] Reading news doesn't seem to be a problem. Perhaps the way to post news is to replace inews on all machines except the server with a shell rsh server inews "$@" possibly adding -f "$Username@$Usermachine" if your mailer doesn't know who everyone is. This does all the work only once, on the server machine, and takes care of Karl Kleinpaste's problem that :news machine is a Pyramid and this box on my desk is a Sun3. All the other binaries I could find were related to batching, expiration, and other server functions, plus the various newsreaders which have to be recompiled separately per system. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
meissner@xyzzy.UUCP (09/30/87)
In article <7365@g.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: > In article <1396@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: > > Is there any reason why one system, that supports spooled > >news files, can't export /usr/spool/news to other systems under > >NFS ? Since nothing would be changed, it seems to be that the only > >hacks needed would be to postnews, rather than vnews. Have I overlooked > >something obvious ? > > What hacks? You just do it ... > > don't forget to export /usr/lib/news also. We do this at Data General, and there are a few gotcha's, nits, etc: 1) The news software executables live in the same directory as the databases (/usr/lib/news). If you have multiple CPU architectures (like say some Suns and a VAX), you may want/need to put the executables elsewhere and use symlinks and/or mount to get the right machine to execute the correct executable. 2) You have to decide how posting will be done (ie, will the machine name that the user posts to get put into the From/Path headers, or do you restrict posting to the master machine). At DG, I hacked inews (which the posting agents call) to do a gethostname, and if the machine is not the master host, it spawns an rsh to execute inews on the master machine do the posting. For example, I am currently posting this article from a machine "nightmare", but when inews is spawned, it will really post it on the machine "xyzzy" which is our net connection. If you have the clients post on their own machines, you get into some nasty problems such as: 1) you have to make sure flock/lockf works transparently on all machines for NFS disks, or you have to go back to the V7 way of locking the active file (with links); 2) You might see double postings, since the master machine is not in the Path header. I have put the relavant code for this at the end of the article. 3) You also have to make sure Reply's work as well (ie, configuring the client sendmail's to handle the addresses given it). 4) Rn really go crazy and damages the .newsrc file if you have the file system /usr/lib/news soft mounted, and the server is down. It also doesn't handle the case too well if the server dies in the middle, and it gets errors reading the active file (though after a few newsgroups it does figure something is wrong and restores the active file). To add my changes for rsh, add a line to defs.h with localize of the form: #define NFS_MASTER "xyzzy" /* machine to post news on */ And then add the following lines to inews.c after it closes the extra file descriptors because of uuxqt brain damage: #ifdef NFS_MASTER { /* Is this on a remote NFS system? */ char buf[256]; char **new_argv, **p; int pid, i; int status, (*hstat)(), (*istat)(), (*qstat)(); if( gethostname( buf, sizeof(buf) ) == 0 && strcmp( NFS_MASTER, buf ) != 0 ){ if( isatty(1) ) printf("Spawning inews on %s\n", NFS_MASTER); p = new_argv = (char **) malloc( sizeof(char *) * (argc+4)); strcpy(buf, LIBDIR); strcat(buf, "/inews"); argv++; *p++ = "rsh"; *p++ = NFS_MASTER; *p++ = buf; while( (*p++ = *argv++) != (char *)0 ) ; pid = vfork(); if( pid == 0 ){ /* child */ execv( "/usr/bin/rsh", new_argv ); perror( "/usr/bin/rsh" ); _exit( 127 ); } else if( pid > 0 ){ /* parent */ istat = signal(SIGINT, SIG_IGN); qstat = signal(SIGQUIT, SIG_IGN); hstat = signal(SIGHUP, SIG_IGN); while( (i = wait(&status)) != pid && i != -1 ) ; (void) signal(SIGINT, istat); (void) signal(SIGQUIT, qstat); (void) signal(SIGHUP, hstat); printf("Done with remote sh\n"); exit( status >> 8 ); } else { perror( "vfork error" ); exit( 1 ); } } } #endif -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa/Csnet: meissner@dg-rtp.DG.COM
fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (10/02/87)
Followup-To: 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
pleasant@rutgers.rutgers.edu (Mel Pleasant) (10/04/87)
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
evan@ndcheg.UUCP (Evan Bauman) (10/05/87)
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 I's LOVE to be able to do this here. We've got around 10 Suns with lots of Usenet enthusiasts scattered among them. So the next question is... Where do I get the NNTP software? Evan Bauman University of Notre Dame ..!iuvax!ndmath!ndcheg!evan