Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: nnrp conf (Noel Butler)
2. Re: nnrp conf (Julien ?LIE)
3. Re: nnrp conf (Edwardo Garcia)
4. Re: nnrp conf (Edwardo Garcia)
5. Re: nnrp conf (Russ Allbery)
6. Re: nnrp conf (Edwardo Garcia)
----------------------------------------------------------------------
Message: 1
Date: Tue, 02 Dec 2014 22:25:28 +1000
From: Noel Butler <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ouch.. 'n yes it is confusing for those not involved in its coding and
development, I kind of echoed your gripe some time ago, comparing it to
dnews access which is pretty much identical to what you've shown - I was
ignored on that aspect, I didnt realise that once it was plain as day
with inn as well, why the hell you'd go from something so clear to a
muddy watered mess I'll never know either.
and I'll +1 your request, not that it'll do much good I feel going by
past comments on other things.
On 02/12/2014 17:26, Edwardo Garcia wrote:
> Halo,
>
> Can we please have the access methods of nnrp,conf brought back!!?!
> for the love of god, I find for months our server has open to world
> because this readers.conf method of groups auth access foo, is such
> over complicating,
>
> example from ORielly
>
> n the virtual brewery example, we will allow any NNTP client in the
> Virtual Brewery domain to both read and post to al$
>
> # Virtual Brewery - nnrp.access
> # We will allow public reading of all newsgroups except our private one.
> *:R:::*,!rec.crafts.brewing.private
>
> # Any host with the Virtual Brewery domain may Read and Post to all
> # newsgroups
> *.vbrew.com:RP::*
>
> this methods so easy a child cant get it wrong why for love of god was
> changed?
>
> here a thought, maybe access can be determin by either readers.conf
> and its confuzions, or nnrp.conf with its so simple access like old
> was as exampled on google, if you want maybe if readers.conf exist it
> override nnrp file otherwise it use both, frank i think old method so
> much simple and zero hassle and my boss not threaten fire me like now
> for letting competition ISP customer use our server.
> _______________________________________________
> inn-workers mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/inn-workers [1]
Links:
------
[1] https://lists.isc.org/mailman/listinfo/inn-workers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20141202/570af073/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 02 Dec 2014 17:35:38 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Edwardo,
> in the virtual brewery example, we will allow any NNTP client in the
> Virtual Brewery domain to both read and post to al$
>
> # Any host with the Virtual Brewery domain may Read and Post to all
> # newsgroups
> *.vbrew.com:RP::*
It is the first example in the readers.conf documentation:
Probably the simplest useful example of a complete readers.conf,
this gives permissions to read and post to all groups to any
connections
from the "example.com" domain, and no privileges for anyone
connecting
elsewhere:
auth example.com {
hosts: "*.example.com, example.com"
default: <LOCAL>
}
access full {
newsgroups: *
}
> # Virtual Brewery - nnrp.access
> # We will allow public reading of all newsgroups except our private
> one.
> *:R:::*,!rec.crafts.brewing.private
And this one is the second example in our documentation:
If you have some systems that should only have read-only access to
the server, you can modify the example above slightly by adding an
additional auth and access group:
auth lab {
hosts: "*.lab.example.com"
default: <LAB>
}
access lab {
users: <LAB>
read: *
}
> this methods so easy a child cant get it wrong why for love of god was
> changed?
I do not understand well how you would have wanted the examples provided
with INN to be more clearer than that.
You just have to use "*.vbrew.com" instead of "*.example.com" and
"*,!rec.crafts.brewing.private" instead of "*". It is exactly what
you already wrote in nnrp.access!
> and my boss not threaten fire me like now
> for letting competition ISP customer use our server.
Well, you just had to use the first two examples shipped in the
readers.conf
documentation...
http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html#S5
In case you have another needs that are not covered in the examples,
do not hesitate to tell and I will be happy to add them to the
documentation.
--
Julien ?LIE
------------------------------
Message: 3
Date: Wed, 3 Dec 2014 12:12:36 +1000
From: Edwardo Garcia <[email protected]>
To: Noel Butler <[email protected]>
Cc: [email protected]
Subject: Re: nnrp conf
Message-ID:
<canso6eg8mubu6wqmvkkk2kyw6fh8hqdmggfgn65evtwwsdy...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
yes, i sawed your posting with dnews it does look much same, stupid to
complicate a change,
On 12/2/14, Noel Butler <[email protected]> wrote:
>
>
> Ouch.. 'n yes it is confusing for those not involved in its coding and
> development, I kind of echoed your gripe some time ago, comparing it to
> dnews access which is pretty much identical to what you've shown - I was
> ignored on that aspect, I didnt realise that once it was plain as day
> with inn as well, why the hell you'd go from something so clear to a
> muddy watered mess I'll never know either.
>
> and I'll +1 your request, not that it'll do much good I feel going by
> past comments on other things.
>
> On 02/12/2014 17:26, Edwardo Garcia wrote:
>
>> Halo,
>>
>> Can we please have the access methods of nnrp,conf brought back!!?!
>> for the love of god, I find for months our server has open to world
>> because this readers.conf method of groups auth access foo, is such
>> over complicating,
>>
>> example from ORielly
>>
>> n the virtual brewery example, we will allow any NNTP client in the
>> Virtual Brewery domain to both read and post to al$
>>
>> # Virtual Brewery - nnrp.access
>> # We will allow public reading of all newsgroups except our private one.
>> *:R:::*,!rec.crafts.brewing.private
>>
>> # Any host with the Virtual Brewery domain may Read and Post to all
>> # newsgroups
>> *.vbrew.com:RP::*
>>
>> this methods so easy a child cant get it wrong why for love of god was
>> changed?
>>
>> here a thought, maybe access can be determin by either readers.conf
>> and its confuzions, or nnrp.conf with its so simple access like old
>> was as exampled on google, if you want maybe if readers.conf exist it
>> override nnrp file otherwise it use both, frank i think old method so
>> much simple and zero hassle and my boss not threaten fire me like now
>> for letting competition ISP customer use our server.
>> _______________________________________________
>> inn-workers mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/inn-workers [1]
>
>
>
> Links:
> ------
> [1] https://lists.isc.org/mailman/listinfo/inn-workers
>
------------------------------
Message: 4
Date: Wed, 3 Dec 2014 12:17:09 +1000
From: Edwardo Garcia <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: [email protected]
Subject: Re: nnrp conf
Message-ID:
<CANso6eEgQ-W1R7fJ5qNEViOFTryqL0dcxHwHXM3WxN1qZ=i...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
no it is not same, you took one line and change it complicated into
auth group and access group, triple the work, and very obvious it is
not so clear how to use, why it change? this brackets comment with
LOCAL says localhost , so much confusion,
I not expect you understand since google reveal you partake in inn
devops and not typikal server admin with isp or carrier.
On 12/3/14, Julien ?LIE <[email protected]> wrote:
> Hi Edwardo,
>
>> in the virtual brewery example, we will allow any NNTP client in the
>> Virtual Brewery domain to both read and post to al$
>>
>> # Any host with the Virtual Brewery domain may Read and Post to all
>> # newsgroups
>> *.vbrew.com:RP::*
>
> It is the first example in the readers.conf documentation:
>
> Probably the simplest useful example of a complete readers.conf,
> this gives permissions to read and post to all groups to any
> connections
> from the "example.com" domain, and no privileges for anyone
> connecting
> elsewhere:
>
> auth example.com {
> hosts: "*.example.com, example.com"
> default: <LOCAL>
> }
>
> access full {
> newsgroups: *
> }
>
>
>
>> # Virtual Brewery - nnrp.access
>> # We will allow public reading of all newsgroups except our private
>> one.
>> *:R:::*,!rec.crafts.brewing.private
>
> And this one is the second example in our documentation:
>
> If you have some systems that should only have read-only access to
> the server, you can modify the example above slightly by adding an
> additional auth and access group:
>
> auth lab {
> hosts: "*.lab.example.com"
> default: <LAB>
> }
>
> access lab {
> users: <LAB>
> read: *
> }
>
>
>
>
>> this methods so easy a child cant get it wrong why for love of god was
>> changed?
>
> I do not understand well how you would have wanted the examples provided
> with INN to be more clearer than that.
> You just have to use "*.vbrew.com" instead of "*.example.com" and
> "*,!rec.crafts.brewing.private" instead of "*". It is exactly what
> you already wrote in nnrp.access!
>
>
>
>
>> and my boss not threaten fire me like now
>> for letting competition ISP customer use our server.
>
> Well, you just had to use the first two examples shipped in the
> readers.conf
> documentation...
> http://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html#S5
>
> In case you have another needs that are not covered in the examples,
> do not hesitate to tell and I will be happy to add them to the
> documentation.
>
> --
> Julien ?LIE
>
------------------------------
Message: 5
Date: Tue, 02 Dec 2014 18:29:32 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: nnrp conf
Message-ID: <[email protected]>
Content-Type: text/plain
Edwardo Garcia <[email protected]> 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 ([email protected]) <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.
------------------------------
Message: 6
Date: Wed, 3 Dec 2014 15:49:40 +1000
From: Edwardo Garcia <[email protected]>
To: Russ Allbery <[email protected]>
Cc: [email protected]
Subject: Re: nnrp conf
Message-ID:
<canso6egtkm2u1of+t1uhblr2ypb0t9lt9tx-y+rqq-1b3pc...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 <[email protected]> wrote:
> Edwardo Garcia <[email protected]> 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 ([email protected]) <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
> [email protected]
> https://lists.isc.org/mailman/listinfo/inn-workers
>
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 67, Issue 2
******************************************
