nnrp conf

[Edwardo Garcia]

Halo Russ,

Thank you for time to reply, I had not realize ORielly book must be so
old, I still think crazy remove, but accept explanation make sense.

before I put back server on, is  possible to have multi auth refer to
one access?
or require  matching pair?
example:

auth "localhost" {
    hosts: "localhost, 127.0.0.1, ::1, stdin, 200.x.x.x.x/24"
    default: "<localhost>"
}

access "localhost" {
    users: "<localhost>"
    newsgroups: "*"
    access: RPA
}

auth  name1 {
    hosts: " foo/16, bah/19, somefoo/19"
    default: "<parent>"     <--------------------------------
}

auth name2 {
    hosts: "x.x.x/17, x.x.x.x/16, ..."
    default: "<parent>"     <--------------------------------
}


access subsids {
    users: "<parent>"   <-----------------
    newsgroups: "*"
}

is this right?   each subsiduary busines we let access to, has many
many IP range, I see 8k limit per host line still, and we keep this
clean in case company sell off one company we just delete block, hope
have syntax right and wont be open server again?


On 12/3/14, Russ Allbery <eagle at eyrie.org> wrote:
> Edwardo Garcia <wdgarc88 at gmail.com> writes:
>
>> Can we please have the access methods of nnrp,conf brought back!!?!
>
> Hi Edwardo,
>
> I'm very sorry that you ran into a nasty problem because of the complexity
> of the readers.conf syntax.
>
> This was something that was much-discussed at the time that readers.conf
> was introduced, which was early in my own involvement in INN development.
> Some people were unhappy with it for exactly the reasons you name: it's a
> fair bit more complicated.  However, the opposing argument at the time was
> that it was much more expressive.  There are lots of complicated things
> that you can do with readers.conf that were completely impossible with the
> old configuration syntax.
>
> For whatever it's worth, the person who wrote the readers.conf parser and
> logic and argued successfully for replacing nnrp.access with it did that
> work for an ISP that needed more complex access control.
>
> Anyway, none of that really helps you at this point.  In concept, I can
> see a lot of appeal in having an alternative, very simple configuration
> syntax that didn't require understanding auth and access blocks.  However,
> this is water way under the bridge now.  All of the old code was removed
> in the INN 2.3.0 release, which was finalized in August of 2000, so it's
> been gone for more than 14 years now.  It would be pretty hard to restore
> in its original form.
>
> If someone feels up to tackling this, the easiest approach at this point
> would probably be to write a program that took the old syntax as input and
> converted it to an equivalent readers.conf file.  It's not as good as
> being able to use the old syntax directly, but it might provide most of
> the benefits and would be considerably less work.
>
> --
> Russ Allbery (eagle at eyrie.org)              <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.
> _______________________________________________
> inn-workers mailing list
> inn-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/inn-workers
>