On 12/7/06, John Doe phoenixoverride@gmail.com wrote:
85.234.128.0/20 85.234.144.54/31 should handle the issue. Betacommand
On 12/7/06, Luna lunasantin@gmail.com wrote:
Oooh, good. Didn't know you subscribed to this list. :) Essjay's original block was on 85.234.128.0/19 , the address we seem to be friends with is 85.234.144.53
On 12/7/06, John Doe < phoenixoverride@gmail.com> wrote:
I can do the blocks of a range if you tell me what should NOT be blocked I can nail the rangeblock just right. Betacommand
So doing the CIDR blocks is the only way?
To be pedantic and fully complete, we'd want: 85.234.128.0/20 85.234.144.0/27 85.234.144.32/28 85.234.144.48/30 85.234.144.52/32
== gap for unblockee at 85.234.144.53/32
85.234.144.54/31 85.234.144.56/29 85.234.144.64/26 85.234.144.128/25 85.234.145.0/24 85.234.146.0/23 85.234.148.0/22 85.234.152.0/21
Unless I missed a bit or bits somewhere doing this in head and on fingers.
This seems like we should automate something; either a netblock minus exceptions interface tool to autogen the CIDR blocks from a top range plus some exceptions, or adding in an explicit "unblock this IP" override and have any CIDR block range lookup check the unblock override before returning blocked or not.
Nobody does Cisco ACLs or BGP routing this way the hard way if they can help it... and our admins by and large aren't network geeks.
George Herbert wrote:
This seems like we should automate something; either a netblock minus exceptions interface tool to autogen the CIDR blocks from a top range plus some exceptions, or adding in an explicit "unblock this IP" override and have any CIDR block range lookup check the unblock override before returning blocked or not.
As I understand it (and _please_ correct me if I'm wrong), single-IP blocks currently override range blocks (and autoblocks). Thus, as a partial workaround, we could place an anon-only block (with account creation permitted) on the specific IP, allowing logged-in users to edit from it.
Ideally, there should perhaps be some way to place a "null block" that would do nothing except override less specific blocks. But in practice, the workaround using an anon-only block seems almost as good to me.
The block message should, of course, say something like "please log in to edit from this IP address".
On 12/7/06, Ilmari Karonen nospam@vyznev.net wrote:
George Herbert wrote:
This seems like we should automate something; either a netblock minus exceptions interface tool to autogen the CIDR blocks from a top range
plus
some exceptions, or adding in an explicit "unblock this IP" override and have any CIDR block range lookup check the unblock override before
returning
blocked or not.
As I understand it (and _please_ correct me if I'm wrong), single-IP blocks currently override range blocks (and autoblocks). Thus, as a partial workaround, we could place an anon-only block (with account creation permitted) on the specific IP, allowing logged-in users to edit from it.
Ideally, there should perhaps be some way to place a "null block" that would do nothing except override less specific blocks. But in practice, the workaround using an anon-only block seems almost as good to me.
The block message should, of course, say something like "please log in to edit from this IP address".
Ok. That makes sense; can someone confirm that's the behavior?
It will probably save some time and sanity on the unblock-en-l members...
Thanks.
George Herbert wrote:
On 12/7/06, Ilmari Karonen nospam@vyznev.net wrote:
As I understand it (and _please_ correct me if I'm wrong), single-IP blocks currently override range blocks (and autoblocks). Thus, as a partial workaround, we could place an anon-only block (with account creation permitted) on the specific IP, allowing logged-in users to edit from it.
Ok. That makes sense; can someone confirm that's the behavior?
Just tested it on my local test wiki, and it works just like I thought. I should really have done that already in the first place.
wikitech-l@lists.wikimedia.org