INN config file parsing infrastructure

Russ Allbery rra at
Sat May 6 08:52:28 UTC 2000

Olaf Titz <olaf at> writes:

> That would be nice, but then the configuration would have to be cut
> down radically.

That's part of the long-term goal.  I don't expect it to happen any time
soon, but every project needs good long-term goals.  INN has a lot of
fairly advanced configuration that needs to continue to be accessible to
those people who need it but which I think we could do a better job hiding
from those people who just want to get a news server running and would be
happy with the defaults.

> Compare that to Apache where you get a usable standard configuration in
> one file (although usually split in three for historical reasons) of
> 20k, and that is heavily commented.

Note that I strongly dislike pretty much everything about Apache's
configuration file syntax, just to state my bias.

> Worse, I don't see how a file like control.ctl can be sensibly GUIized
> without turning the GUI into a glorified text editor, but I also don't
> see a way of getting rid of it.

I think control.ctl is a good example of a badly factored configuration
file in the current Usenet world.  It combines site-specific configuration
information that could be presented much more succinctly (what hierarchies
that system wants to honor control messages for) with mostly static
configuration information that needs to be updated from canonical sources
but which rarely has to be customized for a particular site (the authority
details for each hierarchy).

Certainly there are cases like alt.* where a site administrator should be
editing the policy, but if you separate the problem into a policy editor
and a list of hierarchies for which you honor control messages, I think it
would be much easier to present it as a GUI, and if you change the
underlying files to match that structure (which is something to do slowly
and cautiously, of course, given the prevelance of control.ctl's syntax,
and which would require careful handling not only of backwards
compatibility but also conversion of arbitrary control.ctl file entries
pulled off the net), I think it would be much easier to manage.

To point out another configuration file that's likely bloating your
statistics mentioned above, innreport.conf really isn't a user
configuration file except for some of the bits at the top.  The vast
majority of that file is really at the same level as source code and
probably should be separated from the .conf file and put in lib instead.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list