UnrealIRCd Forums

I have a couple of ideas, not so much suggestions, regarding UnrealIRCd.

1. Opermasks-
Purpose: better organization of irc staff, clears usermodes allowing for expansion through modules, etc.
Function:
/mode +o +o = Server Op (LocOp)
+o +O = GlobOp
+o +s = ServicesOp
+o +n = NetworkOp (new level)

+a +c = Co-Server Admin
+a +a = Server Admin
+a +s = Services Admin
+a +n = Network Admin

2. /redirect for Server admins (a-la PTlink IRCd, VERY useful. Will redirect clients on one server to another one so long as there are c/n lines for it.)

3. Config option to prevent your operators from leaving operator chan (without first setting -o and assuming there is an oper-auto-join channel set. NetAdmins would be excluded from this. This is good to ensure your operators stay in the oper chan for important news, etc on networks whos staff support this.)

4. chanmode +A extension: +A by itself allows any admin in. +A S allows services admins and netadmins, +A N allows only netadmins in.

5. Config option to have the ircd to never show a real users hostname shown on a forced rejoin if hostchange is set to force-rejoin. This is to save users from a possible exploit in anope's services when they deactivate their hostname and it clears x mode from them, and the rejoin is broadcasted to all users, compromising his hidden hostname.

6. config option to allow only nickserv-registered users to /oper [UNLESS services server is absent then this takes no effect regardless of setting]

Would like some feedback

Well thanks for your time and energy in pointing these things out. However, since Unreal3.2 is a release candidate we aren't taking anymore suggestions at this time. If we wish to proceed with a further version we'll take your suggests into consideration.

2. /redirect for Server admins (a-la PTlink IRCd, VERY useful. Will redirect clients on one server to another one so long as there are c/n lines for it.)

I'm currently working on a (free) module called 'JumpServer' [that uses RPL_REDIR etc]. No idea if it is what you ment, but ah well... you'll see..

/redirect would act in such a manner:

/redirect <server.to.send.them.to> - sends all clients on local server (the server the sender of the /redirect command is on) to the specified server. What else would be nice would be to allow this to be used globally, /redirect <server1> <server2> <port> - this sends all clients from server1 to server2 port <x>

Oh that sounds quite 'amazing'.

I'm just talking about RPL_REDIR (/RPL_BOUNCE) alike stuff here that only a few clients support (eg: mIRC, but afaik not irssi/kvirc/xchat/etc).

1. Opermasks-
Purpose: better organization of irc staff, clears usermodes allowing for expansion through modules, etc.
Function:
/mode +o +o = Server Op (LocOp)
+o +O = GlobOp
+o +s = ServicesOp
+o +n = NetworkOp (new level)

+a +c = Co-Server Admin
+a +a = Server Admin
+a +s = Services Admin
+a +n = Network Admin

I completely and totally disagree. In my mind, Unreal has far too many levels as it is. I don't want to see more added. I really see no reason for a "Network Op" as you suggest. What precisely makes a network op different from a regular oper?

2. /redirect for Server admins (a-la PTlink IRCd, VERY useful. Will redirect clients on one server to another one so long as there are c/n lines for it.)

Indeed, this just sends RPL_REDIR. This is a suggestion to the client, a client can (and many do) completely ignore this message. Others treat it as a suggestion and will prompt the user to switch rather than doing it automatically.

3. Config option to prevent your operators from leaving operator chan (without first setting -o and assuming there is an oper-auto-join channel set. NetAdmins would be excluded from this. This is good to ensure your operators stay in the oper chan for important news, etc on networks whos staff support this.)

Not possible. Of course, we can prevent the PART from succeeding. However, clients do not test if the PART succeeded. When you click the X, the window is closed. Therefore, you don't know you are still in the channel, but you really are (the PART was denied). As a result, all this feature would do is break things. Furthermore, if your network has a rule that says opers must be in the oper channel, and they break that rule, then perhaps you need new opers. And even more so, news broadcasts are why commands like /wallops, /globops, /locops, /adchat, /nachat, and /chatops exist. There really is no reason to force opers to be in a channel as IRC already has many means for important news messages to be broadcasted.

4. chanmode +A extension: +A by itself allows any admin in. +A S allows services admins and netadmins, +A N allows only netadmins in.

You can't simply go and add a parameter to an existing mode. It would break compatibility with many clients. But again, in my mind +A is unnecessary as well. If you tell your opers "You are not allowed to go to #admins" and they decide to go there anyway, then you need new opers.

5. Config option to have the ircd to never show a real users hostname shown on a forced rejoin if hostchange is set to force-rejoin. This is to save users from a possible exploit in anope's services when they deactivate their hostname and it clears x mode from them, and the rejoin is broadcasted to all users, compromising his hidden hostname.

Not really sure what you mean here. However, if the services are clearing +x, then perhaps that's the problem, not the fact that Unreal does what it is told.

6. config option to allow only nickserv-registered users to /oper [UNLESS services server is absent then this takes no effect regardless of setting]

That's a real judgement call. Some services require you to /oper before identifying, or you won't get access to operserv. But anyway, this could be implemented rather easily in a module.

3. Config option to prevent your operators from leaving operator chan (without first setting -o and assuming there is an oper-auto-join channel set. NetAdmins would be excluded from this. This is good to ensure your operators stay in the oper chan for important news, etc on networks whos staff support this.)

^^ not impossible. Implement a SAJOIN or SVSJOIN to bring them back in (sajoin makes the client aware it's in a new channel, the window will re-open even if it's closed.)

Network Operator , could be useless, but you could also give them permission to /rehash globally, use /chg* and /sapart + /sajoin. this is suggested because as I forgot to mention I think "services oper" and "services admin" status should be used to show their services status only.. serve no real purpose, and all the privelages that services admins have now shopuld be transferred to network oper. Network Operator IMO is more fitting for the privelages than "Services Admin".

^^ not impossible. Implement a SAJOIN or SVSJOIN to bring them back in (sajoin makes the client aware it's in a new channel, the window will re-open even if it's closed.)

That's a bad idea in my mind. Anyway, as I said, the real solution is teach your opers to follow the rules.

codemastr if opers were always thought to follow rules who was bothered to code SVSNOOP/NOOP features, why was /shun coded to not work on opers, why is there channelmode +A, why do they need to be force-joined when they first /oper, etc etc.. why not make it a configurable option ? it would be good for quite a few people and would be used more often than a lot of already existing commands. And it wouldn't be useless, but it's not like there's already plenty of useless stuff in Unreal.. who in the world needs 7 different ways for opers to communicate, like unreal already has:

ADCHAT
NACHAT
CHATOPS
GLOBOPS
WALLOPS
LOCOPS............

yet you're bothered by what I request

codemastr if opers were always thought to follow rules who was bothered to code SVSNOOP/NOOP features ?

Who bothered to code it? Not us, DALnet did.

The reason however wasn't to force them to follow the rules. The idea was, when you first link a server, you can't trust the opers (you just met them). Therefore, you confine them to only having access to their own servers. However, something like that doesn't apply to joining a channel. SVSNOOP prevents them from mass killing everyone. Your idea stops them from leaving a channel. If they mass kill people, hundreds of users may leave your network. If they refuse to remain in #opers, then no one is affected. The situations are not comparable.

Furthermore, the main reason SVSNOOP remains in Unreal is for services regulated olines. Some people, rather than have duplicate olines on each server, have opted to let services regulate all the olines for the network. As a result, they disable the olines of each server (by setting an SVSNOOP) and then they hand out the modes/operflags themselves.

Again, that doesn't have any comparison to your suggestion.

it has relevance in terms of usefulness, codemastr, sorry I forgot to mention that. Also sorry about the /shun bit as you can also manually define hosts to be exempt from it through except tkls so it's not just opers. ANYWAYS codemastr there isn't a matter of trust involved in this idea. But when you have the ircd preventing them from parting you don't have to be assed with getting everyone together. How about the idea of extending /sajoin to join all opers to a certain channel? /sajoin -opers #chan brings them all in when and only when absolutely needed. and since /sajoin is already present, there's little to no room to complain about it, all you're doing is forcing all the opers to join a single chan instead of a client (which is also less abusive because it's used on the opers vs. clients.)

Again though, I don't see the point of having them all in a channel. That's what all the various /*ops messages are for.

_zero wrote:who in the world needs 7 different ways for opers to communicate, like unreal already has:

ADCHAT
NACHAT
CHATOPS
GLOBOPS
WALLOPS
LOCOPS

Since you have different levels of operators, certain messages may only be pertinent to certain opers:
LOCOPS: Sends to operators on the same server. Used for SQUIT/link notices (*** LocOps - received SQUIT from ...) and can be used for other things.
WALLOPS: Sends to all users with +w. This includes nonopers. Useful for network broadcasts that you want users to "opt-in" to receive. (For mandatory reception, use OperServ GLOBAL.)
GLOBOPS: Sends to all users with +g which can only be set by opers, but it seems to remain set when you -o. Probably used for far SQUITs/links. Also used by services for reporting use of OperServ.
CHATOPS: Sends to all users with +o (and possibly +O), iow all opers. Useful for sending messages to all ops: (*** ChatOps - Going to superban that hacker... \ *** Notice - Permanent G-Line added for *@hacker.com etc.)
ADCHAT: Sends to all users with +A, iow all Admins. Useful for netmap-related things (e.g. *** AdChat - Adding the link block for our new hub.)
NACHAT: Sends to all users with +N. Obviously useless if you only have one netadmin in your whole network, but that's your problem .

codemastr wrote:

2. /redirect for Server admins (a-la PTlink IRCd, VERY useful. Will redirect clients on one server to another one so long as there are c/n lines for it.)

Indeed, this just sends RPL_REDIR. This is a suggestion to the client, a client can (and many do) completely ignore this message. Others treat it as a suggestion and will prompt the user to switch rather than doing it automatically.

I can still see quite a few uses for such a command. It would be nice to at least suggest a new server to people, especially when services are down and you can't GLOBAL everyone that a server has rejoined the network.

For what it's worth.. I've put my experimental JumpServer module online (well, a week ago), unfortunately I haven't received much feedback yet.
You can find it here.

*edit* oh.. I see there was already another thread about this where it was mentioned, ah well ;) */edit*.