View Issue Details

IDProjectCategoryView StatusLast Update
0003109unrealircdpublic2007-01-22 06:54
ReporteravbAssigned Tosyzop 
PrioritynormalSeverityminorReproducibilityN/A
Status resolvedResolutionfixed 
PlatformOSAnyOS VersionAny
Product Version3.2.6 
Target VersionFixed in Version3.2.7 
Summary0003109: [Feature request] Usermode +F - exception from Fake Lag
DescriptionSubj. 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.
TagsNo tags attached.
3rd party modules

Activities

syzop

2006-11-11 18:24

administrator   ~0012627

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.

syzop

2006-11-11 18:25

administrator   ~0012628

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.

aquanight

2006-11-12 01:33

reporter   ~0012630

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.

djGrrr

2006-11-12 11:14

reporter   ~0012631

Last edited: 2006-11-12 11:26

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.

syzop

2006-11-12 11:53

administrator   ~0012632

Last edited: 2006-11-12 11:55

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

djGrrr

2006-11-14 09:09

reporter   ~0012655

Last edited: 2006-11-14 09:10

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 :)

penna

2006-11-14 09:23

reporter   ~0012656

a long on x86 is 32bit but a long on x86_64 is 64bit.

djGrrr

2006-11-20 10:37

reporter   ~0012688

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)

syzop

2006-11-20 10:42

administrator   ~0012689

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.

avb

2006-12-16 20:35

reporter   ~0012831

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.

2006-12-16 20:36

 

nofakelag.diff (6,969 bytes)

2006-12-16 22:17

 

nofakelag.fix.diff (6,982 bytes)

avb

2006-12-16 22:19

reporter   ~0012832

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

djGrrr

2006-12-17 05:32

reporter   ~0012834

Last edited: 2006-12-17 05:33

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

avb

2006-12-17 13:32

reporter   ~0012835

Last edited: 2006-12-17 13:33

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?

djGrrr

2006-12-17 14:01

reporter   ~0012836

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

avb

2006-12-17 15:42

reporter   ~0012837

So you insist that exception from fake lag should available for any user, not necessarily for IRCOp?

djGrrr

2006-12-17 15:57

reporter   ~0012838

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

avb

2006-12-17 19:43

reporter   ~0012839

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).

2006-12-17 19:43

 

svsnolag.final.diff (327 bytes)

2006-12-17 19:45

 

svsnolag.final.2.diff (10,372 bytes)

avb

2006-12-17 19:47

reporter   ~0012840

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

syzop

2006-12-18 06:33

administrator   ~0012841

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 :)

2006-12-28 19:45

 

svsnolag.patch (7,301 bytes)

djGrrr

2006-12-28 19:46

reporter   ~0012950

just added a patch to make it the way you wanted (using FLAGS_) :)

hopefully now we can add this for 3.2.7 :)

2006-12-28 21:56

 

m_svsnolag.c (3,402 bytes)

djGrrr

2006-12-28 21:57

reporter   ~0012952

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 ?

syzop

2007-01-22 06:54

administrator   ~0013083

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.

Issue History

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