Xref: utzoo news.admin:4130 news.software.b:1777
Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!vsi1!wyse!mips!sultra!dtynan
From: dtynan@sultra.UUCP (Der Tynan)
Newsgroups: news.admin,news.software.b
Subject: Re: Auto-expiration of news
Summary: inews improvement (?) suggestion.
Message-ID: <2694@sultra.UUCP>
Date: 1 Dec 88 01:16:46 GMT
References: <1066@psuhcx.psu.edu>
Followup-To: news.software.b
Organization: Tynan Computers, Sunnyvale, CA
Lines: 41

From article <1066@psuhcx.psu.edu>, by wcf@psuhcx (Bill Fenner):
> 
> Does anyone have a good way to expire news automatically when the news
> partition gets full?  We only have a 25 meg partition for news, and it
> often manages to fill up on weekends, and it's a big pain to come in
> to find a console log 5 inches thick with logs of /usr/spool/news: write
> failed, filesystem full.

I have a similar problem.  Having given it some thought, I have come up with
a clean solution that (someday) I will implement in 2.11 (or whatever).  On
the other hand, if any of the *new-and-improved* news software people are
reading this, perhaps they'd care to comment?

Anyway, the idea is this.  In the NEWS/active file, a new field is introduced
in the tradition of the 'm' field for 'moderated'.  It is a boolean ('y'/'n'?),
which indicates that the given newsgroup is not read at this site.  In this
way, a nightly (or weekly) cron program would zip through all the .newsrc
files, to see what groups aren't subscribed to, and update the 'active' file.
On the other hand, if someone subscribes to a currently unavailable group,
the daemon would reactivate it.  And vnews/readnews/whatever would inform
the reader that the group isn't currently carried, but will appear in a few
days.  Of course, certain groups (such as comp.mail.maps) would have a special
mark saying that they must ALWAYS be subscribed to ('a' perhaps?). Then, rnews
as part of its processing, would look at this flag, and if necessary, dump
the article.

Currently, the two ways of doing this, are to remove the group from the
active file, in which case the 'junk' group fills up like nobodys business.
Or, conversely, to have the sysadmin at the remote feed modify the 'sys'
file, so that certain groups weren't sent.  This is awkward, because changes
may occur very frequently.  Both schemes also mean that the 'checkgroups'
messages will bomb fairly severely.  In this age of Trailblazers, I don't
think anyone is worried about line bandwidth, but just disk space (20Mb/week),
so this scheme would allow them to carry only those groups that people actually
read.  Comments?
						- Der
-- 
	dtynan@zorba.Tynan.COM  (Dermot Tynan @ Tynan Computers)
	{apple,mips,pyramid,uunet}!Tynan.COM!dtynan

 ---  If the Law is for the People, then why do we need Lawyers? ---