View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002207||unreal||ircd||public||2004-12-01 15:36||2005-08-28 17:27|
|Fixed in Version||3.2.4|
|Summary||0002207: Fake Lag configurable by class ?|
Is it possible to get the fake lag thing (parse_lag blabla) configurable for a given class ?
At the moment, Opers can bypass it, or locops if compiled so, but wouldn't it be nicer if we could specify for a class if we want to avoid fake lag ?
i.e. a default class conf to "fake-lag on" and an option "fake-lag off" or whatever ...
I'm telling about that because we need special eggdrops to be able to "flood" because they are blocked when they send a lot of information to a lot of users. We are going to let them gain locop so they can flood, but according to me it would be better to be able to make them use a "flood enabled" class.
Thanks for reading ;)
|Tags||No tags attached.|
|3rd party modules|
||Can you add this to the ircd? This can be a great feature.|
I think the fakelag shoulg be a ./Config option, either to disable it, or change it...
parse.c: cptr->since += (1 + cmdbytes/90);
If this can be changed to a #define thing, then it would be easy to have the fake;ag configurable in ./Config
|And which part of that statement should be configurable? The /90? I doubt people would understand what that does.|
I don't think it's useful to make the formula configurable either.
Rather just a disable option or something (I too have trusted eggs which I want to flood but preferably not making an oper ;p). When we are at it, it is of course just a bit of privilege limitation. Because, if such a bot would still be hacked or freak out it could do things like join all channels, mass msg adds at full speed, part, msg everyone in the channel personally, etc... In short: mass damage, but yes... since it's not an oper it cannot (directly) kill/gline/etc :P. I'm just saying, that it's still something very dangerous and should always be carefully restricted/considered -- hence why I had the opinion for a long time this shouldn't be a config option, but since I do it myself for 3 years now and I see people asking it from time to time I'm beginning to reconsider that position :P.
Then again, wouldn't we regret it if this were added? All those idiots / floodproblems?
But..... then again, should that be a reason for not implementing an option?
I guess it depends. Because you cannot just say 'no, never' to that question, if people were perfect/smart/ethical we could still have things like +I, some /sendrawline cmd, and all those other abbusive/scary commands :P.
But I'm getting a bit off-topic ;).
Well ... if you have it configured at compile time or if you can enable it for a given class, maybe n00bz won't even find it. I was actually planning to use it for example on a password protected class also IP restricted.. but of course, people could misuse it right... disabling it server wide is something we won't do, and I hate having eggies gaining even restricted locops so ... that's why I suggested that.
And I also think it's irrelevant to change the formula, the way it is seems just OK...
Hm.. that's a good idea, making it a compile time option, and if enabled.. it will be possible to configure it by class.
That would get rid of all my concerns at least.
<windows_guy> HEY??? AND THEN I NEED TO COMPILE MY OWN VERSION?
guess what... we do that all the time on *NIX ;).
plus, that's a good n00b filter for windows users as well :)
Added in CVS.
- Added FAKELAG_CONFIGURABLE option in include/config.h, this enables an option called class::options::nofakelag, which disables "fake lag" for a certain class (that is: the artificial delay introduced by the ircd to prevent flooding is turned off, allowing the user to flood at full speed). IT'S USE IS DISCOURAGED UNLESS YOU REALLY KNOW WHAT YOU ARE DOING. Sorry, option is not in ./Config -advanced since I don't get autoconf working, but it's such a scary option that this might as well be a good idea to keep in config.h anyway. This feature has been suggested for several years (and refused), but the final suggestion (with implementation specific hints) came from Gilou in bug 0002207.
(or at least I hope so, because at the end I got:
cvs [commit aborted]: received broken pipe signal
cvs commit: saving log message in /tmp/cvsPVdril
|2004-12-01 15:36||Gilou||New Issue|
|2005-02-07 16:23||Homer||Note Added: 0009047|
|2005-02-15 14:22||Stealth||Note Added: 0009151|
||Note Added: 0009152|
|2005-02-15 17:43||syzop||Note Added: 0009154|
|2005-08-28 15:49||Gilou||Note Added: 0010410|
|2005-08-28 15:57||syzop||Note Added: 0010412|
|2005-08-28 17:27||syzop||Status||new => resolved|
|2005-08-28 17:27||syzop||Fixed in Version||=> 3.2.4|
|2005-08-28 17:27||syzop||Resolution||open => fixed|
|2005-08-28 17:27||syzop||Assigned To||=> syzop|
|2005-08-28 17:27||syzop||Note Added: 0010414|