View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003109 | unreal | ircd | public | 2006-11-11 18:22 | 2007-01-22 06:54 |
| Reporter | avb | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| OS | Any | OS Version | Any | ||
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.7 | ||||
| Summary | 0003109: [Feature request] Usermode +F - exception from Fake Lag | ||||
| Description | Subj. Maybe it will be nice, if there such usermode, for example settable obly by services, or only by IRCOps with some additional oper flag? Like class::options::nofakelag but as usermode. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
ircops already don't get fake lag and for specific users, see FAKELAG_CONFIGURABLE in Changes (and include/config.h). We are not exactly keen on this. |
|
|
Ok, you already figured that out. No I'm not really planning to make this something easy and for services and all... It's already possible with some proper configuring, anyway. |
|
|
As syzop said, not needed. Fakelag exceptions are not something to be "played" with (and I know if this got added it will eventually end up getting "played" with, and that person will shortly regret it when the spambots hit), because you can open the door for mass-spam/flood/etc. See syzop's posts on 0002207 for why. |
|
|
honestly, i think your reasons for not implementing this user mode, as well as a lot of other extremely good feature requests are completely stupid (at least the ones you say to the public). IRCd's are not something that should be run by morons; not implementing a potentially great feature because you think n00bs will "play" with it, doesn't make sense, and any thing they do that screws up their ircd/network is there problem, not yours (simply add warnings to the docs, and don't give them support if they are doing stupid stuff that you have warned not to do). I think a user mode for fake lag excemption that can _ONLY_ be set via a U:Line would be very useful. this way you don't need a completely separate class (which is hard to manage for per ip or user restrictions). Making a usermode settable by u:lines would make it very easy to use a services module to let services admins+ be able to make special nicks (like certain bots) become flood exempt on identify; anyone who allows a spambot to be flood exempt would be a complete moron anyways. At least this way its much easier to control who can have this mode, rather than risking someone leaking the ip/port/password of a special IRCd or class used for flood exempting clients. Another way of doing this would be to simply add a user flag that is checked in the function that checks if it should add fake lag (i don't remember the function name off hand but i know its very simple). This way you don't need to add any user modes or make it easy for just anyone to mess with. It would make it be possible for someone to write a module their self, that could make someone flood exempt without having to modify the core ircd source. Then, anyone who wants to mess with it and has some programing experience, can, and you don't have to worry much about what stupid people will do with it; I think you have to agree with me on this; making it possible to do with a module would make everyone happy. |
|
|
Well, I disagree. It's not black and white. On one side, we don't intend to make the ircd moron-safe, that would be something you can never succeed. On the other side, we do sometimes make things require some extra configuring (like this), if they are dangerous. So it depends. We don't want tons of people enabling something by turning on a "turbo flag" (very possibly even accidently) and saying "ah much faster ircd now", and then blaming us when their ircd goes down and/or is screwed up. Some warnings like include/config.h etc is not a bad idea. If I would follow your logic, then Invisibility (umode +I) would still be implemented, that's not a road we want to follow. Yes, we realize owners are responsible for their own network. But we also have some responsibility on our own! On-topic: Guess why I left this bugreport open after my comment? You know how I work, if I really reject something the bugreport is immediately closed. I left it open because I didn't reject it for good... I wanted to see if the reporter had some better reasons as to why this would have to be done by services rather than something that can already be done right now in the conf. You provided some valid reasons, so I wouldn't mind having a services command (u-lines only) added that would tag a user as a "no lag" user. Since you said modules and all, I presume the same person (you?) that would write a module, could also submit a patch, so... If you or the reporter has time, feel free to make a patch. Create a new FLAG_SOMETHING in include/struct.h (be sure to use a free value), create a new command (new file in src/modules), be sure to check for ulines and simply set/unset the flag. Naturally the Makefile.in and makefile.win32 needs to be updated as well. As for the command-name I don't know... SVSLAGEXCTP? SVSNOLAG? Something like that. Attach it here (or mail me) and add a comment that you made the patch (and any remarks you might have), and I'll check it out and apply it if it's good. I'd personally like to work on other things. EDIT: Oh and don't forget to do the stuff in l_commands.c either ;p |
|
|
i am not extremly famliar with C, but i have made/modified a few modules for anope and am working on one for unreal. i am curious, the flags and umodes are longs... does this mean they have more than 32bits to work with? i know this is probably a stupid question, but i really need to know before i attempt to make a patch :) |
|
|
a long on x86 is 32bit but a long on x86_64 is 64bit. |
|
|
i have modified a copy of the 3.2.5 source, and have tested it, as well as a anope module to go with it. i will get the latests cvs and modify it later, but i need to know exactly how i should create the patch (ie. what command line options to diff) |
|
|
With CVS it's easy: cvs diff -u >filename.patch And then email (or attach here) the filename.patch, and also your m_somename.c file you created. |
|
|
patch provided for those who find this feature useful. Changes: + Added new global usermode F; + Added new operflag nofakelag (F); Only users with operflag "nofakelag" or netadmins or services admins can do mode +F on themselves (changing via SVSO also supported). Users with +F are excepted from fake lag. It works fine for me, but i think that more testing is required. |
|
|
small fix: usermode should be 'umode_allow_opers', but anyway it works fine in both patches because we check 'is user an oper?' in m_mode |
|
|
This patch doesn't really make sense for opers, as all global opers and up are fake lag exempt anyways, and fake lag for local ops is configurable with a define. It would be cool though for opers if you take away the fake lag exemption for all opers and restrict this to netadmins + opers with the nofakelag oper flag, allowing for a bit better oper restrictions. I was already in the process of making a patch; my way of doing it was to use a UMODE and a FLAG, this way, you can make a services module that would send a command like this (restricted to u:lines of course): SVSNOLAG + djGrrr This would give me the ability to set/unset +F as I please. Then, to remove that ability, you'd simple send another command to take it away: SVSNOLAG - djGrrr This way you could very easily have a services module allow specific users to get umode +F on identify, which would be especially useful for very trusted bots that you eant to be able to send fast. Maybe we can mix the ideas together to make an even better patch ? :D |
|
|
Why we need additional services command if +F/-F can be done via SVSO (add/remove operflag) and SVSMODE (add/remove mode)? :OperServ SVSO somenick +oF :OperServ SVS2MODE somenick +OF in other words, it is necessary to add operflag + oper usermode, or additional services command (SVSNOLAG) that not concerned with opers anyway, or both? or maybe some another thing? |
|
|
whats the point of a umode +F if its only for opers ? opers are already fake lag exempt... hence they don't need a special mode |
|
|
So you insist that exception from fake lag should available for any user, not necessarily for IRCOp? |
|
|
yes, that is the entire point of this report, but its something that only a u:line should be able to set, so that you could allow specific non-opers (usually bots) to be exempt from fake lag, via a services module |
|
|
Here it is, module m_svsnolag, that contains 2 commands: SVSNOLAG, and SVS2NOLAG - the difference between them - that SVS2NOLAG sends notice to user that he/she is not more lagged. Works fine for me, but i'm new to C, so good testing is required ;) Personally i'm don't like idea to except users from lag via services command, because all other ircd's that have such feature - do this via usermode, (and opers without that usermode usually not excepted too). |
|
|
Oops, sorry ;) i'm set wrong permissions when download file from my test server, so svsnolag.final.diff contains only 403 error message ;) svsnolag.final.2.diff - the correct diff |
|
|
Your latest patch is quite close to what I wanted/said. Just use flags, not operflags, since it's unrelated to opers. Pick a FLAGS_* value (I know I said FLAG_, I meant FLAGS_), like FLAGS_UNOCCUP4 is free (just rename it etc.. and use that value). Then check/use sptr->flags, instead of sptr->oflag. Then I could put it in, not for 3.2.6 (too late), but so it can be in Unreal 3.2.7 :) |
|
|
just added a patch to make it the way you wanted (using FLAGS_) :) hopefully now we can add this for 3.2.7 :) |
|
|
hmmm, i had to add the m_svsnolag.c file too because for some reason the cvs diff command won't include new files in the output, is there some switch for that ? |
|
|
Thanks a lot for the patch & all, I've applied it (almost) as-is to both 32* and 33*. I didn't test any of it, but it looked good :P. Changelog: - Added ability to enable "no fake lag" for a user through through services via the new commands SVSNOLAG/SVS2NOLAG (syntax: SVSNOLAG [+|-] NickName). Obviously, care should be taken when giving such access to a user since he/she will be able to flood at full speed and could possibly take down the entire IRCd (well, everyone on it). Suggested by avb, coded by djGrrr. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-11-11 18:22 | avb | New Issue | |
| 2006-11-11 18:24 | syzop | Note Added: 0012627 | |
| 2006-11-11 18:25 | syzop | Note Added: 0012628 | |
| 2006-11-12 01:33 | aquanight | Note Added: 0012630 | |
| 2006-11-12 11:14 | djGrrr | Note Added: 0012631 | |
| 2006-11-12 11:26 | djGrrr | Note Edited: 0012631 | |
| 2006-11-12 11:53 | syzop | Note Added: 0012632 | |
| 2006-11-12 11:55 | syzop | Note Edited: 0012632 | |
| 2006-11-14 09:09 | djGrrr | Note Added: 0012655 | |
| 2006-11-14 09:10 | djGrrr | Note Edited: 0012655 | |
| 2006-11-14 09:23 | penna | Note Added: 0012656 | |
| 2006-11-20 10:37 | djGrrr | Note Added: 0012688 | |
| 2006-11-20 10:42 | syzop | Note Added: 0012689 | |
| 2006-12-16 20:35 | avb | Note Added: 0012831 | |
| 2006-12-16 20:36 | avb | File Added: nofakelag.diff | |
| 2006-12-16 22:17 | avb | File Added: nofakelag.fix.diff | |
| 2006-12-16 22:19 | avb | Note Added: 0012832 | |
| 2006-12-17 05:32 | djGrrr | Note Added: 0012834 | |
| 2006-12-17 05:33 | djGrrr | Note Edited: 0012834 | |
| 2006-12-17 13:32 | avb | Note Added: 0012835 | |
| 2006-12-17 13:33 | avb | Note Edited: 0012835 | |
| 2006-12-17 14:01 | djGrrr | Note Added: 0012836 | |
| 2006-12-17 15:42 | avb | Note Added: 0012837 | |
| 2006-12-17 15:57 | djGrrr | Note Added: 0012838 | |
| 2006-12-17 19:43 | avb | Note Added: 0012839 | |
| 2006-12-17 19:43 | avb | File Added: svsnolag.final.diff | |
| 2006-12-17 19:45 | avb | File Added: svsnolag.final.2.diff | |
| 2006-12-17 19:47 | avb | Note Added: 0012840 | |
| 2006-12-18 06:33 | syzop | Note Added: 0012841 | |
| 2006-12-28 19:45 | djGrrr | File Added: svsnolag.patch | |
| 2006-12-28 19:46 | djGrrr | Note Added: 0012950 | |
| 2006-12-28 21:56 | djGrrr | File Added: m_svsnolag.c | |
| 2006-12-28 21:57 | djGrrr | Note Added: 0012952 | |
| 2007-01-22 06:54 | syzop | Status | new => resolved |
| 2007-01-22 06:54 | syzop | Fixed in Version | => 3.2.7 |
| 2007-01-22 06:54 | syzop | Resolution | open => fixed |
| 2007-01-22 06:54 | syzop | Assigned To | => syzop |
| 2007-01-22 06:54 | syzop | Note Added: 0013083 |
