LocalOper & Oper Auto Join..

[Darvocet]

Wow I didnt ever notice that this forum was here, so hopefully someone can help me out!

I run IRCServices 5.0.41 with Unreal. My problem is that I have set my opers to auto join to lets say #Oper. This works great, I set the channel as +O and only opers can join. However, when a localoper first opers-up, he is also auto-joined to the channel. Which is what i would want to happen except that ChanServ then immediatly bans and kicks the user for joining.

I get around this with a well timed -O sajoin +O script, however the auto-join and ban are very annoying. Is there anyway to ensure that localopers are also allowed to join into a +O room? Or is there some setting I can use for ChanServ to prevent this from occuring?

Thanks for your help in advance. (PS. I have already read both UnrealIRCD and IRCServices Docs front to back, but do not recall ever reading anything similar)

---[EDIT]--- Speaking of the devil it just happened... So here is a paste of what i see.

Code: Select all

[3:09pm] Joins: LocalOper ([email protected]) [8 users]
[3:09pm] ChanServ sets mode: +b *[email protected].*
[3:09pm] LocalOper was kicked by ChanServ (You are not permitted to be on this channel.)

And.. the only flags I usually give a local-oper (though I am open to suggestions) are flags o & W.

[Solutech]

Sounds to me like you have secure ops set , restricted or somesuch mode . Look at what modes are set for the room . The only reason for chanserv to launch a kick ban will be if its told to .

[Ron2K]

In my experience, I've found that if you mlock +O (or +A) on to a channel, Services will kick/ban the first user to join the channel if that user isn't a oper/admin. (Undocumented feature?) It would therefore probably also kick/ban users that get into a +O/+A channel that it thinks shouldn't be there...

This is probably what's happening. The local server will recognise the locop as an oper and permit that user to join a +O channel. However, as far as I know, information about locops is not sent to other servers, so Services won't recognise that user as an operator. Services therefore thinks that the user is a non-oper trying to join an oper-only channel, and does the kick/ban treatment.

So far, my only experience of this has been a user being the first to join a channel that has +O/+A mlocked on - if the user didn't have the correct privileges, Services did a kick/ban on the user. (Before you ask Solutech, restricted mode was off.) I'll try it later with the scenario given in the first post in this thread and post my success (or lack of) next time I come visiting here.

Now, you're probably asking "what can be done to fix this?". The best way would be for UnrealIRCd to send locops information to other services. As far as I know, it doesn't do this. (I may be wrong about this however, if I am, someone please correct me.) Alternatively, as from Unreal3.2.2, you get "User is using modes +xzO" (or something similar) in the /WHOIS output, and it may be possible to get the Services developers to take advantage of it (though how they'd do it is beyond me).

(This has to be the longest response to a question that I've ever typed )

[Ron2K]

Right...

Background Information

I used the following server configuration:

Code: Select all

server1 <---> server2 <---> services

Both IRCd's were v3.2.2b, and the version of Services used was 5.0.44.

Test 1 - non-oper being the first to join a channel with +O mlocked on

First off, I had to register the channel. Obviously, I made sure that things like restricted mode were turned off. As soon as the non-oper attempted to join the channel, ChanServ kicked/banned the user.

Test 2 - locop being the first to join a channel with +O mlocked on

I gave my dummy client a local oper block on server 2, and successfully managed to oper up that client. However, an interesting thing was noticed: I have the option whereby OperServ broadcasts to the network about oper-ups turned on, so OperServ should have sent a notice when the locops gained locop status; no such message was sent. Indicative of things to come. Needless to say, the results here were the same for in the previous test - ChanServ kicked/banned the locop.

Test 3 - locop joining a channel with +O mlocked on

One would expect the result to be the same as the previous test, and indeed this was the case.

Test 4 - locop joining a channel with +O on, but not in the mlock

Same result. Surprise, surprise.

Test 5 - attempt to gain access via a netsplit

I moved the locop to server 1, then split the link between servers 1 and 2. Once done, the locop joined the channel (which was empty). Then, I relinked the two servers. As soon as the link was reestablished, ChanServ removed the locop from the channel. No surprise there

Test 6 - locop status between servers

I introduced dummy clients on both servers, and performed a /WHOIS on the locop. The clients on the server that the locop was on recognised the locop status, however the clients on the other server did not. This, coupled with the aforementioned broadcast message issue, suggests that UnrealIRCd does not send locop information between servers.

Conclusion

It seems like Services has an undocumented feature preventing users from sneaking into +O channels (by being the first to join, by netsplits, or otherwise). Undoubtedly, this would work for +A as well. However, since UnrealIRCd seemingly does not send locop information between servers (and hence to Services), Services will think that a locop joining a +O channel is unauthorized to do so, and therefore it's +O/+A protection feature will be triggered.

Based on this, your options are:

1. Turn +O off and instead control access to the channel via the restricted option. However, this might allow users to get in via netsplits.
2. Go to the UnrealIRCd bug tracker and suggest that UnrealIRCd send locop information between servers in future versions.
3. Go to the Services mailing list and suggest that this feature either be disabled, or can be user-configurable (on or off).

Should you choose one of the last two options, a link to this thread would be helpful, so that those attempting to rectify this can get a good idea what the problem is.

[aquanight]

Go to the UnrealIRCd bug tracker and suggest that UnrealIRCd send locop information between servers in future versions.

Actually that has already been done, but the bug has been marked private :/ .

[Syzop]

-edit- woops... wrong topic :) -/edit-

true, it's private, and it won't be done for 3.2.3 btw :)

[Darvocet]

Right...

Yup, you guys did perfect tests to duplicate the problem. I am currently just using a timer script to -O sajoin and then +O the channel. It's slightly annoying but since I only have a couple local ops it is tolerable.

I do greatly appreciate the responses though. Perhaps I will try the restricted channel and give that a shot.

Darvocet

[Plasma]

A suggestion, try adding your nickname to the access list of the channel if it is not on there already.

[Darvocet]

A suggestion, try adding your nickname to the access list of the channel if it is not on there already.

Hm well this is a good point, but I have tried this and been unable to do it properly. I accept the fact that it is probably user error and not server error though

Setting the access list like:

Code: Select all

[8:53am] -ChanServ- Access list for #Oper:
[8:53am] -ChanServ- Num Lev Nickname
[8:53am] -ChanServ- 1 50 AOP.Global Op
[8:53am] -ChanServ- 2 100 SOP.Network Admin
[8:53am] -ChanServ- 3 100 SOP.Network Admin
[8:53am] -ChanServ- 4 50 AOP.Global OP
[8:53am] -ChanServ- 5 40 HOP.Local Op
[8:53am] -ChanServ- 6 40 HOP.Local OP

This is basically how I have the channel ops arranged. Localops are HOP, Global/Network ops are AOP/SOP. However, +A doesn't like HOPs which is understandable, even though they ARE on the access list. And suprisingly the AOP.Global OP (Access 50) is not allowed correctly either. I did sit down and MANUALLY try to set access levels, and on 1 user in particular even when i set his access level to 100, it was still kickbanning him from the channel.

Thanks for you guys continued support.

Darvocet.