a3@rivm05.rivm.nl (Adri Verhoef) (03/26/91)
On account of a recent problem with the C-news checkgroups script, I'm coming up with a proposition here. A little background of the problem: it seems that new and old descriptions of newsgroups are kept in the newsgroups file, after executing checkgroups. How checkgroups should work, a proposition. ------------------------------------------- 1. Make a backup copy of the newsgroups file. 2. Fetch all valid top hierarchies (alt, bionet, bit, biz, comp, ...) from the checkgroups message, storing them in "top_hier". 3. Fetch all obsolete top hierarchies (!pubnet, ...) from the checkgroups message, storing them in "not_hier". 4. Delete all newsgroups that belong to one of the top hierarchies that were saved in "top_hier" or in "not_hier" from the newsgroups file. 5. Append all valid newsgroup descriptions from the checkgroups message to the newsgroups file. 6. Sort the newsgroups file. 7. Compare the newsgroups file and the active file. [Check groups] =========================================== Afterthoughts. -------------- a. File "localgroups" seems to be unneeded. b. The newsgroups file could now contain "control", "general", "junk", - although this is not necessary - so that a seemingly real comparison between newsgroups file and active file can be performed. c. The comparison between newsgroups file and active file needs to be worked out some more. [What about aliasing?] =========================================== This looks real easy to implement. (As they say: a one cent's whistle.) Action "7" is the hardest part to program, but since that has been done already, it only needs a little re-programming. -- Adri Verhoef (a3@rivm.nl, Postmaster, NewsAdmin, Systems Programmer, SysAdmin) National Institute for Public Health and Environmental Protection (RIVM).
karl.kleinpaste@osc.edu (03/27/91)
The obvious solution to the C News checkgroups problem is for C News sites simply to inhale the B News checkgroups script whole. All the script does is egrep/sed/comm crud. Apparently the copyright on B News prevents Henry & Geoff from including it in their distribution (based on past conversations), but I see nothing preventing individual sites from picking it up. -- ..Go:del showed that provability is a weaker notion than truth, no matter what axiomatic system is involved. --Douglas R Hofstadter, _Go:del,_Escher,_Bach_, page 19
jmaynard@thesis1.med.uth.tmc.edu (Jay Maynard) (03/27/91)
One gotcha: checkgroups should not say anything, pro or con, about any groups
in a hierarchy not mentioned in the checkgroups message. The reason behind
this is that checkgroups messages appear for hierarchies outside the Big 7
(bionet.* comes immediately to mind), and a checkgroups for bionet.* should
not have anything to say about alt.*.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.med.uth.tmc.edu | adequately be explained by stupidity.
"You can even run GNUemacs under X-windows without paging if you allow
about 32MB per user." -- Bill Davidsen "Oink!" -- meclewis@ferret.ocunix.on.ca (Chris Lewis) (03/29/91)
In article <1991Mar25.195250.24700@rivm.nl> a3@rivm05.rivm.nl (Adri Verhoef) writes: >How checkgroups should work, a proposition. The difficulty with this proposal is that it assumes that there is only one "authority" for checkgroups. In contrast, there's at least 3 major ones, and quite a few minor ones. Worse, their name-space overlaps, case in point "inet" and "world" (the mainline USENET one). This implies, amongst other things, that there are logically *several* different "newsgroups" files. One other peripheral issue is that of backwards compatibility... Frankly, given the way stock C-news checkgroups works (sorry H&G if my info is out of date) and B-news still gets upset with the different "authorities", you'll NEVER want to issue a real checkgroups anymore, for too many machines do moderately unpleasant things to their administrators when a checkgroups comes in, and we'll never get enough people to upgrade their software. This is an idea I came up with quite some time ago, but have never had a chance to implement - it's similar to something else I've seen recently: 1) Add an argument to the "Control: checkgroups" header. The argument specifies the "authority" or "sphere of influence". For example, Gene would post "world" (or usenet or whatever name we chose for it), then there'd be an "inet", "bionet" etc. etc. etc. Eg: "Control: checkgroups usenet" 2) The body of the article looks like the current B-news and C-news mechanism. It would be nice to have something capable of supporting some of the additional C-news active flags as well as the existing moderated/unmoderated. This file currently looks something like: flags newsgroup description newsgroup description flags newsgroup description .... 3) When a system receives a checkgroups header, it first saves the body in NEWSDIR/newsgroups.<authority> (or, perhaps better, "<authority>.ng") 4) A new newsgroup file is created by catting together all of the .ng files (with some munging to get rid of the flags). 5) The active file is compared against the ".ng" files (more or less the same way as now). 6) There should be a config option to indicate whether the newsgroup update should be performed or the differences just mailed to the administrator. T'would be nice to parameterize a bit further so that checkgroups will apply updates automatically in some hierarchies, but not in others. 7) There should be a "synchronization" mechanism, so that you can create "ng" files for given hierarchies with your existing newsgroup set. This is to simplify being able to tell checkgroups about local groups or groups that don't have an "authority" (probably alt). Things to think about: - If we extend the permissible flags, we might have to define some semantics about converting C-news ones into B-news ones (at least, converting it into something that B-news supports). For example, the "=newsgroup" mechanism in C-news could be used to automatically update the newsgroup aliases file in B-news. (These aren't isomorphic flags, but they're reasonably close) - How do we implement this so as to not blow out all of the machines that don't upgrade? We keep telling them about how to disable checkgroups. (null out the shell script) - installation is easy - both B-news and C-news should be able to slip in a shell program that implements this without changing any code (B-news may need to be modified to stuff the checkgroups argument out to the shell script) Benefits: - we get automated checkgroups without the software screaming like it does now. - we get the newsgroups[s] files updated. - This can be retrofitted to existing news systems easily, since it's largely an independent shell script. - some level of parameterization to customize how it operates on a finer basis. The principle problem to be overcome is security.... -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!