View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000771 | unreal | ircd | public | 2003-03-05 23:50 | 2023-05-22 12:30 |
Reporter | CoNfOuNd | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | N/A | OS | N/A | OS Version | N/A |
Product Version | 3.2-beta15 | ||||
Fixed in Version | 6.1.1-rc1 | ||||
Summary | 0000771: maxchannelsperuser class block | ||||
Description | would it be a possible idea to add maxchannelsperuser in the class block so you can stop certain classes mis-using it while allowing certain classes to well, join more channels.. | ||||
Additional Information | e.g. class clients { pingfreq 90; maxclients 500; maxchannelsperuser 15; sendq 100000; }; | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
has duplicate | 0002415 | closed | Move set::maxchannelsperuser to class::maxchannelsperuser |
|
Hm, well IMO it's a good idea. |
|
I would use the class block to class various TLD's.. class .ALL { pingfreq 90; maxclients 60; sendq 100000; }; class .COM { pingfreq 90; maxclients 40; sendq 200000; }; etc. so I would find it handy, as right now I would like to allow .BE connections to join extra channels, or certain bots to join more channels than users who are likely to flood etc. |
|
imho it is better suited to allow {} Reason is, class {} applies to servers as well, since servers don't join channels, what need is there for them to have such a feature? On the other hand, allow {} is specific for users. |
|
I second this feature request. My main intention for it is to allow certain bots to join more channels than the global limit. |
|
@aragon: opers can join unlimited chans I think, helpops should also be allowed to join unlimited chans. Because sometimes I dont want to give operator rights to a bot. |
|
is it just me, or does the history of this bug note not add up to the actuall replies etc? and i like the idea of this too |
|
Good idea if you ask me:) |
|
Bump. Do we need this? |
|
yes, need! |
|
I think we can throw this in the set::anti-flood block, so do it by security group. That way you can have different limits for known-users (like identified users) vs unknown-users. ...Even though most anti-flood settings are about rates and not limits (well max-concurrent-conversations is sorta in-between i guess) PS: Sorry for missing the 20th anniversary of this bug two weeks ago. |
|
Done in https://github.com/unrealircd/unrealircd/commit/3652940c2ca7c8000253e26cfb9fe5c1abaf97bd Also docs updated in https://www.unrealircd.org/docs/Anti-flood_settings#max-channels-per-user (and the set:: setting too) commit 3652940c2ca7c8000253e26cfb9fe5c1abaf97bd (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Fri May 19 21:40:33 2023 +0200 Add set::anti-flood::<secgroup>::max-channels-per-user setting to override the default set::max-channels-per-user (also called set::maxchannelsperuser). This way you can give known-users a higher max-channels-per-user, or even a special security group for trusted users (that you may already have given a more lax flood setting and lower lag-penalty etc. etc. so that fits in nicely) And yeah this also: * Makes it both in set and the anti-flood block accept both maxchannelsperuser and max-channels-per-user. * Removes old MAXCHANNELS= in 005, as we already have CHANLIMIT= This does not: * Re-announce the 005 CHANLIMIT= if someone transitions from a security group with a different max-channels-per-user. We don't do that for IRCOps either, and I think no IRCd does that actually... To be honest i wonder if sending the limit in 005 is useful at all, do client really track this and limit their GUI based on it?? Doubt it! |
|
Correction, this is now in set blocks for security groups (not in anti-flood): https://www.unrealircd.org/docs/Set_block#Set_block_for_a_security_group |
Date Modified | Username | Field | Change |
---|---|---|---|
2004-03-01 14:49 | aragon | Note Added: 0005263 | |
2004-03-02 00:28 | DukePyrolator | Note Added: 0005267 | |
2005-03-09 11:19 |
|
Relationship added | has duplicate 0002415 |
2005-03-09 18:09 | White_Magic | Note Added: 0009549 | |
2005-03-10 08:37 | vonitsanet | Note Added: 0009554 | |
2007-04-27 05:57 |
|
Note Added: 0013850 | |
2007-04-27 05:57 |
|
Status | new => feedback |
2007-04-27 06:17 | Bock | Note Added: 0013864 | |
2023-05-19 20:04 | syzop | Note Added: 0022866 | |
2023-05-19 20:04 | syzop | Assigned To | => syzop |
2023-05-19 20:04 | syzop | Status | feedback => assigned |
2023-05-19 20:05 | syzop | Note Edited: 0022866 | |
2023-05-20 14:35 | syzop | Status | assigned => resolved |
2023-05-20 14:35 | syzop | Resolution | open => fixed |
2023-05-20 14:35 | syzop | Fixed in Version | => 6.1.1-rc1 |
2023-05-20 14:35 | syzop | Note Added: 0022868 | |
2023-05-22 12:30 | syzop | Note Added: 0022882 |