Anope channel modes
Moderator: Supporters
Anope channel modes
I'm testing out UnrealIRCd and Anope to see whether I'm willing to move away from IRCu/SRVX (SSL connections being the prime reason which IRCu doesn't support).
The one thing I've found so far that I do not like is that even when you set MLOCK on channels to enforce certain modes, these modes are not in effect when the channel is empty.
For instance, if I register #opers, and I set a MLOCK for +O in chanserv to only allow IRCops to join the channel, a regular user will still be able to join the channel if everyone has left it because Anope will not re-enforce those modes until AFTER the user has joined the channel.
Is there a way to have Anope enforce modes at all times? Even when no one is in the channel?
The one thing I've found so far that I do not like is that even when you set MLOCK on channels to enforce certain modes, these modes are not in effect when the channel is empty.
For instance, if I register #opers, and I set a MLOCK for +O in chanserv to only allow IRCops to join the channel, a regular user will still be able to join the channel if everyone has left it because Anope will not re-enforce those modes until AFTER the user has joined the channel.
Is there a way to have Anope enforce modes at all times? Even when no one is in the channel?
Well, the example of #opers was purely just an example. I was curious if this was how Anope worked as a whole, or if there was a way to force mode retention on registered channels even while the channel is empty.
Take for example a user who wants to create a secure channel by only allowing users to join the channel who are logged in via SSL. It's not that he does not welcome new users, it's that he simply doesn't want unsecure traffic. So he MLOCK's mode +z. Channel clears out at some point, and some random joe schmo connected unsecurely can join the channel and sit there. Sure, once a registered operator re-joins the channel, they can then kick the unsecured user, but is this really the best way?
Take for example a user who wants to create a secure channel by only allowing users to join the channel who are logged in via SSL. It's not that he does not welcome new users, it's that he simply doesn't want unsecure traffic. So he MLOCK's mode +z. Channel clears out at some point, and some random joe schmo connected unsecurely can join the channel and sit there. Sure, once a registered operator re-joins the channel, they can then kick the unsecured user, but is this really the best way?
Code: Select all
*** joining #habana [13:00]
*** mode: hall.ssp.sld.cu set [+ntSCG ]
*** mode: ChanServ set [+rz ]
*** topic: ChanServ set:
*** chan ( [email protected] ) join [13:00]
*** mode: chan set [+ao chan chan]
*** mode: chan set [+q corrosIve]
*** Modes: +CGnrStz Users: 2 Ops: 0 Away: 0
*** IRCops: (1) - corrosIve
Code: Select all
/cs register #habana password descript
/cs set #habana mlock +z
/part #habana
/join #habana
And everything works as should work.
Well, I wouldn't put it past me that I may be overlooking something.
So I did a test again.
(Connection 1) /chanserv register #test password description.
(Connection 1) /chanserv set #test mlock +z
(Connection 1) /part
(Connection 1) /disconnect
(Connection 1) (Rejoin on non-SSL port)
(Connection 1) /join #test
(Connection 1) * Now talking in #test
(Connection 1) * ChanServ sets mode: +rz
(Connection 1) * ChanServ changes topic to ''
(Connection 1) -ChanServ- This channel has been registered with ChanServ.
(Connection 1) * ChanServ sets mode: -ahoq [PP] [PP] [PP] [PP]
I am able to join despite being on an unsecured connection. So to make sure I am right in my assumptions on how this is working I form another concurrent non-secured connection to my IRCd.
(Form another non-SSL connection to IRCd)
(Connection 2) /join #test (bear in mind there IS a user in #test right now, thus the channel modes are now in place)
(Connection 2) #test unable to join channel (not using secure connection)
Now, I'll go back to the user who is sitting in #test.
(Connection 1) /part #test
(test is now empty, and I go back to my second concurrent connection who just a moment ago was not able to join the channel due to mode +z)
(Connection 2) /join #test
(Connection 2)* Now talking in #test
(Connection 2)* ChanServ sets mode: +rz
(Connection 2)* ChanServ changes topic to ''
(Connection 2)-ChanServ- This channel has been registered with ChanServ.
(Connection 2)* ChanServ sets mode: -ahoq test test test test
So I did a test again.
(Connection 1) /chanserv register #test password description.
(Connection 1) /chanserv set #test mlock +z
(Connection 1) /part
(Connection 1) /disconnect
(Connection 1) (Rejoin on non-SSL port)
(Connection 1) /join #test
(Connection 1) * Now talking in #test
(Connection 1) * ChanServ sets mode: +rz
(Connection 1) * ChanServ changes topic to ''
(Connection 1) -ChanServ- This channel has been registered with ChanServ.
(Connection 1) * ChanServ sets mode: -ahoq [PP] [PP] [PP] [PP]
I am able to join despite being on an unsecured connection. So to make sure I am right in my assumptions on how this is working I form another concurrent non-secured connection to my IRCd.
(Form another non-SSL connection to IRCd)
(Connection 2) /join #test (bear in mind there IS a user in #test right now, thus the channel modes are now in place)
(Connection 2) #test unable to join channel (not using secure connection)
Now, I'll go back to the user who is sitting in #test.
(Connection 1) /part #test
(test is now empty, and I go back to my second concurrent connection who just a moment ago was not able to join the channel due to mode +z)
(Connection 2) /join #test
(Connection 2)* Now talking in #test
(Connection 2)* ChanServ sets mode: +rz
(Connection 2)* ChanServ changes topic to ''
(Connection 2)-ChanServ- This channel has been registered with ChanServ.
(Connection 2)* ChanServ sets mode: -ahoq test test test test
Last edited by whoaboy on Wed Feb 15, 2006 10:10 pm, edited 1 time in total.
After you registered the channel, and set MLOCK +z, did you completely disconnect from the IRCd, reconnect on your non-SSL port, and try joining the channel while it is empty? I'm pretty sure you'll find that you are able to join the channel despite having MLOCK +z.JIVXor wrote:It works fine for me, I don't know how you're setting the MLOCK command. I just type:Code: Select all
*** joining #habana [13:00] *** mode: hall.ssp.sld.cu set [+ntSCG ] *** mode: ChanServ set [+rz ] *** topic: ChanServ set: *** chan ( [email protected] ) join [13:00] *** mode: chan set [+ao chan chan] *** mode: chan set [+q corrosIve] *** Modes: +CGnrStz Users: 2 Ops: 0 Away: 0 *** IRCops: (1) - corrosIve
Code: Select all
/cs register #habana password descript /cs set #habana mlock +z /part #habana /join #habana
And everything works as should work.
No, I did not disconnect from the IRCd. I believe that it doesn't matter if you disconnect or not of the server, anyway, you continue being a non sure connection. Anope doesn't deal with this(if you disconnect or not of the server). It only check if a new client joins the *empty*channel, and there completes the function of MLOCK.
But for your tranquility, now I tested it disconnecting from the IRCd, and it also worked.
Check out your services, your ULines.
Edit: I was thinking, if it could be a problem with the SSL connections topic, you should request help to the coders to see if they have an answer for this.
But for your tranquility, now I tested it disconnecting from the IRCd, and it also worked.
Check out your services, your ULines.
Edit: I was thinking, if it could be a problem with the SSL connections topic, you should request help to the coders to see if they have an answer for this.
Really? So even though you had an empty channel, the channel properly refused you from joining due to mode +z? Hrm, if that's the case, then perhaps there is some minor problem with my services setup.JIVXor wrote:No, I did not disconnect from the IRCd. I believe that it doesn't matter if you disconnect or not of the server, anyway, you continue being a non sure connection. Anope doesn't deal with this(if you disconnect or not of the server). It only check if a new client joins the *empty*channel, and there completes the function of MLOCK.
But for your tranquility, now I tested it disconnecting from the IRCd, and it also worked.
Check out your services, your ULines.
Edit: I was thinking, if it could be a problem with the SSL connections topic, you should request help to the coders to see if they have an answer for this.
Which version of Anope are you using? I'm running the current stable version, 1.6.4.
Damn man!! You must blame me until the sea left without water. I was telling you that everything were fine, and definitively was not working well. I'm able to join the channel and AFTER ChanServ sets mode +z. I begin to think that it's a negotiation problem between the services and the server, because anope sets the mode when the user joins, not BEFORE.
Hmm... not to my knowledge. My solution: you'll have to set a TLD block and specify some rules for that kind of users : chan's rules etc ... see
http://www.vulnscan.org/UnrealIRCd/unre ... l#tldblock
Hope that helps... and as fast as you can send a help request to coders/supporters to fix that problem.
Hmm... not to my knowledge. My solution: you'll have to set a TLD block and specify some rules for that kind of users : chan's rules etc ... see
http://www.vulnscan.org/UnrealIRCd/unre ... l#tldblock
Hope that helps... and as fast as you can send a help request to coders/supporters to fix that problem.
Lol, I believe you. I just wanted to be sure I understood we were on the same page.JIVXor wrote:Damn man!! You must blame me until the sea left without water. I was telling you that everything were fine, and definitively was not working well. I'm able to join the channel and AFTER ChanServ sets mode +z. I begin to think that it's a negotiation problem between the services and the server, because anope sets the mode when the user joins, not BEFORE.
Hmm... not to my knowledge. My solution: you'll have to set a TLD block and specify some rules for that kind of users : chan's rules etc ... see
http://www.vulnscan.org/UnrealIRCd/unre ... l#tldblock
Hope that helps... and as fast as you can send a help request to coders/supporters to fix that problem.
Yeah, I'll definitely be putting in a request to have this fixed. I was just curious about which version of Anope you were using, I thought that maybe they had fixed this and it was implemented in the Development version.