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? ---