readers.conf -- is this possible

Russ Allbery rra at
Sat Jun 24 02:45:05 UTC 2000

Todd Olson <tco2 at> writes:

> I'm wondering if the following is possible to implement within the
> framework of readers.conf.  If not I'm wonder which is the best avenue
> to start hacking the code.

What you're trying to do doesn't work well in INN right now for the
reasons that you state.  The Perl authentication hooks do a bit of a
better job with it, and the external authenticators need to be expanded to
have the same set of features as the Perl hooks.

> The problem is that the current *access* methods seem to be
>   "choose one and only one"
> while I need
>   "additively combine several"


> There are several avenues (in my order of preference)
> 1) make a new block, say "access_additive" that adds to 
>    rather than replacing the wildmats
> 2) make a new key in the existing access block, that 
>    adds to, rather than replaces the wildmats
>     (will this work in the current readers.conf ??)
> 3) make a key that calls a program to call an external program
>    to compute the wildmat and asign it dynamically.

> In nnrpd for version 2.2.2 we currently a #3 style hack,
> but I think #1 might be better.

Of those, we're going to get #3 eventually, but #3 is the most complicated
for the local administrator since they're generally going to have to write
some code to use it.  Of the rest, I like the idea of #2, and yes, I think
it should work even with the current parsing infrastructure.  It should be
possible to make it work in the new parsing infrastructure as well.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list