Anope IRC Services
Anope Support => 1.8.x/1.7.x Support (Read Only) => Topic started by: Trel on August 11, 2008, 03:58:57 AM
-
Is there any way for anyone who is opered (with correct flags) to be able to use superadmin regardless of what nick they're using?
-
Not without a module no. Additionally that's not a clever idea anyway. All it needs then is for one rogue server admin to add an O:Line for someone you can't trust with services access and bam.
-
Not without a module no. Additionally that's not a clever idea anyway. All it needs then is for one rogue server admin to add an O:Line for someone you can't trust with services access and bam.
That may be the case on a large server, but not on a single non-networked server with a small staff.
-
In that case why don't you just give all your opers ServicesRoot access? or appropriate access in OperServ? Would be far simpler.
-
better still, use http://modules.anope.org/viewmod.php?id=127 to make SET usable by Services Admins so you don't have to be root to use it. Then password protect it with http://modules.anope.org/viewmod.php?id=127 so only those that you want to have superadmin will have it. This solution conveniently works on almost all size networks.
-
In that case why don't you just give all your opers ServicesRoot access? or appropriate access in OperServ? Would be far simpler.
All of them DO have that access. The problem is if they're not using the exact nickname. Maybe as a halfway point, it could be done that somehow Anope looks at the OPER name and not the nickname. So in my case if I oper as Trel, and Trel is a name listed in services root, I would be able to use superadmin even if my nick was maybe Trel[Away]. Currently unless there's some setting wrong, my nick has to be Trel as well.
better still, use http://modules.anope.org/viewmod.php?id=127 to make SET usable by Services Admins so you don't have to be root to use it. Then password protect it with http://modules.anope.org/viewmod.php?id=127 so only those that you want to have superadmin will have it. This solution conveniently works on almost all size networks.
That probably still won't work unless it tracks the nick changes. As in User_A could be listed as a service admin, but if he changes his nick to User_A[Playing_Game], unless it tracks that (and it might, I'm not sure), it wouldn't work for the same reason I have the original problem.
(Also, you gave the same link twice)
-
It is anopes very foundation to identify users based on their nickname.. everything depends on nickserv.
If they use other nicks like ..[away], simply group those with their main nickname and anope will have no problem recognizing them.
Anope does track the last nickname identified, but to access services one needs to change his nick back to that nickname or a nick in the same nickgroup.
-
I guess grouping could work for this then. I'll see if that works for the people who were complaining of it :)
-
I guess grouping could work for this then. I'll see if that works for the people who were complaining of it :)
Groups WILL work as all nicks grouped have the exact same access as the display nick. So as long as the display nick is a Services Root and the user os opered and identified, it won't matter what grouped nick they use.
-
Unfortunately groups do not work.
---> set superadmin on right here
[13:28] Trel is now known as Trel[Away]
[13:28] Trel[Away] is now known as Trel
---> tried to op myself using /cs op #channel Trel
[13:28] —ChanServ— Access denied.
---> Set superadmin on again
---> tried to op myself using /cs op #channel Trel
[13:29]ChanServ sets mode: +o Trel
[13:29] Trel is now known as Trel[Away]
---> did /ns group Trel <password> (to make absolutely sure that I was in the group)
[13:29] —NickServ— You are already a member of the group of Trel.
-
superadmin is reset on nick changes...
superadmin is only meant as a temporary measure anyways since it makes the user founder of all channels... extremely abusive.
-
ah ok, wish it was an option, but I guess I'll have to make due.