spaf@uther.cs.purdue.edu (Gene Spafford) (12/16/87)
For some months now I have been posting a "checkgroups" control message
every two weeks to help sites keep their files up-to-date. I will not
be posting the checkgroups message in that form again (at least for the
near future).
When the "inet" groups were created, they were given names that fit
into the regular 7-category newsgroup structure of the Usenet. The
arguments for this were that it would be easier to understand the
placement of these groups, and that it would be easier to migrate
individual "inet" groups into the mainstream Usenet if the conditions
were right. Although there is nothing wrong with these goals, the
software is not designed to handle the situation well. Considerable
"leakage" has occurred so that some sites get partial or full "inet"
feeds without expecting them. My regular "checkgroups" posting does
not include the "inet" groups, so system admins throughout the network
get mail every week telling them that dozens of "inet" groups are
invalid and should be removed -- so the message is not heeded.
Rather than continue to post something that annoys so many users and is
often ignored, I will post the "checkgroups" information as a shell
file that each system administrator can tailor to local specifications
and then run with a local distribution. I will post this script to
news.admin every two weeks until such time as the software gets a
little smarter or the "inet" groups all become full Usenet groups.
This is exactly how I was posting it a year ago, before the advent of
2.11 news, so most news admins should be familiar with the process.
If you have suggestions on how to do this more effectively or
comprehensively, please send me mail.
--
Gene Spafford
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spafclewis@spectrix.UUCP (Chris Lewis) (12/21/87)
In article <2660@arthur.cs.purdue.edu> Gene Spafford (spaf@arthur.cs.purdue.edu) wrote: [Gene requested that followups be mailed, but I think this is really symptomatic of a larger and more general problem and bears discussion here] >When the "inet" groups were created, they were given names that fit >into the regular 7-category newsgroup structure of the Usenet. The >arguments for this were that it would be easier to understand the >placement of these groups, and that it would be easier to migrate >individual "inet" groups into the mainstream Usenet if the conditions >were right. Although there is nothing wrong with these goals, the >software is not designed to handle the situation well. With C-news the situation is worse - ANY newsgroup not mentioned in "newsgroups" or "localgroups" files get bitched about. At lsuc I had to add bionet, alt, unix-pc, to.<site>, tor, ont, can, and usrgroup newsgroups to the localgroups file. This is what got me thinking about this last week. B-news (but not C-news) checkgroups.sh knows about "comp", "rec" (actually from the distributions header - this is what causes the inet.* problem) etc. and is smart enough to bitch only about them. In addition, neither B-news or C-news checkgroups will handle checkgroups originating from other "domains". We will in general always have problems with checkgroups, and problems with keeping up to date with other "domains" unless we do something about the semantics of checkgroups. We should remove the "USENET" bias from the checkgroups message. What I would suggest is that we implement a method by which checkgroups can handle an arbitrary number of "*.groups" files. This would largely consist of: 1) For each "domain", you have a "group" file: can.groups ont.groups tor.groups usenet.groups (the current newsgroups file) inet.groups spectrix.groups etc. (note: only the usenet and inet groups overlap in top-level name - doesn't matter though) 2) The checkgroups message contains an argument, eg: Control: checkgroups usenet.groups 3) checkgroups concatenates all of the *.group files together when it does its checking against the active file. 4) The contents of the checkgroups message gets written into the "argument" file. Eg: on a "checkgroup usenet.groups", the list of newsgroups gets written into the "usenet.groups" file. (There has to be some sort of safety check to make sure that someone doesn't say "checkgroups inews") 5) checkgroups might as well concatenate all of the "*.groups" file into the "newsgroups" file (so as to not break postnews or Pnews). Advantages: you can use checkgroups on groups other than the standard USENET ones - the "gateways" of the other sets of newsgroups can periodically post checkgroups. Cleans up some rough edges w.r.t. non-USENET checking and Newsgroups file. Doesn't require any changes to anything other than the checkgroups shell file (at least in B2.11, 2.10.3 or 2.10.2, or C-news Alpha). Real simple to install. The same shell file would probably work no matter what version of news is used. Disadvantages: requirement of up-to-date "group" files (eg: hand patching after a local newgroup) - not a big problem - one that C-news can handle automatically without change except to the newgroup script, B-news would require a bit of hacking to the newgroup stuff. (Eg: "newgroup <newsgroupname> <groupfilename>" appends the text of the article into the specified group file) I'm even volunteering to write a new version of checkgroups to do this. Regarding the present problem (why Gene is going back to manually issued checkgroups). Somewhere along the way between 2.10.1 and 2.11 the checkgroups shell file lost the ability to combine the localgroups file with the newsgroups file when it was doing its checking. Made presumably because it no longer requires the SA to pay any attention to localgroups w.r.t. checkgroups. A mistake in my opinion. As an interim hack, rather than lose the utility of the automatic checkgroups message, why don't we take out the stuff in checkgroups that checks distributions, and append localgroups to newsgroups for processing. In fact, why doesn't everybody simply use a slightly hacked up copy of C-news checkgroups? Along with making sure your localgroups file is up-to-date. For those people with inet.* groups and can't/won't upgrade, why don't they simply put an "exit 0" in the beginning of their checkgroups script? Then they can run it manually thru an unmunged copy. Whilst everybody else gets to use the stuff as was originally intended. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc}!spectrix!clewis [Also: lsuc!clewis in a pinch] Phone: (416)-474-1955