View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003256 | unreal | ircd | public | 2007-03-07 11:21 | 2019-12-30 18:26 |
| Reporter | djGrrr | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | * | OS | * | OS Version | * |
| Product Version | 3.2.7 | ||||
| Fixed in Version | 5.0.1 | ||||
| Summary | 0003256: maxperip exception block | ||||
| Description | currently, as far as i know, the only way to add an exception for certain hosts to bypass the maxperip setting in the allow block, is to create a totally new allow block just for a specific host. I think this is a really bad way to do this, and there should be a much easier way via an except block. my idea is to have something along the lines of... except maxperip { mask *@localhost; limit 20; }; this should be relatively easy to implement (i think) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
My opinion: the allow block is perfect for this. I don't see why to create yet another method to do the same. If you start doing that for this, you can keep going on and on. Reminds me of the ircnet days, which had tens if not hundreds of I lines :) Perhaps sts/aqua can comment on this as well. |
|
|
well, the point of this is, it allows a simple maxperip bypass of multiple allow blocks at the same time. on my network i have all the leafs configured with 2 allow blocks. one is the standard allow block, and the other requires ssl and a password, and gives a different user class to have nofakelag. it would be a big pain to try and have multiple allow blocks per special ip exception, just imagine if i had even more general allow blocks.... i honestly think this would be a good addition, as the allow block is definetly not suited for this, and its not another method to do the same... edit: maybe i need to be a little clearer in my description :P |
|
|
Reasons allow block is better for this: - You can limit by hostmask and/or ipmask (though it's an either-or match if you use both). And yes, you can use CIDR. - You can require a password for it to be effective (nopasscont, for example). - You can require SSL (and possibly an ssl client cert). - You can assign the user to a different class, with a different user limit, etc. As syzop said, more than one way to do the same thing isn't really needed. Allow block is perfect for this. And it doesn't take that much more than making an except block. |
|
|
aquanight, you obviously read nothing that i wrote, if you did you would see that the allow block is crap for this just think of this... i have 5 different general allow blocks (ones that allow *@*) all with different requirements, like ssl, password, etc.... now, i want to add 1 ip/host to be exempt from maxperip, that means, i need to add 5 more HUGE allow blocks... correct me if i'm wrong but.... I would have thought that writing 1 line is a lot easier than writing 25+. Just because YOU would have no use for such a feature doesn't mean that 100s of other people wouldn't |
|
|
Could we stirr up a little more conversation on this? Perhaps some examples of use and such? |
|
|
ok, lets say you have 3 allow blocks, 1 is the general *@* allow block, matching any clients, second matches the same except ssl, third, matches *@* with ssl and a password that uses a class that gives fake lag excemption allow { ip *@*; hostname *@*; class clients; maxperip 2; }; allow { ip *@*; hostname *@*; class clients_ssl; maxperip 3; options { ssl; }; }; allow { ip *@*; hostname *@*; class clients_flood; maxperip 3; password "fl00d"; options { ssl; }; }; now, i think, it would be a lot better if you could simply just add this.. except maxperip { mask *@172.16.*; limit 20; }; rather than having to add 3 more huge allow blocks |
|
|
I'm fine with adding this, but am not willing to code it. I'm taking it off the todo list, but if anyone comes with a decent patch it will be added :) |
|
|
With the new exception infrastructure and ELINE, the following was added in 5.0.1 which allows you to achieve the same: commit fccb3b2f5bc8f845db4cee9d4e88512ccedb881b (HEAD -> unreal50, origin/unreal50) Author: Bram Matthys <[email protected]> Date: Mon Dec 30 18:19:09 2019 +0100 Add /ELINE exception type 'm' to bypass allow::maxperip. In the configuration item you can now achieve the same via: except ban { mask 1.2.3.4; type maxperip; } Or even: except ban { mask { 1.2.3.4; 8.8.8.8; }; type maxperip; } etc. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-03-07 11:21 | djGrrr | New Issue | |
| 2007-03-07 11:35 | syzop | Note Added: 0013279 | |
| 2007-03-07 11:44 | djGrrr | Note Added: 0013280 | |
| 2007-03-07 12:12 | djGrrr | Note Edited: 0013280 | |
| 2007-03-24 10:53 | aquanight | Note Added: 0013328 | |
| 2007-03-24 11:16 | djGrrr | Note Added: 0013329 | |
| 2007-03-24 11:21 | djGrrr | Note Edited: 0013329 | |
| 2007-03-24 11:23 | djGrrr | Note Edited: 0013329 | |
| 2007-04-18 05:31 |
|
Status | new => acknowledged |
| 2007-04-18 05:33 |
|
Note Added: 0013507 | |
| 2007-04-18 07:32 | djGrrr | Note Added: 0013517 | |
| 2007-07-18 07:27 |
|
Relationship added | child of 0003454 |
| 2007-12-30 11:32 | syzop | Note Added: 0014945 | |
| 2007-12-30 11:32 | syzop | Relationship deleted | child of 0003454 |
| 2019-12-30 18:26 | syzop | Assigned To | => syzop |
| 2019-12-30 18:26 | syzop | Status | acknowledged => resolved |
| 2019-12-30 18:26 | syzop | Resolution | open => fixed |
| 2019-12-30 18:26 | syzop | Fixed in Version | => 5.0.1 |
| 2019-12-30 18:26 | syzop | Note Added: 0021180 |
