AW: [IRCServices] Addition for the command line...

[Jonathan Morton]

>As far as I am informed, services does place an akill, but, an akill is not
>activated until the next user matching an autokill connects the network.
>Therefore, there is always enough time to erase an autokill, I think.
>
>If you think, that there might be an irc operator, who accidentally
>"removes" a
>services administrator by doing an autokill AND forcably killing this
>person, so that
>he/she has to reconnect, then I would say, that you ought to check, whom you
>are making
>an irc operator.
>
>And, additionally, if you move the akill.db somewhere else, services of
>course
>would start with an empty akill database, which, also would be a solution.

What happens if Services is started _after_ the admin is online?  Does it
not check who is online at the moment it starts up?  Simply moving the
akill.db is practically the same as deleting it, IMHO, as it can't be
merged in while services is running, and it can't be edited without being
connected to an IRC server with Services attached.

A workaround might be to move the akill.db to a small Linux box running
Services and an ircd, and connect using "localhost" to avoid the ISP-based
AKILL.  Then the db can be edited safely, and moved back to the main server
when all is well.  The admin _should_ have telnet access to their server
anyway, and it's easy to install a basic IRC client such as ircII on
something standard enough to run an ircd and Services, so it might not even
be necessary to bring down the server or services, provided the admin has
rights to _be_ the admin from localhost and no AKILL has been set on same.
Of course, if an AKILL has been set up on localhost and every other ISP
that the admin has rights from (and an account on) then you're screwed
anyway and will have to trash the akill.db (and preferably that lamer who
set up the bans in the first place).

Perhaps an editor for the databases, that is independant of the IRC
protocols, would be a good idea?  Since I assume the db's are in a
simple(?) flat-file format, it shouldn't be too hard to generate such an
editor, especially if source is culled from Services itself.  Such an
editor could even eventually be made capable of partially fixing corrupted
databases, for those advanced users who know what they're doing (yes, we've
had a corrupt database before, we lost 2/3rds of the nick registrations and
correspondingly about 1/2 the channels disappeared with them).

Also, it might be an idea to introduce "exception-bans" in the style of the
+e channel-mode and the e:line in ircd.conf.  Setting an Exception on the
admin staff (as a minimum) would make it impossible for such lame acivity
to happen in the first place.  It's also handy for if you have just _one_
un-lame regular user from a lamerz' ISP, then you can set an exception on
him and AKILL the rest of the ISP.  It's always annoying when you have a
lame ISP but one of your friends uses it.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi at cyberspace.org  (not for attachments)
uni-mail: j.d.morton at lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://chromatix.autistics.org/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE-
Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----



---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.