mrl@uai.com (Mark R. Ludwig) (02/20/91)
First of all, I hope I'm not wasting time and/or net bandwidth with this question, but it's driving me nuts. I hope this is the correct newsgroup for my question. I have been reading this newsgroup for the last several weeks, and have seen no mention of a problem such as this. I consider myself a novice at Usenet administration, so bear with me if I mangle the terminology (or the King's English)... By way of background, let me describe our configuration, just in case I am describing a "known problem." I retrieved C News from UUNET in late October; I don't know what "release" designation it has, if any. The machine is a Sun-4/260 running SunOS 4.1. I have installed C News in non-standard directories (such as /usr/local/bin instead of /usr/bin and /etc/news instead of /usr/lib/news), but the configuration and build scripts seem to have dealt with that quite nicely (thanks to the UTZoo team!). I have not tinkered with any of the programs; however, I have been loosening some of the protections of files and binaries in the target directories, in response to other errors (awk being unable to open $BINDIR/relay/canonsys.awk comes to mind immediately). Overall, I'm quite pleased with C News. Now to the subject problem... Sometime since starting the daily maintenance script ($NEWSBIN/maint/newsdaily) we began getting some reports of errors which I do not understand. Due to my naivety, I didn't start the daily maintenance scripts on day one, so unfortunately I don't know how long this has been happening. Here's an example from $NEWSCTL/log.o (which I have wrapped for readability--it's one line in the file): Feb 19 03:15:27.510 uunet - <casterln.666903484@are> no subscribed groups in `gnu.emacs.help' This problem is not limited to this one newsgroup; there are 21 complaints in today's log, naming 3 other newsgroups. Despite this message, some posts in the named newsgroups succeed in making it into the spool. For example, here are the last few entries from the spool directory for gnu.emacs.help: -rw-rw-r-- 1 news 1121 Feb 19 03:15 gnu/emacs/help/109 -rw-rw-r-- 1 news 2162 Feb 19 03:15 gnu/emacs/help/108 -rw-rw-r-- 1 news 28133 Feb 18 03:15 gnu/emacs/help/107 Clearly, *some* posts are getting through. Here are the relevant lines from our active file (we have 36 entries): gnu.emacs.help 0000000109 0000000001 y gnu.emacs.bug 0000000001 0000000001 m gnu.emacs.gnus 0000000005 0000000001 y gnu.gdb.bug 0000000001 0000000001 m The complaints are more prevalent for the gnu.* newsgroups, but since our volume is so low, these are among the most-active ones UUNET feeds us. Some of the complaints name groups which have no articles in our spool. (Side question: I have searched quite thoroughly and have been unable to find the rejected articles anywhere! I thought I might find them in newsgroup junk. Where are they?) I hope I have described the problem fully, and that someone "out there" has some idea what's happening here, or can point me in the right direction. Thanks in advance for your help...$$ -- PATH: mrl@uai.com UUCP: uunet!uaisun4!mrl PSTN: 213/822-4422 USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA 90293
geoff@zoo.toronto.edu (Geoffrey Collyer) (02/20/91)
Mark R. Ludwig: > Feb 19 03:15:27.510 uunet - <casterln.666903484@are> > no subscribed groups in `gnu.emacs.help' Looks likes another set of FAQ answers. This message means that gnu.emacs.help is not permitted by your subscription list (newsgroup pattern in your ME line). Very likely you'ved got "!gnu" in there or you've omitted "gnu" entirely. >Despite this >message, some posts in the named newsgroups succeed in making it into >the spool. For example, here are the last few entries from the spool >directory for gnu.emacs.help: > > -rw-rw-r-- 1 news 1121 Feb 19 03:15 gnu/emacs/help/109 > -rw-rw-r-- 1 news 2162 Feb 19 03:15 gnu/emacs/help/108 > -rw-rw-r-- 1 news 28133 Feb 18 03:15 gnu/emacs/help/107 This usually means that you are receiving cross-posted articles which name gnu.emacs.help and at least one group permitted by your subscription list. The link counts should be greater than 1 though, so perhaps the other group(s) aren't in your active file. >Clearly, *some* posts are getting through. Here are the relevant lines >from our active file (we have 36 entries): > > gnu.emacs.help 0000000109 0000000001 y > gnu.emacs.bug 0000000001 0000000001 m > gnu.emacs.gnus 0000000005 0000000001 y > gnu.gdb.bug 0000000001 0000000001 m Why do you have these groups in your active file when your sys file doesn't permit them? You should fix one file or the other. >(Side question: I have searched quite thoroughly and have been >unable to find the rejected articles anywhere! I thought I might find >them in newsgroup junk. Where are they?) Dropped articles (as opposed to junked articles, which are flagged with a "j" flag in the log file) do not appear in junk. Articles that you have clearly asked to be rejected are just dropped; articles are junked only when there is doubt (roughly, when your subscription list permits at least one group in an article yet none of these groups appear in active, which probably means that the newgroup for the valid group(s) hasn't arrived yet). -- Geoff Collyer utzoo!geoff, zoo.toronto.edu!geoff
mrl@uai.com (Mark R. Ludwig) (02/21/91)
Thanks to all for the quick answers! I had hoped I hadn't missed something simple...like a mistake in the `sys' file. Such is the fate when months pass between implementation phases. (*Sigh*) I guess it was the fact that cross-posted articles circumvented the check which threw me off the track.$$ -- PATH: mrl@uai.com UUCP: uunet!uaisun4!mrl PSTN: 213/822-4422 USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA 90293
tale@rpi.edu (David C Lawrence) (02/25/91)
[[ The bulk of this article is made up by the alt mess, especially
at the end, but it isn't really about alt. ]]
In <1991Feb20.063914.9994@zoo.toronto.edu> geoff@zoo.toronto.edu
(Geoffrey Collyer) writes:
Articles that you have clearly asked to be rejected are just dropped;
articles are junked only when there is doubt (roughly, when your
subscription list permits at least one group in an article yet none of
these groups appear in active, which probably means that the newgroup
for the valid group(s) hasn't arrived yet).
The "which probably means that the newgroup for the valid group hasn't
arrived yet" made me very curious, so I went and did an analysis of
everything I've junked since early November 1990. The statement appears
to be very false, at least in the case of my site. My reasons for saying
so appear after some more commentary.
In numerous alt group cases, I did in fact receive a newgroup of some sort
before subsequent junking of articles for it. I often even had ample time
to add the group if it was my wont. For many of the articles that have
passed through here, I dislike what having !rpi! in the path implies about
my own acceptance of the group as valid, _especially_ for alt groups.
Sometimes, though, it is quite useful. I could not otherwise really be
evaluating the traffic of a questionable alt group without this policy of
junked article transmission. For the analysis though I consider the whole
alt group question separate from looking at the other groups of hierarchies,
namely other regionals/alternative groups and the mainstream USENET.
This whole thing leads to propagation of groups (not just their articles)
by insipient seepage in all hierarchies. Not all of my junked articles
for the novell group, for example, were from the gateway and there has not
even been an erroneous escaped global newgroup for it. The problem is
aggravated by sites which still automatically created a new group each time
it gets one it never heard of before --- a practise the main Unix systems
ditched very long ago.
A summary, where the first number in the ratio indicates reception of
something I consider bogus and the second is something valid:
articles groups articles groups
ba 11:0 4:0 comp 145:3 26:3
bionet 3:0 2:0 misc 12:0 6:0
ca 1:0 1:0 rec 29:14 7:6
can 1:0 1:0 sci 5:2 3:1
gnu 2:1 2:1 soc 6:0 4:0
ny 2:2 1:1 talk 7:0 1:0
trial 0:5 0:1 ========= =======
====== ====== 204:19 47:10
20:8 11:3
alt 158:245 47:19
In the accounting which follows, here is how I approached it:
Ignore groups with character garbage {eg, ` and '} in name (9 total).
Ignore totally screwed up Newsgroups lines that broke the simple awk script.
Ignore groups in hierarchies I do not get (26 total). Personal favourites:
oh.my.god!theres.a.test.group.in.the.followup! (1)
local.test (1)
These contribute to the statistical inaccuracy of the rest of this
analysis, as most of them look like they are probably valid groups
in the regional hierarcy --- this indicates that the propagation and
subsequent junking came from cross-posting into a hierarchy I do
get, but misspelling the group name. I should change the format of
the report generator to just dump the whole Newsgroups: line rather
than split it.
Try to give some groups the benefit of the doubt; even if no newgroup was
issued before the junkings, or if, in the case of alt, it is in Spaf's
list despite my not carrying it. For other alt groups this generally
means that I was watching the traffic of an alt group which was not
created with a reasonable newgroup, or one that I had reservations about
for some reason.
The numbers are how many I junked. ()s indicate bogus articles, []s
indicate valid articles (perhaps in retrospect), {}s indicate not valid
here but in Spaf's list. Followed by x means I started blocking the
transmission of the group, while = means I started refiling, and
continued forwarding with the original header intact, the group.
ba (11 bogus): ba.forsale (3=), ba.misc.forsale (2=), ba.wanted (5=),
ba.wanted.housing (1)
bionet (3 bogus): bionet.molbio.pir (2), bionet.software.pc (1)
ca (1 bogus): ca.wnated (1)
can (1 bogus): can.usergroup (1)
gnu (2 bogus, 1 valid): gnu.gdb (1), gnu.utils (1);
gnu.emacs.vm.info [1]
ny (2 bogus, 2 valid*): ny.events (2); ny.forsale [2]
* ny.forsale was only deemed valid in subsequent debate and _then_ two
newgroups went out for it. None had been made prior to these junkings.
trial (5 valid): trial.soc.culture.italian (5)
comp (145 bogus, 3 valid): comp.arch.parallel-sym (1),
comp.dcom.lans.novell (102*), comp.forsale (2),
comp.forsale.computers (1), comp.graphics.pixutils (1),
comp.ibm.binaries.d (2), comp.mac.sys.programmer (1), comp.mail (1=),
comp.misc.admin (1), comp.neural-nets (1), comp.security (1),
comp.source.wanted (1), comp.sources.ibm.pc.d (1),
comp.sys.amiga.datacom (1), comp.sys.amiga.software.pirate (1),
comp.sys.amiga.unix (1), comp.sys.arm (2), comp.sys.ibm.pc.net (1),
comp.sys.ibm.pc.software (2), comp.sys.intergraph (4),
comp.sys.mac.app (1), comp.tex.text (1), comp.unix.appleIIgs (6),
comp.unix.appleiigs (4), comp.unix.shells (1), comp.windows.x.openlook (4)
comp.sys.3b1 [1], comp.sys.amiga.graphics [1], comp.sys.amiga.misc [1]
* Even when you take out 102 for the novell bogosity it still leaves 43:3
misc (12 bogus): misc.computers.forsale (1), misc.consumer.house (1),
misc.forsale.edu (1), misc.forsale.wanted (2), misc.jobs.offerred (3),
misc.sheep (4)
rec (29 bogus, 14 valid): rec.arts.tv.bbc (1), rec.auto (1), rec.moto (1),
rec.music (2), rec.pets.dog (2), rec.sport.midget.tossing (14),
rec.sport.snowboarding (8); rec.audio.car [1], rec.games.pinball [3],
rec.music.video [6*], rec.radio.amateur.policy [1], rec.radio.swap [1],
rec.sport.football.pro [2]
* I am not sure which others this applies to, but I know that in the
case of rec.music.video (and others) the articles appeared because
an admin jumped the gun and added the group locally well before a
netwide newgroup went out (was even scheduled to appear) for it.
sci (5 bogus, 2 valid): sci (3), sci.philosophy.tech_sci.skeptic (1),
sci.sceptic (1), sci.engr.chem [2]
soc (6 bogus): soc.culture.indianhelp (1), soc.culture.italian (1),
soc.culture.uk (1), soc.gender-issues (3)
talk (7 bogus): talk.bizarre.rabbit (7)
alt (158 bogus, 245 valid):
alt (4), alt.alt (4), alt.bicycles (3), alt.bitch.pork (1x)
alt.boned (1), alt.books (1), alt.borg.wesley.now (2),
alt.cult.movies (1), alt.cybertoon (3), alt.desert-sto (1),
alt.desert.storm.its.not.scud.its.al-hussein.dammit (6x),
alt.desert.toppings (19x), alt.deset-storm (1), alt.dice-man (1),
alt.ernie-pook (2), alt.fan.BIFF (1), alt.fan.jim_whitehead (1),
alt.fax.bondage (1), alt.finals.suicide (4),
alt.flame.those.nasty.little.hangnails-ouch (7), alt.forsale (1),
alt.fusion (3), alt.graffiti (3=***), alt.graphics (1),
alt.great.ass.paulina (9x), alt.great.ass.wheaton (2x),
alt.hash.house.harriers (2), alt.iraqi.dictator.bomb.bomb.bomb (2x),
alt.junk (5), alt.minutes.lame (1), alt.national.enquirer (9x),
alt.nodies (12x), alt.personal (1), alt.rock-n-rollup (1),
alt.rumors (1), alt.sca (3*** ***), alt.sex.aluminum.baseball.bat (4x),
alt.sex.homosexual (2), alt.sex.sonja (8), alt.sexy.bald.captains (1x),
alt.skiing (1), alt.stupid.putzkutz.putz (7x),
alt.suicide.finals (2), alt.tv.tinytoon (1), alt.unix.wizards (9x**** ***),
alt.vehicles (1), alt.wee.willie.wisner (2);
alt.bbs.internet [2], alt.bbs.lists [20], alt.bbs.lists.d [5],
alt.binaries.multimedia [1], alt.birthright {8=},
alt.california [12*], alt.cd-rom [1], alt.comp.compression [9**],
alt.cyberpunk.chatsubo [6], alt.drugs.usenet {1x}, alt.forgery {24x},
alt.fractals.pictures {29x}, alt.lang.teco [8], alt.magic [10],
alt.party [41****], alt.romance.chat [35** ***], alt.sex.pictures.d [1x],
alt.sport.bungee [20], alt.surfing [12]
alt.birthright was a mess. Steve Gallacci fans thought it was for
them, but it was an abandoned hulk left behind by Kent Paul Dolan &
crew, meant for discussion of the Birthright political party. Spaf
added it back on his list in the most recent round describing its
_intent_, but not its _traffic_. I am refiling it (and alt.fan.albedo)
to alt.fan.furry to agree with the traffic in it. I'm screwed if its
traffic does indeed start to be what it was originally.
* alt.california was a valid group. Many moons ago it was removed after
requests from some Californians (I recall, but have no records) and
subsequent discussion in alt.config. Some people never removed it,
it got a dabble of traffic recently, and made it back on Spaf's list.
Since adding it again, I have received _two_ articles for it.
** The person who newgrouped alt.comp.compression rmgrouped it within
hours of his first message. We were all hoping for the comp.compression
just to finish naturally and then have a good mainstream group for this.
But no, admins blew off the rmgroup request from the newgrouper. Bleah.
*** Another mess. Several months ago, I ignored the bogus newgroup and
junked articles for alt.graffiti. I think I eventually x'ed it. Then it
showed up in Spaf's list, so I gave it new life. Then it left Spaf's list,
traffic was dead, so I removed it. Then an rmgroup came from Wisner in
response to a run-away script at accuvax. Then Becker newgrouped it without
comment and few more articles followed. Now I just refile the traffic to
rec.humor where it fits fine.
**** I ignored the bogus newgroup for alt.party but watched the traffic
in junk move toward good discussion about how to pick themes for parties,
how to throw a good party, &c. So I added it. Only 43 articles since.
** *** I loathe this group. I am not completely sure why I carry
alt.romance.chat. Over 2000 articles in a week.
*** *** alt.sca was a valid group, but rec.org.sca was added. Several
months later, I stopped refiling it.
**** *** Mentioned in alt.config, validly newgrouped by rough alt.config
criteria but not added by me, rmgrouped by the person who newgrouped it.
I decided to x it rather than = it after noting that not one of the nine
articles I junked had any wizardly content.
--
(setq mail '("tale@rpi.edu" "uupsi!rpi!tale" "tale@rpitsmts.bitnet"))