0003055: Server-side MLOCK support - UnrealIRCd Bug Tracker

(0012318)
White_Magic (reporter)
2006-09-05 07:07

this sounds like a perfect answer to the problem, rather than " killing " someone for racing the modes.

(0012349)
djGrrr (reporter)
2006-09-07 21:31

I really like this idea, and you even thought of everything (Channel owners (+q) would still be able to override the locked modes. So would servers (and services).)

And since it would be for 3.3.* it wouldn't cause any incompatibilities :)

(0012351)
tabrisnet (reporter)
2006-09-07 21:56

partly disagree. server/services only. don't allow channel owners to do so. if they are able to change the mlock in services, then they have the right to do so, and should not override.

(0012352)
djGrrr (reporter)
2006-09-07 22:36

i definetly don't agree with you there tabrisnet; what if services is down for some reason (its possible, and can sometimes be for hours at a time) ? then the channel owner can't even change mlocked modes....

(0012353)
tabrisnet (reporter)
2006-09-07 22:43

and if you have multiple channel "owners" (who have +q), but only one is founder, and only one can change the mlock, what happens there? We now have a way for a co-founder, or non-founder, to bypass something the founder wanted!

(0012354)
djGrrr (reporter)
2006-09-07 22:45

.... there comes the issue of who do u trust....

(0012355)
tabrisnet (reporter)
2006-09-07 22:55

Which is often the entire point of +Q. Not trusting the ops to not war with each other. Yes, it shouldn't happen. It does. It happens in real life (assuming anything on IRC is real).

(0012356)
djGrrr (reporter)
2006-09-07 23:03

ops maybe, but not channel owners (+q), which is what the thread was all about to begin with

(0012357)
Stealth (administrator)
2006-09-07 23:05

Also, I think when modes are locked on the channel, as with services, only the specified modes should be forced. To lock modes unset, simply specify the -mode as you would with services:

nt-k
Lock +nt, but do not allow +k
All other modes should be settable

(0012358)
tabrisnet (reporter)
2006-09-07 23:26

Hi. I'm tabris, owner of SurrealChat.net. I have about 200 users, half of which are under the age of 14. Maybe 10% are over 20.
Many of these kids are at the stage where mIRC is cool and scripting is leet. Writing or testing shitlist and war-scripts is a hobby of theirs. Now, to be honest, the founder should take care of this, and if they don't care then it's not an issue. But the fact remains, this does happen, it will happen, and it cannot be stopped short of closing/freezing the channel and removing all chanop status.

Meanwhile, it is not uncommon for +Q to be set by the founder to prevent such chanop wars, but still allowing problem users who are NOT on the channel access list to be removed via !kick.

Yes, You are assuming that users will either be smart or responsible. I'm not. I want a speedbump so 16 y/o Johnny doesn't run over any children in his new Jaguar going 40MPH in the parking lot of the nearby WalMart.

I no longer believe in hte goodness of others. At least not of little children when dealing with other little children.

(0012361)
tabrisnet (reporter)
2006-09-08 08:37

As to services being down... if services is down [long enough], NO ONE will have +q, as no one will be able to ask chanserv to op them.

(0012362)
syzop (administrator)
2006-09-08 08:47

IMO +q should be allowed to change it (well and opers with can_override of course, and SAMODE etc, but needless to say that)

But, anyway, as for when services are down.. that's a good point.
I think it should be made that, when services (server defined in set::services-server) are down for more than a certain period of time, then all server-side MLOCKing restrictions should be removed (remove the restriction itself), this can even be made configurable in the unrealircd.conf, and default to - for example - 5 minutes.

(0012363)
tabrisnet (reporter)
2006-09-08 09:01

Then it will need to be something that is also kept and synched when a netsplit is resolved (I probably said that badly, but the only term I can think of is 'netsplit healing'). Services won't know to reset it otherwise.

(0012364)
syzop (administrator)
2006-09-08 10:00

Yup (I understand).

(0012369)
brain4 (reporter)
2006-09-09 08:14

what happens if your server side mlock clashes with that of a services (uline) set mlock? Does the uline override the server side mode lock?

Not referring to +q users here of course u:lines are a seperate issue, u:lines should NEVER be allowed to 'lose' at any attempt to do *anything*.

(0012370)
syzop (administrator)
2006-09-09 09:06

Pretty obvious I think :P

(0012371)
JasonTik (reporter)
2006-09-09 12:03

Don't U:Lines override pretty much everything anyhow? (Including the current form of server side mlock (restrict-channel-modes, or w/e))

(0012372)
syzop (administrator)
2006-09-09 13:01

Correct.

(0012373)
Stealth (administrator)
2006-09-09 14:38

In the even services go down, I think servers should keep the settings... If they are there, then they are wanted, and if they were temp, then there should still be a +q around to undo it

(0012374)
djGrrr (reporter)
2006-09-09 17:40

I agree with Bugz, i don't really think it should be temp if services splits, could kind of defeat the purpose... and there would most likely still be a +q around

(0012375)
syzop (administrator)
2006-09-09 17:55

As I said, the time limit would be configurable.

Notes
(0012318) White_Magic (reporter) 2006-09-05 07:07	this sounds like a perfect answer to the problem, rather than " killing " someone for racing the modes.

(0012349) djGrrr (reporter) 2006-09-07 21:31	I really like this idea, and you even thought of everything (Channel owners (+q) would still be able to override the locked modes. So would servers (and services).) And since it would be for 3.3.* it wouldn't cause any incompatibilities :)

(0012351) tabrisnet (reporter) 2006-09-07 21:56	partly disagree. server/services only. don't allow channel owners to do so. if they are able to change the mlock in services, then they have the right to do so, and should not override.

(0012352) djGrrr (reporter) 2006-09-07 22:36	i definetly don't agree with you there tabrisnet; what if services is down for some reason (its possible, and can sometimes be for hours at a time) ? then the channel owner can't even change mlocked modes....

(0012353) tabrisnet (reporter) 2006-09-07 22:43	and if you have multiple channel "owners" (who have +q), but only one is founder, and only one can change the mlock, what happens there? We now have a way for a co-founder, or non-founder, to bypass something the founder wanted!

(0012354) djGrrr (reporter) 2006-09-07 22:45	.... there comes the issue of who do u trust....

(0012355) tabrisnet (reporter) 2006-09-07 22:55	Which is often the entire point of +Q. Not trusting the ops to not war with each other. Yes, it shouldn't happen. It does. It happens in real life (assuming anything on IRC is real).

(0012356) djGrrr (reporter) 2006-09-07 23:03	ops maybe, but not channel owners (+q), which is what the thread was all about to begin with

(0012357) Stealth (administrator) 2006-09-07 23:05	Also, I think when modes are locked on the channel, as with services, only the specified modes should be forced. To lock modes unset, simply specify the -mode as you would with services: nt-k Lock +nt, but do not allow +k All other modes should be settable

(0012358) tabrisnet (reporter) 2006-09-07 23:26	Hi. I'm tabris, owner of SurrealChat.net. I have about 200 users, half of which are under the age of 14. Maybe 10% are over 20. Many of these kids are at the stage where mIRC is cool and scripting is leet. Writing or testing shitlist and war-scripts is a hobby of theirs. Now, to be honest, the founder should take care of this, and if they don't care then it's not an issue. But the fact remains, this does happen, it will happen, and it cannot be stopped short of closing/freezing the channel and removing all chanop status. Meanwhile, it is not uncommon for +Q to be set by the founder to prevent such chanop wars, but still allowing problem users who are NOT on the channel access list to be removed via !kick. Yes, You are assuming that users will either be smart or responsible. I'm not. I want a speedbump so 16 y/o Johnny doesn't run over any children in his new Jaguar going 40MPH in the parking lot of the nearby WalMart. I no longer believe in hte goodness of others. At least not of little children when dealing with other little children.

(0012361) tabrisnet (reporter) 2006-09-08 08:37	As to services being down... if services is down [long enough], NO ONE will have +q, as no one will be able to ask chanserv to op them.

(0012362) syzop (administrator) 2006-09-08 08:47	IMO +q should be allowed to change it (well and opers with can_override of course, and SAMODE etc, but needless to say that) But, anyway, as for when services are down.. that's a good point. I think it should be made that, when services (server defined in set::services-server) are down for more than a certain period of time, then all server-side MLOCKing restrictions should be removed (remove the restriction itself), this can even be made configurable in the unrealircd.conf, and default to - for example - 5 minutes.

(0012363) tabrisnet (reporter) 2006-09-08 09:01	Then it will need to be something that is also kept and synched when a netsplit is resolved (I probably said that badly, but the only term I can think of is 'netsplit healing'). Services won't know to reset it otherwise.

(0012364) syzop (administrator) 2006-09-08 10:00	Yup (I understand).

(0012369) brain4 (reporter) 2006-09-09 08:14	what happens if your server side mlock clashes with that of a services (uline) set mlock? Does the uline override the server side mode lock? Not referring to +q users here of course u:lines are a seperate issue, u:lines should NEVER be allowed to 'lose' at any attempt to do anything.

(0012370) syzop (administrator) 2006-09-09 09:06	Pretty obvious I think :P

(0012371) JasonTik (reporter) 2006-09-09 12:03	Don't U:Lines override pretty much everything anyhow? (Including the current form of server side mlock (restrict-channel-modes, or w/e))

(0012372) syzop (administrator) 2006-09-09 13:01	Correct.

(0012373) Stealth (administrator) 2006-09-09 14:38	In the even services go down, I think servers should keep the settings... If they are there, then they are wanted, and if they were temp, then there should still be a +q around to undo it

(0012374) djGrrr (reporter) 2006-09-09 17:40	I agree with Bugz, i don't really think it should be temp if services splits, could kind of defeat the purpose... and there would most likely still be a +q around

(0012375) syzop (administrator) 2006-09-09 17:55	As I said, the time limit would be configurable.

Issue History
Date Modified	Username	Field	Change
2006-09-05 06:43	syzop	New Issue
2006-09-05 07:07	White_Magic	Note Added: 0012318
2006-09-05 12:01	tabrisnet	Issue Monitored: tabrisnet
2006-09-07 21:31	djGrrr	Note Added: 0012349
2006-09-07 21:56	tabrisnet	Note Added: 0012351
2006-09-07 22:36	djGrrr	Note Added: 0012352
2006-09-07 22:43	tabrisnet	Note Added: 0012353
2006-09-07 22:45	djGrrr	Note Added: 0012354
2006-09-07 22:55	tabrisnet	Note Added: 0012355
2006-09-07 23:03	djGrrr	Note Added: 0012356
2006-09-07 23:05	Stealth	Note Added: 0012357
2006-09-07 23:26	tabrisnet	Note Added: 0012358
2006-09-08 08:37	tabrisnet	Note Added: 0012361
2006-09-08 08:47	syzop	Note Added: 0012362
2006-09-08 09:01	tabrisnet	Note Added: 0012363
2006-09-08 10:00	syzop	Note Added: 0012364
2006-09-09 06:21	syzop	Relationship added	child of 0003049
2006-09-09 08:14	brain4	Note Added: 0012369
2006-09-09 09:06	syzop	Note Added: 0012370
2006-09-09 12:03	JasonTik	Note Added: 0012371
2006-09-09 13:01	syzop	Note Added: 0012372
2006-09-09 14:38	Stealth	Note Added: 0012373
2006-09-09 17:40	djGrrr	Note Added: 0012374
2006-09-09 17:55	syzop	Note Added: 0012375
2007-04-27 03:22	stskeeps	Status	new => acknowledged
2010-07-14 21:25	syzop	Relationship added	parent of 0003915