[INN-COMMITTERS] inn (TODO)

Russ Allbery rra at stanford.edu
Sat Dec 28 19:52:15 UTC 2002


Marco d'Itri <md at Linux.IT> writes:
> On Dec 28, "Jeffrey M. Vinocur" <jeff at litech.org> wrote:

>> I'm generally bothered by control.ctl (especially lately with the
>> newgroup floods).  It should probably be kept in mind when designing
>> the new config file to replace newsfeeds/incoming.conf/innfeed.conf,
>> since the fundamental (though ephermal) list of "what groups we want to
>> carry" is relevant to that new file as well as the replacement for
>> control.ctl.

> Do not forget that it has to be parsed from perl...

Here's the file format that control.ctl is now generated from.  There is
one file like this per hierarchy:

    id: $Id: it,v 1.1 2002/11/28 08:39:42 eagle Exp $
    hierarchy: IT
    groups: it.*
    type: public
    description: Italian
    sender: [ gcn at news.nic.it ]
    contact: [ gcn at news.nic.it ]
    url: "http://www.news.nic.it/"
    pgp: yes
    key-id: gcn at news.nic.it
    key-fingerprint: "94 A4 F7 B5 46 96 D6 C7  A6 73 F2 98 C4 8C D0 E0"
    key-url: "http://www.news.nic.it/pgp.txt"
    admin-group: it.news.annunci

It's pretty straightforward to parse directly (I have Perl code to do
that), but it was also designed to be parsed with the new configuration
parsing library in INN.  I haven't stuck all the new control.ctl
generation stuff on a web page yet, but hope to get to that soon.  It
works *much* better for maintaining the control.ctl file, the PGPKEYS
file, and the README.html file on ftp.isc.org, but I think it would also
work better for INN down the road.  I also have code to convert a
control.ctl file to this format and back again.

This was really designed for my own purposes, but I tried to keep it so
that it could potentially be used for INN as well.  The basic idea is that
we could ship a file that contained all of the fragments like the above,
expand them out into a tree of files, users could edit those files to
change whatever they want (like the alt.* rules), and then they'd create a
separate file that looked like:

    hierarchy comp <control/comp>
    hierarchy it <control/it>

etc.  This is the syntax in the new config parser for defining a group
with the contents of another file.

There are several other ways to do this; that was just a first pass at the
idea.  There are still some difficulties with the above, not the least
being that there are 11 hierarchy configurations that can't be represented
using that syntax yet (generally university hierarchies with special
exceptions for class hierarchies, or the public hierarchies that shouldn't
allow control messages apparently from tale).  It also can't represent
(yet) exclusions that people want to add, like saying not to honor control
messages for the binary groups.

I think it could be expanded to handle those things if people are
interested.  I'm not sure when I'll get a chance to work on it more, but
I'll try to put all the stuff up on the web so that other people can play
before too long.

> I would *really* find good uses for a headers-only feed (there is no way
> I can use nnrpd for big server farms which need multiple hosts, but I
> still would like to use INN for transit and filtering, and maybe spool
> too.)

Modifying innfeed to generate a header-only feed is pretty trivial; the
only hard part is puzzling out where in innfeed to do it.  I think people
have even posted patches before.

What's the main obstacle to using nnrpd for reading?  The need to
replicate the spool to each of the reader hosts?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list