francis@cis.ohio-state.edu (RD Francis) (06/28/91)
Well, we've finally switched over to our new machine running C-News (with Dave Alden's nntplink stuff, and Rich $alz's newsgate). Most things are going smoothly, but I do have a couple of questions: 1) Evidently BNews inews (or at least our copy of it) checked for multiple occurrences of the same group in the Newsgroups: line, and removed them, so articles with lines like "Newsgroups: test,test" would only get posted to test once. Now, articles with the Newsgroups header described above get posted twice. Is this the way things are supposed to be,or not? (We've got a piece of software we wrote that assumes that the duplicates will be weeded out of Newsgroups, which I'm willing to work on to resolve the problem on our end; I was just curious as to whether or not the behaviour we're seeing is considered correct) 2) This one is much more serious. rn users have, on two or three separate occasions now, been told that all of their newsgroups were bogus, and been unsubscribed from everything. I suspect that this has occurred at the same time as I've been running addgroup (and maybe delgroup). I've changed newgroup so new groups are not automatically created, and run addgroup myself. My suspicion is that when addgroup (again, or delgroup) changes the active and active.times files, rn is getting seriously confused. Does anyone have any suggestions? -- R David Francis francis@cis.ohio-state.edu
henry@zoo.toronto.edu (Henry Spencer) (06/28/91)
In article <CMM.0.88.678044489.francis@wolfman.cis.ohio-state.edu> francis@cis.ohio-state.edu (RD Francis) writes: >1) Evidently BNews inews (or at least our copy of it) checked for >multiple occurrences of the same group in the Newsgroups: line, and >removed them, so articles with lines like "Newsgroups: test,test" >would only get posted to test once. Now, articles with the Newsgroups >header described above get posted twice. Is this the way things are >supposed to be,or not? Our position tends to be that if the group appears twice, that means the article appears twice. There is some possibility this might eventually get optimized, but don't hold your breath. >2) This one is much more serious. rn users have, on two or three >separate occasions now, been told that all of their newsgroups were >bogus, and been unsubscribed from everything... No ideas about this one. There is inherently a short window during a delgroup when files are being rewritten, but I'd be surprised if rn was consistently hitting it. -- Lightweight protocols? TCP/IP *is* | Henry Spencer @ U of Toronto Zoology lightweight already; just look at OSI. | henry@zoo.toronto.edu utzoo!henry
alexis@panix.uucp (Alexis Rosen) (06/28/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >francis@cis.ohio-state.edu (RD Francis) writes: >>2) This one is much more serious. rn users have, on two or three >>separate occasions now, been told that all of their newsgroups were >>bogus, and been unsubscribed from everything... > >No ideas about this one. There is inherently a short window during a >delgroup when files are being rewritten, but I'd be surprised if rn was >consistently hitting it. I can't believe you guys haven't been asked about this one zillions of times. It messed me up good before I modified delgroups. I've been meaning to post a request for you to fix/change this for a while, since it may not be a bug, but it's definitely a deficiency. The problem is that if you run delgroups as root, the active file becomes owned by root. And if UMASK is to 600 (or do I mean 177?), the new active file won't be readable by others (this last is supposition, since I've only been bitten by part one, but that's bad enough). Of course, you _should_ run delgroups as news, but since none of us are perfect and news tasks are often dealt with by an admin running as root (again, despite "better practice" rules), I think delgroups should have lines to do appropriate chowns and chmods. Come to think of it, this may not be his problem, since this would require human intervention to be fixed. But it should be dealt with anyway... --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY alexis@panix.com {cmcl2,apple}!panix!alexis
cudep@warwick.ac.uk (Ian Dickinson) (06/28/91)
In article <1991Jun27.201257.29111@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <CMM.0.88.678044489.francis@wolfman.cis.ohio-state.edu> francis@cis.ohio-state.edu (RD Francis) writes: >>2) This one is much more serious. rn users have, on two or three >>separate occasions now, been told that all of their newsgroups were >>bogus, and been unsubscribed from everything... > >No ideas about this one. There is inherently a short window during a >delgroup when files are being rewritten, but I'd be surprised if rn was >consistently hitting it. I had this problem and put it down the way delgroup replaces the active file, and rn does seem to get confused during that. Similarly, if I left an rn running overnight, it often got confued when I pressed a key because expire had done something similar. I don't have the problem anymore, since I use trn (rn is a link to trn) which uses the active2 file which mthreads creates. None of the other newsreaders in use here seem to have the problem. Ciao, -- \/ato /'\ /`\ Ian Dickinson TED KALDIS FOR PRESIDENT! /^^^\/^^^\ vato@warwick.ac.uk /TWIN/TEATS\ @c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson / \
henry@zoo.toronto.edu (Henry Spencer) (06/29/91)
In article <1991Jun28.084515.29919@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >The problem is that if you run delgroups as root... >... I think delgroups should have lines to >do appropriate chowns and chmods. No. There is fundamentally no way we can bulletproof our software against incompetent administrators; we refuse to expend substantial efforts trying. And the effort *is* substantial, because those "lines to do appropriate chowns and chmods" are Unix-version-dependent and need to be configurable in several ways. We're also unhappy at the thought of the sheer number of files that would need to have such lines sprinkled into them. As you mention, this doesn't sound like RDF's problem. -- Lightweight protocols? TCP/IP *is* | Henry Spencer @ U of Toronto Zoology lightweight already; just look at OSI. | henry@zoo.toronto.edu utzoo!henry
alexis@panix.uucp (Alexis Rosen) (06/29/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >alexis@panix.uucp (Alexis Rosen) writes: >>The problem is that if you run delgroups as root... >>... I think delgroups should have lines to >>do appropriate chowns and chmods. >There is fundamentally no way we can bulletproof our software against >incompetent administrators; we refuse to expend substantial efforts trying. >And the effort *is* substantial, because those "lines to do appropriate >chowns and chmods" are Unix-version-dependent and need to be configurable >in several ways. We're also unhappy at the thought of the sheer number >of files that would need to have such lines sprinkled into them. Would you please explain this? I'm willing to be convinced but I don't see how this can be. You already know about chown and chmod from the build script. And you already know what the name of the news ID is. What more do you need? Is there really a Unix where chmod 644 active ; chown news active won't do the trick? (You'd use variables, of course, I'm just keeping things simple. (Hm. Thinking about it, does active have to belong to the news _group_ as well as ID? It still shouldn't matter- you know about that from build too.) Also, how many such scripts are there? The only one I've ever run into on this is delgroup. (There may be others that I've never messed up with.) If you only did the "right" think, Cnews would be lots smaller, a little faster, and too troublesome for many people to run. Fortunately for us all, you generally do the good thing instead of the right thing, at least enough for us to generally cope. ("Do the good thing"? Spike Lee's sequel? :-) I think that the delgroups problem is a common enough failure that it's worth a few extra lines of code. While I'm discussing scripts, on A/UX addgroups fails to figure out the name of the creator, if a group is created locally. That's because $USER isn't defined. But $LOGNAME does. I'm not sure but I think some other unixes have this too. If so, could you use "${USER-${LOGNAME-unknown}}" instead of "${USER-unknown}" in addgroups? --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NYC alexis@panix.com {cmcl2,apple}!panix!alexis
cudcv@warwick.ac.uk (Rob McMahon) (06/29/91)
In article <CMM.0.88.678044489.francis@wolfman.cis.ohio-state.edu> francis@cis.ohio-state.edu (RD Francis) writes: >rn users have, on two or three separate occasions now, been told that all of >their newsgroups were bogus, and been unsubscribed from everything. I >suspect that this has occurred at the same time as I've been running addgroup >(and maybe delgroup). One reason I know for this is NFS. If you remove a file from the server while a client has it open, all operations on the file will fail with ESTALE. So programs that update the file in place are fine, as are programs which do <create active.new> rm -f active.old ln active active.old && mv active.new active the *first* time. If you repeat this, however, the file which an `rn' running on a client has open no longer exists, and it panics and thinks all the groups have been removed. `Addgroup' uses the first method, `delgroup' uses the second method, and cause this problem (well in fact it does `mv active active.old ; mv active.tmp active': wouldn't the above be better ? (no time when active doesn't exist)). `Expire' and `upact', but I think not `updatemin', also do this which can cause trouble if you leave rn running overnight. The real solution must be to change rn to notice that read operations are failing, and to close and reread the active file. Another solution would be to use something like ln active "active.keep/`date`.$$" instead, and mopup after all "reasonable" rn's should have exited (a day or two ?). Cheers, Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
ronald@robobar.co.uk (Ronald S H Khoo) (06/30/91)
alexis@panix.uucp (Alexis Rosen) writes, in reply to henry@zoo.toronto.edu (Henry Spencer) who is: henry> also unhappy at the thought of the sheer number henry> of files that would need to have such lines sprinkled into them. alex> Would you please explain this? I'm willing to be convinced but I don't alex> see how this can be. You already know about chown and chmod from the alex> build script And you already know what the name of the news ID is. alex> What more do you need? One major problem with chown()ing as a solution is that you have to remember to do it after creating just about any file at all. Yuk. Half of the volume of the news scripts would end up being devoted to this. Another thing is that it doesn't seem elegant to choose a solution with all these nasty races, when the real solution is simply to ensure that all maintenance scripts are run as news. This has other advantages anyway. However, "there is no portable way" in which a script can determine who it's run as. test "`whoami`" = news || die_with_error_message seems conceptually right, but can be confused by multiple entries in /etc/passwd for news, and the fact that System V would need a "whoami" shell script: #!/bin/sh expr "`id`" : 'uid=[0-9]*(\([^)]*\))' which will break the next time that USL decides to change the output format of /bin/id. However, I'd like to see some form of "whoami" emulation anyway, because it's useful. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)