View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001637 | unreal | ircd | public | 2004-03-09 00:58 | 2004-05-17 19:35 |
| Reporter | Stealth | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0001637: KILL suggestion | ||||
| Description | Allow the /kill-ing of channels. Working the same as any /kill, but will kill every user in the specified channel with the same reason, and one KILL notice. This would be usefull on networks whos services do not support channel kills. It would also make getting rid of a channel full of proxy clones easier. | ||||
| 3rd party modules | |||||
|
|
maybe it is also a good idea to allow "#channel" to be also a supported target in /gline /kline 'cos kills actually do not bother most of the clones as they start simply reconneting... |
|
|
Hate to say this, but it's done by services. And im not sure, but this may break the RFC. Try having a look at anope.org [anope services], they may be able to help you. [I believe its operserv/chankill or chanserv/chankill or something] |
|
|
I know the services do handle it, but alot of services that are in my category dont (win32). I have suggested it many times to the people who make the services, but it just never gets added. This will also be usefull for when the services crash or if a net simply does not have services. Usually when word gets out that the services are down, it opens up alot more possablilties for others to break rules (drone relays, channels full of proxy clones, spam bot control channels and such). *edit* Took out some typo's. =P edited on: 2004-03-11 15:51 |
|
|
This could also be used to remove users that are engaging in activities unacceptable by your network rules, and you want to empty the channel they are using to do it. You'd do: /kill #Blah We don't serve your kind here. |
|
|
Like war channels. Instead of going through a list of users and typing a kill/gline command for each, you can just kill/gline the whole channel. |
|
|
Ok, yeah, I see the point now. Particuarly for like, warez channels and the like (yes, some IRC networks _do_ restrict them :]) yeah... but... Im still not sure. syzop?? codemastr?? anyone? |
|
|
Another point of the suggestion, I believe Bugz is thinking of with Channel KILL: Let's say you use services to do a Channel Kill. You'd do something like: /operserv KillChan #Blah We don't serve your kind here. Then /operserv basically /NAMES the channel (or uses internal channel list) and /KILLs any user there. Let's say Joe, Bob, Nick were on that channel, you'd get: *** Notice - Received KILL message for [email protected] from services.mynet.net!OperServ (KillChan by SRA (We don't serve your kind here.) *** Notice - Received KILL message for [email protected] from services.mynet.net!OperServ (KillChan by SRA (We don't serve your kind here.) *** Notice - Received KILL message for [email protected] from services.mynet.net!OperServ (KillChan by SRA (We don't serve your kind here.) *** Notice - Client exiting ([email protected]) [Killed (OperServ (KillChan by SRA (We don't serv your kind here.)))] *** Notice - Client exiting ([email protected]) [Killed (OperServ (KillChan by SRA (We don't serv your kind here.)))] *** Notice - Client exiting ([email protected]) [Killed (OperServ (KillChan by SRA (We don't serv your kind here.)))] Three seperate KILL sever notices (and three seperate Client Exiting notices, but that can't be helped). With /kill #Blah support, you'd only get: *** Notice - Received KILL message for #Blah (<optionally list affected users>) from netadm.mynet.net!SRA (We don't serve your kind here.) *** Notice - Client exiting ([email protected]) [[irc.mynet.net] Local Kill by SRA (We don't serve your kind here.)] *** Notice - Client exiting ([email protected]) [[irc.mynet.net] Local Kill by SRA (We don't serve your kind here.)] *** Notice - Client exiting ([email protected]) [[irc.mynet.net] Local Kill by SRA (We don't serve your kind here.)] Only one KILL notice. If there's a potential for large channels it may be best to leave out <affected users> to stay within the RFC 512byte limit. (Optionally, for the QUIT and ERROR :Closing link messages use something like [irc.mynet.net] Channel #Blah Killed by SRA (We don't serve your kind here.)]) |
|
|
Yeah. Leave out userlists. Waaaay to big... [have seen channels with >500 people or something) |
|
|
No you wouldn't. We'd have to do it exactly the same way services does it or we would break the IRC protocol. For example, it would mean services wouldn't know the people were killed. We'd have to cycle the user list and kill each one individually just as services do. |
|
|
This would still be usefull for alot of reasons, one being that alot of services still dont have the option of killing a channel. This also can be easily scripted into any IRC client, but nothing says that all admins are scripters. It still would generally faster if the IRCd were to do this, and it can offere more protection to opers. |
|
|
It's actually very easy for a service to know who is affected by a Channel KILL if it is properly recognizing JOIN/PART/QUIT/NICK messages (which they do or else NickServ/ChanServ wouldn't work). Sure, no service daemon supports it, but that's because no IRCd has ever implemented. If the IRCd implements it, services could soon follow. And in case of old service daemons, well, that's what PROTOCTL is for isn't it? PROTOCTL TOKEN NICKv2 SJOIN SJOIN2 SJ3 KILLv2 The presence of KILLv2 could indicate support for this. If absent, the server would just send seperate KILLs for each user. However, I think what is suggested is that the Oper initiating the KILL only has to name a channel, and opers on the same server only receive one snotice for the KILL (other servers that see the seperate KILLs would probably just send seperate snotices as normal). It doesn't matter whether the server has to split the KILL or not, if it has to, it won't take any more time than the oper going through a channel of 400-odd users and KILLing each one, or a ChanServ/OperServ CHANKILL. |
|
|
Well yeah, we could use a PROTOCTL of course, just saying that it couldn't be entirely done the way you suggest. |
|
|
ive had a mirc addon (which i coded myself) that does this, althou u cant be on the channel, its a simple " /who " you set the " punishment " kill / Kline / Gline / Gzline /AKILL type in the mask into a input box " #channelname " all results are then " punished " to your settings, fully adjustable ban times and ban / kill reasons. i *could* make this NOT ban / kill the user using it, but i decided not too.. I coded it for the reason, should services die and there bots etc, this addon takes them out with accuracy, and becoz it uses the " /who " command, you can more than *just* channels..... nicknames, idents, realnames.. etc etc powerful & effective. |
|
|
I made the same thing. As I mentioned, it is easily scripted, but not all opers know how to script. Last I checked, the ability to modify an IRC client was NOT a requirement to run a server, and there are _lots_ of the peolple that dont know how to script running servers or have an OLine on one. I had my first OLine long before I was capable of such scripts. |
|
|
Problem with using /WHO like that is users with +i or a channel with +ps will not show in /WHO (unless opers can see them). If opers can't seem them, there will be survivors. |
|
|
umm aquanight, u need to be oper to use /kill ... so it will work... networks are not gonna allow non opers to use a command that will /kill all users on a channel, thus they must be an oper.... |
|
|
I wasn't sure if user +i and channel +ps was overriden by ALL opers or just service admins, or what. I suppose it _could_ (apparently it isn't as of now) be an option to limit the ability to see invisible/private/secret to certain opers. If that were to happen, then not all opers with kill power would be able to see everyone. My method of channel kills (if I ever had to do one): Join the channel with -x+H, observe the conversation, and if it's illegal, I highlight everone in the chanlist except myself, right-click, point to Control, click Kill (or maybe G-Line :P ), type in something interesting, click Ok and watch them disappear. edited on: 2004-03-15 13:20 |
|
|
/me calls syzop, or codemastr to check this thread out... Look, it may indeed be a good idea. But can it be done? |
|
|
not good idea to let services do the channel kill, Ãf you believe it a good feature the IRCd side should handle this thing. What you mean by break the RFC? RFC has to change for the demand. It's waste for services to send 500 kill commands to IRCd for killing a 500 user's channel. edited on: 2004-03-25 10:42 |
|
|
I only find one reason this *maybe* useful.... Java / non mirc clients can use the ircd to preform the channel kill without Needing services... isnt it better that the Ircd does it rather than Services? O_o |
|
|
Perhaps the RFC does change for demand... But standards are a part of life. One development team does not a standard make. "It's waste for services to send 500 kill commands to IRCd for killing a 500 user's channel." Erm. How? "isnt it better that the Ircd does it rather than Services? O_o" Hello, Services _is_ a type of server, as such. On a network, the kills will be propegated accross servers anyway. (services > server1 > etc) so if IRCd did it it would be etc < server1 > services (so they know whats happening) It would be nice for networks without services, but is it worth it... |
|
|
The idea is that we would not have to propagate it between servers. We'd just send a KILL #chan to each server rather than a KILL for each user. I think it's a good idea, just some of the technical details need to be worked out. |
|
|
Reason I didn't comment on this is that I'm not particulary keen on this, rather see it as a services job, but ah well.. If it is implemented, and you /kill (uh.. doesn't look very useful) or /*line (that sounds better) a channel I presume we want to exclude it from killing/glining/.. opers? Besides making the on-the-wire-data counter intuitive (like :oper kill #chan :blah doesn't kill everyone on #chan) one should also think about the nice 'local irc operators' problem this causes ;p. Of course you could decide to let every server kill his own clients (but that's also very counter-intuitive since normal kills work the opposite), or we could just ignore this and accept it as a fact of life that local opers suck. [blah] At first I also saw several issues with logging... Like you don't want an oper to silently kill/*line some of your friends (perhaps even by accident) by using this... But after some thoughts I remembered that the exit notice (+cF and in the log) would be clear enough on this.. with KILL the oper issueing the kill is clearly shown, and with gline you see the notice + immediately all the exit notices + you can always look afterwards via /stats and see who placed it blablabla... so that shouldn't be an issue. [/blah] |
|
|
Well I was sorta thinking kill everyone except the sender, and except U:lines (in case there are BotServ bots, etc.) I didn't really give much thought to opers. However, I kind of wonder whether it should have an exception for opers. I mean, then shouldn't G:lines have exceptions for opers too? This wouldn't actually be a "ban" it would just be a kill. So the oper can easily reconnect. I'd say just /globops opers should leave #dronebots, I'm killing everyone and that's enough. I'm just not sure I see the need to add an exception for opers. |
|
|
/kill #chan - kills all normal users in chan /kill +#chan - kills all voiced users and normal users /kill @#chan - kills all channel ops, halfops, voices and normal users /kill *#chan - kills every user in chan (except ulines) /kill u#chan - kills only unregistered users and the same syntax for kline/gline/zline/gzline/shun (and svskill?) i think this could be useful if a normal channel is flooded by bots and you dont want to kill/ban your regular users. |
|
|
Even if a network has services this is a nice alternative for if services go down and you need the chankill from operserv . But the mirc script, who is a dumb idea for glineing you get the masked host. |
|
|
Finaly someone come with positive idea on this thing, which i request a year ago. There is one more thing we also need, is the JOINMUTE feature that block any message from a user when he send it within 10 seconds(or any define value) after join channel. That good to block some spam bot or flooder |
|
|
Last night, right before I felt alseep I realized that this whole idea (kill #chan server<->server) is not possible due to desynch problems. I did my best to illustrate it here: http://www.vulnscan.org/tmp/chankill.png As you can see, someone issues a /kill #chan on server A, and at the same time someone joins from server D. This is not an impossible situation at all, in fact the timeframe is [highest lag in ms between two servers] and situations as these are quite common and possible with any channel, especially on a large botchan. Similar stuff applies to /*line #chan. |
|
|
what if ? KILL #<chan> <TS> |
|
|
bad bad idea imo... no, this whole thing is broken by design... I can understand people want to save the bandwith of 500 kills or *lines, but it's not something we should do at all costs... like if you count 200 bytes/gline-or-kill and you *line a 500 clones chan... then it's 500*200=100K.. that sucks.. I agree, but it's not that a server can't handle it and the end result (that the 500 clones are gone) is also quite good.... And, it already took the same amount of data (or more) for the clones to connect+join (although better spread), and the traffic itself is a fraction of the total traffic generated between server<->users etc (quit msgs, exitting client msgs, *line msg to client iself... all together probably X-1X Mb). |
|
|
Syzop, what if we somehow locked the channel down to prevent joins? eg "Cannot join #channel: KILL in progress by <oper>" until the # of users=0 Naturally, this would mean that it couldnt be overridden by opers... but it would stop the desynch problem, would it not? /me gets the feeling that this wont come in till after 3.2 if ever... |
|
|
Well it definately won't be coming until after 3.2, that's given. Unreal is in Release Candidate mode. That means you don't go adding new features, especially ones like this that have the potential to introduce many new bugs. |
|
|
Actually, w00t kinda has the right kind of idea, but the problem is: how will other servers know that the lockdown is in progress w/o receiving the KILL # ? The oper making the kill should be responsible for locking the channel down using a global ban (*!*@*) and removing all exceptions/ops/etc. |
|
|
I suggest closing this request. There are multiple services out there that can do this and they have proven to work just fine. If someone really wanted an ircd command too (which I disagree on) one could code a module. As for bandwith saving and all those crazy techniques.. it's simply unsafe, so just forget about it [see also my previous post]. |
|
|
I disagree with Syzop. The way this command could be implemented: Your current server recieves the KILL # command. It then sets +b *!*@* (or +i or something) in the current channel. Since having one kill notice will break it, send a notice telling the other opers that the channel has been killed. Preceed with the kill as normal The reason i suggested this in the first place, is because there are a lot of services that dont have this, and a lot of networks that dont yet have services. |
|
|
Bugz: having the server put a global ban is probably not a good idea. The oper doing the kill should do this (and also /kick|/sapart any other opers from the channel). Plus, with that, unless you deop everyone first, a chanop would have a chance to remove the ban, or put an exception. You would have to deop everyone in one fell swoop, which may require OperServ CLEAR. Here's how I would do it (assuming the channel is registered): 1) I would first ChanServ SUSPEND the channel to disable the ACL. 2) I would deop everyone (OperServ CLEAR) and remove all exceptions. 3) I would put a ban *!*@* in the channel (though SUSPEND should do this already) 4) I would then KILL away. 5) After a while (if I feel like it), I would UNSUSPEND the channel and probably /part it to let the IRCd delete it. Otherwise, I will change it to a FORBID. If the server did the ban+mass-deop, it would probably want to also not immediately destroy the channel. |
|
|
I'm closing it, sorry guys. A few of you are clearly missing general perspective. I don't blame any of you, you need to be able to think in a certain special way and have many years of experience in this. Remember, just 1 mistake and you got a desync, a 'ghost'! This is a very serious issue, not something unimportant. aquanight: right, you raise a few of the issues that exist and show how complex it is, there are several other issues too (just to name a few: operoverride, lock acknowledgements / lag, parts, incompatability, etc etc) it's simply not feasible. When we are at it, the original request on KILL #chan or *LINE #chan is still very possible (even in a module).. just not any of these "bandwidth save" attempts. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-09 00:58 | Stealth | New Issue | |
| 2004-03-09 05:49 | medice | Note Added: 0005376 | |
| 2004-03-10 19:01 | w00t | Note Added: 0005399 | |
| 2004-03-11 02:25 | Stealth | Note Added: 0005410 | |
| 2004-03-11 09:43 | aquanight | Note Added: 0005412 | |
| 2004-03-11 15:50 | Stealth | Note Added: 0005422 | |
| 2004-03-11 15:51 | Stealth | Note Edited: 0005410 | |
| 2004-03-11 15:51 | Stealth | Note Edited: 0005410 | |
| 2004-03-11 17:20 | w00t | Note Added: 0005425 | |
| 2004-03-11 18:31 | aquanight | Note Added: 0005435 | |
| 2004-03-11 19:25 | w00t | Note Added: 0005441 | |
| 2004-03-11 22:17 |
|
Note Added: 0005442 | |
| 2004-03-12 03:28 | Stealth | Note Added: 0005443 | |
| 2004-03-12 13:35 | aquanight | Note Added: 0005444 | |
| 2004-03-12 13:40 |
|
Note Added: 0005445 | |
| 2004-03-12 23:20 | White_Magic | Note Added: 0005451 | |
| 2004-03-13 02:33 | Stealth | Note Added: 0005452 | |
| 2004-03-13 21:22 | aquanight | Note Added: 0005459 | |
| 2004-03-14 00:03 | White_Magic | Note Added: 0005462 | |
| 2004-03-15 13:20 | aquanight | Note Added: 0005500 | |
| 2004-03-15 13:20 | aquanight | Note Edited: 0005500 | |
| 2004-03-24 17:22 | w00t | Note Added: 0005582 | |
| 2004-03-25 10:40 | auspice | Note Added: 0005583 | |
| 2004-03-25 10:42 | auspice | Note Edited: 0005583 | |
| 2004-03-25 10:49 | White_Magic | Note Added: 0005584 | |
| 2004-03-28 19:01 | w00t | Note Added: 0005641 | |
| 2004-03-28 19:17 |
|
Note Added: 0005644 | |
| 2004-03-28 22:06 | syzop | Note Added: 0005657 | |
| 2004-03-28 22:30 |
|
Note Added: 0005658 | |
| 2004-03-28 23:53 | DukePyrolator | Note Added: 0005660 | |
| 2004-03-29 03:06 | Static | Note Added: 0005663 | |
| 2004-03-29 08:57 | auspice | Note Added: 0005665 | |
| 2004-03-29 09:51 | syzop | Note Added: 0005666 | |
| 2004-03-29 10:33 | auspice | Note Added: 0005668 | |
| 2004-03-29 10:47 | syzop | Note Added: 0005669 | |
| 2004-03-29 18:34 | w00t | Note Added: 0005675 | |
| 2004-03-29 18:43 |
|
Note Added: 0005676 | |
| 2004-05-17 13:39 | aquanight | Note Added: 0006301 | |
| 2004-05-17 13:52 | syzop | Note Added: 0006302 | |
| 2004-05-17 18:54 | Stealth | Note Added: 0006303 | |
| 2004-05-17 19:12 | aquanight | Note Added: 0006304 | |
| 2004-05-17 19:35 | syzop | Status | new => closed |
| 2004-05-17 19:35 | syzop | Note Added: 0006305 |
