Eggdrop deops itself to +voice status upon joining chan

[marvz]

Hello. My bot is in my group for chan access and its a SOP. I want the bot to deop itself and voice itself of staying on the chan as an op. The reason I don't add it to the AOP list or just a voice list is because as a SOP nobody can mess with it unless they have admin authority. So, I looked in the tcl archives and couldn't find anything that would do what I am interested in. I'm sure its an easy thing or that I might've overlooked something so I apologize in advance for the rookie requests Thanks in advance for any help or suggestions.

[willyw]

Hello. My bot is in my group for chan access and its a SOP. I want the bot to deop itself and voice itself of staying on the chan as an op. The reason I don't add it to the AOP list or just a voice list is because as a SOP nobody can mess with it unless they have admin authority. So, I looked in the tcl archives and couldn't find anything that would do what I am interested in. I'm sure its an easy thing or that I might've overlooked something so I apologize in advance for the rookie requests Thanks in advance for any help or suggestions.

I wonder if whatever network your bot is on, has some sort of Nickserv or Chanserv commands to do this.
I played with it briefly, on one network. I could "de"SOP myself, but once I had done so, I could not "re"SOP myself via a command (... I could leave and rejoin and regain SOP) If there as a NS or CS command to do it, I must have overlooked it. When I tried /mode #chan +a mynick , services simply told me that I was not the owner of the chan.

Curiously, I could not get a test bot to "de"SOP itself. It would de-op itself, with .tcl pushmode #chan -o botsnick though.
Maybe -a is a mode that the bot just doesn't understand... I really don't know.

This will be interesting to see what develops.

If I were you though, using a regular client program, and your own account I would experiment and see if you can do what you wish.
If you can discover commands that will do it with no eggdrop involved at all, that might be a step in the right direction.

[marvz]

I looked into having chanserv or nickserv doing it and for some reason they can only op the bot when it enters the chan. As far as having it deop the bot and adding the voice to it there wasn't anything I found on them that would perform these actions. I could easily just remove it from the SOP group and only have it voiced but that would leave it open to having other AOP's messing with it. As a SOP it won't allow anyone to perform any op functions to it.

I'm looking to have the bot perform this automatically because if one of the other admins isn't around the bot would sit in the chan as a SOP. I want to avoid this beause we had a split the other day and when users joined the chat that had the aol (no pun intended) flags it kept trying to op them even though the hadn't identified through nickserv so it was basically a war between the bot and chanserv.

SO at this point I'm drawing a blank as to how to get the bot to autimatically perform these actions to avoid that happening.

[willyw]

...
I'm looking to have the bot perform this automatically because if one of the other admins isn't around the bot would sit in the chan as a SOP. I want to avoid this beause we had a split the other day and when users joined the chat that had the aol (no pun intended) flags it kept trying to op them even though the hadn't identified through nickserv so it was basically a war between the bot and chanserv.

SO at this point I'm drawing a blank as to how to get the bot to autimatically perform these actions to avoid that happening.

If this is what you really want, then this is what should be addressed.
Not a work-around.
We might even figure out something that is better.

If a user has +a in the bot, then the bot will try to op them, when they join.

a - autoop (user is opped automatically upon joining the channel)

do .help whois to get a list of all the flags.

Thus, whether or not they have identified with Nickserv has no bearing.

What do you mean by a war between the bot and Chanserv though?
What exactly was happening?

It would seem like the bot would have op'd them, and that would be the end of it.

Sorry ... I'm not getting the whole picture.

[willyw]

I looked into having chanserv or nickserv doing it
...

What network?

[marvz]

This is what would happen since the user was not identified with nickserv:

23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com

That's what I meant by the bot fighting with chanserv. Since the user is not identified with nickserv chanserv doesn't allow the user to be oppped even though they're on the AOP/SOP list.

the network is irc.irc4lyf.com[/code]

[willyw]

This is what would happen since the user was not identified with nickserv:

23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
[23:00] #spf: mode change '+o ddog' by beersnob!beersnob@look-random-characters-D3DDEC9A.dsl.irvnca.pacbell.net
[23:00] #spf: mode change '-o ddog' by ChanServ!services@irc4lyf.com
...

That's what I meant by the bot fighting with chanserv.

ooohhh...
uuuuuuugly.

Since the user is not identified with nickserv chanserv doesn't allow the user to be oppped even though they're on the AOP/SOP list.

The network that I hang on mostly, doesn't do that. You can be op'd with no problems.
Thanks for explaining.

Would it be feasible, in your case, to not give your operators the a flag?
Give them just the o flag.
Then, your bot would not try to automatically op them upon joining.
Instead, they would have to send:

Code: Select all

/msg botnick op <password> [channel]

and then the bot would op them.

This way has the additional benefit of being much more secure too, as each op'ing would be password protected, unlike auto-op'ing.

[Luminous]

A large problem is, that afaik, eggdrop does not see a few modes as being "valid irc modes". I had this discussion with one of the developers not that long ago. So if you try to pushmode mode a or q, it won't work, although this is rumored to be fixed... sometime.

Also, I at one point tried to get my bot to do something similar. I tried a regex to catch the "botnick has joined #chan" message and make my bot send a mode- it wouldn't. It almost seems like we need a new "onchanjoin" bind to do this. We have the server evnt for when we first join a server and id, but afaik, there isn't a way to do so on channel join.

[willyw]

marvz:

Your network uses Unreal ircd, and probably Anope for services.
This is what I'm used to.

I suspect that the owner of your channel has set Secureops.
You can read about it a bit, with:

Code: Select all

/msg chanserv help set secureops

If that is what the channel owner really intends, then all well and good. That's what he wants....

But, it could be unnecessary or unintentional. If you are not sure, could it hurt to ask the owner if he cares to remove it?
If that Secureops setting is removed, I think the problem that you described would be gone.

If he wants to keep it, then I think your best option is to remove the +a flag from your ops in the bots internal user list, and let the ops op themselves via /msg, as described above. This is secure.


But, in the interest of your original post ( and again, I feel this is a work-around, and not the best solution), here is something for you to try:

Code: Select all

# Upon joining, bot will remove its own SOP, then remove the remaining OP.
# Bot will then VOICE itself

# There are two commands available (for +o users of the bot) - both are via /msg to the bot. 
#
# /msg <botnick> !resop
# will cause the bot to regain its SOP status
#
# /msg <botnick> !desop
# will cause the bot to remove its own SOP, then remove OP, and voice itself.  (Same as when it joined)
#
#


###  Config

# Set the channel
set desop_chan "#spf"

# Set the mask of the bot.  You may need to use wildcards.
# format is:    nick!user@host
set botmask "beersnob!beersnob@*.dsl.irvnca.pacbell.net"

### End Config



###   script

bind join - "$desop_chan $botmask" bot_desop_itself
bind msg o "!resop" resop
bind msg o "!desop" msg:bot_desop_itself



proc bot_desop_itself {nick uhost handle chan} { 
global botnick

	putserv "mode $chan -a $botnick"
	putserv "mode $chan -o $botnick"
	putserv "privmsg chanserv :voice $chan $botnick"
}


proc resop {nick uhost handle text} {

	set chan [lindex [split $text] 0]

	putserv "privmsg nickserv :logout"
	putserv "privmsg nickserv :identify rowbot"
}


proc msg:bot_desop_itself {nick uhost handle text} {
global desop_chan

	bot_desop_itself $nick $uhost $handle $desop_chan
}

I have not registered nicks, etc. on your network, to test this on your network. On another network, that uses Unreal and Anope, where I do have nicks for a test bot, I have tested it. It worked there.

Above, in the little Config area, the info for the #channel and bot's mask could already be correct for you. You should double check that though.

[marvz]

willyw:

The chan has secureops on it and that's why the issue arose. The owner chose to do it that way and well, its his chan and its his call.

I removed the a flag on the users and left them with the o flag and the bot still did the same thing. I thought it might've been something that would need a restart or something but, even though I restarted it, the bot kept doing it. Is there a certain time frame that the bot needs in order for it to implement the changes?

I'll try the script tonight and report back and let you know how it worked out. Thanks again for the help.

[willyw]

willyw:
...
I removed the a flag on the users and left them with the o flag and the bot still did the same thing. I thought it might've been something that would need a restart or something but, even though I restarted it, the bot kept doing it. Is there a certain time frame that the bot needs in order for it to implement the changes?

I believe the change is immediate.

Perhaps these users have(had) two +a flags - one global, and for the channel?
Do a .whois <handle> on a few of them, and have a look at both global flags, and channel flags.

Something is causing it - we just need to find it.....

I'll try the script tonight and report back and let you know how it worked out. Thanks again for the help.

You're welcome.

[blake]

If your bot is fighting with services on the channel telnet to your bot and type

.chanset #channelname -nodesynch

if your bot has aop/sop on the channel use a set option for it to identify to chanserv on joining the channel
then maybe a small script that will voice it first then deop it chances are that some of the basic access levels are disabled like deopme op deop

willyw if you would like access on a server that will allow you full access i have a test server that i run inbox me if you would like to use it

[marvz]

willyw:
...
I removed the a flag on the users and left them with the o flag and the bot still did the same thing. I thought it might've been something that would need a restart or something but, even though I restarted it, the bot kept doing it. Is there a certain time frame that the bot needs in order for it to implement the changes?

I believe the change is immediate.

Perhaps these users have(had) two +a flags - one global, and for the channel?
Do a .whois <handle> on a few of them, and have a look at both global flags, and channel flags.

Something is causing it - we just need to find it.....

I'll try the script tonight and report back and let you know how it worked out. Thanks again for the help.

You're welcome.

I couldn't do the .whois because I just deleted the users and added them all with the fh flags for the time being while I figured this out.

I used the script and its working like a charm! Thanks a lot! This will do unless there is a fix without the use of a tcl script.

[marvz]

If your bot is fighting with services on the channel telnet to your bot and type

.chanset #channelname -nodesynch

if your bot has aop/sop on the channel use a set option for it to identify to chanserv on joining the channel
then maybe a small script that will voice it first then deop it chances are that some of the basic access levels are disabled like deopme op deop

willyw if you would like access on a server that will allow you full access i have a test server that i run inbox me if you would like to use it

I will have to wait for a split or someone that is on the aop/sop lists to do the same mistake again to test that out. I don't have a way to test it without that happening. thanks for the info/suggestion and I'll keep it in mind should this occur again.

[marvz]

Ok, I've been using the script for a few weeks now and have seen some stuff happen.

For one, the setting of -nodesynch is in place. Yet, if the bot is opped for whatever reason it will start doing the same thing. It fights with chanserv over halfop/op the user in the chan if they haven't identified with nickserv. I removed the ay flags on the users but it is still doing it anytime that the user comes on without identifying.

Second, when the bot joins the chan it executes the script perfectly, but it doesn't add the +a flag to itself in order to protect itself from other op/sop users from "messing" with it (see example).

Code: Select all

[13:30] * beersnob was kicked by marvz (marvz)
[13:30] * beersnob (beersnob@look-random-characters-E150081B.com) has joined #spf
[13:30] * ChanServ sets mode: +ao beersnob beersnob
[13:30] * beersnob sets mode: -a beersnob
[13:30] * beersnob sets mode: -o beersnob
[13:30] * ChanServ sets mode: +v beersnob
[13:30] * marvz sets mode: +o beersnob
[13:30] * marvz sets mode: -o beersnob
[13:31] * marvz sets mode: -v beersnob
[13:31] * marvz sets mode: +v beersnob
[13:31] * marvz sets mode: +o beersnob
[13:31] * marvz sets mode: -o beersnob

I have SOP access on the chan but if the a mode would be set on the bot even I wouldn't be able to do anything to it but let it sit there in whatever it has set itself in (+v in this case).

So what do you guys make of this?