yountm@gtephx.UUCP (Marvin Yount) (01/31/91)
I'm trying to get Rn set up on our Apollo site. I've got it running
pretty well (up to patch 45), but we have noticed a situation regarding
the locking of the active file. When someone is running Rn, other people
can use Rn or readnews to read, but Rn is locking everyone out of posting
news (at least via postnews). Our news system is Bnews 2.11, recently
rebuilt under SR10.2 and sys5). Has anyone else run into this active file
locking situation and know of a solution to it?
A few facts and figures about our site. We have approximately 500 Apollos
on a token ring network. Most of our nodes are at SR10.1 (with a few
nodes at 10.2). We also have several nodes that must remain at SR9.7 for
awhile longer, but with news and Rn being built at SR10, these nodes won't
have direct access to news. Rn has been built on a 10.2 node. We are
primarily a sys5 site, but I was unable to get Rn built under sys5 and had
to turn to bsd to complete the build.
Thanks in advance for any help or suggestions.
--
======================================================================
Marv Yount (yountm@gtephx)
UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc}!gtephx!yountm
AG Communication Systems, Phoenixstealth@engin.umich.edu (Mike Pelletier) (02/01/91)
In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: >I'm trying to get Rn set up on our Apollo site. I've got it running >pretty well (up to patch 45), but we have noticed a situation regarding >the locking of the active file. When someone is running Rn, other people >can use Rn or readnews to read, but Rn is locking everyone out of posting >news (at least via postnews). Our news system is Bnews 2.11, recently >rebuilt under SR10.2 and sys5). Has anyone else run into this active file >locking situation and know of a solution to it? Here at the University of Michigan, we have a very similar environment -- about 500 apollos on various rings, and had the identical problem. Only processes running on the same node as the locking process will be able to access the file. The solution is to forget completely about the Apollo //* filesystem, and install C-news and NNTP on an individual Apollo node, and use rn with NNTP to access the articles. Since all the nntp daemon processes will be on the same node, they'll be able to interact with the files normally. We left the Apollos completely, and put news up on a DEC, but it should run without inordinate difficulty on an Apollo. -- Mike Pelletier - Usenet News Admin & Programmer "Wind, waves, etc. are breakdowns in the face of the commitment to getting from here to there. But they are the conditions for sailing -- not something to be gotten rid of, but something to be danced with."
wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) (02/01/91)
In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: >I'm trying to get Rn set up on our Apollo site. I've got it running >pretty well (up to patch 45), but we have noticed a situation regarding >the locking of the active file. When someone is running Rn, other people >can use Rn or readnews to read, but Rn is locking everyone out of posting >news (at least via postnews). Our news system is Bnews 2.11, recently >rebuilt under SR10.2 and sys5). Has anyone else run into this active file >locking situation and know of a solution to it? > Well this sound more than familiar! Tis was the reason why I killed news when we were still running sr9.7. There was just to much hassle in keeping it up and running. On Sr10.x however it runs as smooth as Rools Rojse. Why are you in trouble: - Once a user starts reading news, it opens the active file for reading this prevents writing access to this file from stations which are remote ( with reference to the place to the active file ). If you invoke postnews, it turns to inews to get the message posted. Inews will try to open the active file to update the area which got a extra message, but unless this is done on the station where the active file is on the disk, it will fail. This is how we work: - We download from a system on our campus backbone using nntpxfer. Posting is done with sendnews, since we do not have many postings. This is what I've done, to prevent the problems: - I've created a file active.copy which is for the user to read when starting news. This is a copy of the real active file. It can be created by cron every 5 min. (Our as we do it, after the download make a new copy). Then the user copies this file to /tmp/active.${user} And there's no reason why he should cause trouble anymore. For this you only have to change the path of active in the rn And while your at it, change the enviroment-string org to look for something like rnorg. (gets ride of the 'org: none' string in a message header.) - Posting is more of a problem: You still have to prevent the active file from getting inacessible for more acces to it (like at download time.) Fortunatly is there an inews (I called it inews.fake) which looks like inews, but connects to an nntp server where it posts the new article. This also solves the problem for running things on SR9.7. So run nntpd on the node where you have the active file. (Note: Nntpd invokes the real inews). This construction also supports another scenario, where a site upload news through nntp. The moral of the story is to have one site as news-admin site. Here all the transactions on the news-database take place. Users are allowed to make copies, and can read the global /usr/spool/news tree. I've got our /usr/local/news directory available for anon-ftp, so if you want so can get all binaries. There are also 2 files describing the changes made. Also available are the sources in /usr/local/src/news. The address: ftp.eb.ele.tue.nl(131.155.2.25) Dirs: /pub/apollo/local/news /pub/apollo/local/src/news Ciao, Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
rees@pisa.ifs.umich.edu (Jim Rees) (02/02/91)
In article <1991Jan31.195615.13448@engin.umich.edu>, stealth@engin.umich.edu (Mike Pelletier) writes: In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: >I'm trying to get Rn set up on our Apollo site. I've got it running >pretty well (up to patch 45), but we have noticed a situation regarding >the locking of the active file... The solution is to forget completely about the Apollo //* filesystem, and install C-news and NNTP on an individual Apollo node, and use rn with NNTP to access the articles. That's one way to do it, but it seems a shame to not use the Apollo distributed file system to read the articles. Using nntp will put a bigger load on both clients and servers and slow down your news readers. What we did at Apollo, and what the Engineering School here did until recently, was closer to what Willem suggests. Fix the readers to copy the active file and work out of the copy. Fix both readers and inews to retry on a locked active file. Unfortunately this is more work than most people want to do when there is another solution available. These days people like to pretend that files are never implicitly locked, and that the whole universe is one big happy Unix file system. File system folks (like me) are trying hard to provide this fiction, even though some of us think it's a little misguided (I happen to like knowing that I've got exclusive access to a file when I open it for write). I've still got the code for inews that sets the proper locks on the active file, and retries on busy. I'll be happy to send it to anyone who wants it.
sboyle@mentorg.com (Sean Boyle x1542) (02/02/91)
In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: >I'm trying to get Rn set up on our Apollo site. I've got it running >pretty well (up to patch 45), but we have noticed a situation regarding >the locking of the active file. When someone is running Rn, other people >can use Rn or readnews to read, but Rn is locking everyone out of posting >news (at least via postnews). Our news system is Bnews 2.11, recently >rebuilt under SR10.2 and sys5). Has anyone else run into this active file >locking situation and know of a solution to it? What we did here was modify rn to look at active.copy and on the node connected to the filesystem containing the active file copies the active file over the top of active.copy every 15 minutes or so... This seems to work fairly well. -- "There is a time to laugh and a time not to laugh and this is not one of them." Inspector Jacques Clouseau sboyle@mentor.com Mentor Graphics Corporation
stealth@engin.umich.edu (Mike Pelletier) (02/04/91)
In article <4f8ebb1a.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article <1991Jan31.195615.13448@engin.umich.edu>, stealth@engin.umich.edu (Mike Pelletier) writes: > > In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: > >I'm trying to get Rn set up on our Apollo site. I've got it running > >pretty well (up to patch 45), but we have noticed a situation regarding > >the locking of the active file... > > The solution is to forget completely about the Apollo //* filesystem, and > install C-news and NNTP on an individual Apollo node, and use rn with NNTP > to access the articles. > >That's one way to do it, but it seems a shame to not use the Apollo >distributed file system to read the articles. Using nntp will put a bigger >load on both clients and servers and slow down your news readers. The articles have to get around the ring one way or another... If there is a slowdown, it's imperceptible to anything but a program, and doesn't impact the reading of news. >What we did at Apollo, and what the Engineering School here did until >recently, was closer to what Willem suggests. (Not too recently here at Engineering... Over a year or so...) -- Mike Pelletier - Usenet News Admin & Programmer "Wind, waves, etc. are breakdowns in the face of the commitment to getting from here to there. But they are the conditions for sailing -- not something to be gotten rid of, but something to be danced with."
wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) (02/05/91)
In article <1991Feb4.153336.8268@engin.umich.edu> stealth@engin.umich.edu (Mike Pelletier) writes: =>In article <4f8ebb1a.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu => (Jim Rees) writes: =>>In article <1991Jan31.195615.13448@engin.umich.edu>, => stealth@engin.umich.edu (Mike Pelletier) writes: =>> In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: =>> >I'm trying to get Rn set up on our Apollo site. I've got it running =>> >pretty well (up to patch 45), but we have noticed a situation regarding =>> >the locking of the active file... =>> =>> The solution is to forget completely about the Apollo //* filesystem, and =>> install C-news and NNTP on an individual Apollo node, and use rn with NNTP =>> to access the articles. =>> =>>That's one way to do it, but it seems a shame to not use the Apollo =>>distributed file system to read the articles. Using nntp will put a bigger =>>load on both clients and servers and slow down your news readers. I agree completely with Jim. We've got this nice file system, and because things are a little different from the way the creators of the news-system thought they would be, we're going to shoot the bugger with the largest canon they've got in the gulf. =>The articles have to get around the ring one way or another... =>If there is a slowdown, it's imperceptible to anything but a program, =>and doesn't impact the reading of news. Well not completely. If you've got an extensive 'KILL' list (like mine), every new group does get read ahead. The system then really gets penallised?? by having to fetch the articles through NNTP. Generating an Index is also much slower. One more problem gets a solved by sr10.3. It used to be that the maximum number of processes was 64. Now in your concept you've got to run the NNTPD on the system were the news comes in. (Unless you abuse 'another' Unix system for this). At our place this system (our gateway) also runs sendmail, portmap, mountd, nfsd, pcnfsd, atleast 4 DPCI processes, .... and of course the NNTP servers (which go upto 4 when downloading) So You'll understand that processes is among the very scare resources. So the blunt hatchet does really cost you. =>>What we did at Apollo, and what the Engineering School here did until =>>recently, was closer to what Willem suggests. => =>(Not too recently here at Engineering... Over a year or so...) I've patched news this way in 1988, under sr9.7 for the first time. But then other things were causing headaches, so it all got scratched again. In that time I also posted some of the previously described patches. The problem was then, that not everything really left our system. (UP/DOWNloading was done in a different way.) Ciao, Willem Jan Withagen. Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands