Xref: utzoo comp.sys.apollo:7784 news.software.b:6766 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!svin02!eba!ebs!wjw From: wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) Newsgroups: comp.sys.apollo,news.software.b Subject: Re: Rn locks active file on Apollos(long) Keywords: postnews, active locked Message-ID: <1063@eba.eb.ele.tue.nl> Date: 1 Feb 91 09:28:33 GMT References: <168@numenor.gtephx.UUCP> Sender: news@eb.ele.tue.nl (The News system) Organization: Eindhoven University of Technology, The Netherlands Lines: 69 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