readers.conf -- is this possible

[Russ Allbery]

Todd Olson <tco2 at cornell.edu> 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"

Right.

> 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 stanford.edu)             <http://www.eyrie.org/~eagle/>