Anope IRC Services
Anope.org => Anope General => Topic started by: RealityGone on November 11, 2006, 11:41:16 PM
-
Currently on our irc network we have run into a situation in which we need to wipe our services databases. In order to resolve disputes in which users claim a channel/nick/etc was stolen from them we thought it would be helpfull to have a human readable form of the database so that we could at least confirm nicknames, emails, & hosts of the previous registrant.
I have searched google and only come up with tools to convert from one services database to another. Does anyone out there know of a tool or anything that could help with this?
-
You could use MySQL dumping to take backups of the databases, or you could make a module which exports the databases in some other format like XML.
-
making the db files readable by humans is a bad idea. If you can read them .. so can hackers. as far as your disputes go, I fail to see how if 1 user registers a nick/chan, another can claim it since a simple /nickserv info nick all or /chanserv info #chan all will display all you need to know about the nick/chan. If the second person claims a nick/chan, have them tell you what the email address that NickServ/ChanServ has on record, if it doesn't match .. it's likely that it's not their nick or channel.
Secondly, reading the db files directly won't tell you anything different than NickServ/ChanServ will tell you on IRC .. after all, the db's are where they get the information in the first place.
-
Thanks for that, I'll look into doing a MySQL dump & other anope modules.
Also, katsklaw, I know the databases show everything that chanserv, etc will show. But I want to have a backup human-readable copy of the databases. This way AFTER they are wiped & no information is in them at all we can check what it USED to be when there are disputes about who owns said nick/channel.
-
Other networks who have had a similar situation simply kept the old DB's running in -noexpire mode on a private server, opers could then easily check who should have what etc....
-
Originally posted by katsklaw
If the second person claims a nick/chan, have them tell you what the email address that NickServ/ChanServ has on record, if it doesn't match .. it's likely that it's not their nick or channel.
Thats all very well and good until the wrongful owner changes the email address which having taken over control they can do. Especially so in the case of Nick. The only way that could work is if you still had access in some way or another to the old DB's and checked against those instead.
[Edited on 12-11-2006 by Jobe1986
[Edited on 14-11-2006 by katsklaw]
-
Originally posted by Rob
Other networks who have had a similar situation simply kept the old DB's running in -noexpire mode on a private server, opers could then easily check who should have what etc....
That's so ingeniously simple. I can't believe I didn't think of it. That's awesome. Thanks a lot. :D
-
Originally posted by Jobe1986
Originally posted by katsklaw
If the second person claims a nick/chan, have them tell you what the email address that NickServ/ChanServ has on record, if it doesn't match .. it's likely that it's not their nick or channel.
Thats all very well and good until the wrongful owner changes the email address which having taken over control they can do. Especially so in the case of Nick. The only way that could work is if you still had access in some way or another to the old DB's and checked against those instead.
[Edited on 12-11-2006 by Jobe1986]
This is where searchable services logs (which conveniently log such events) are a helpful tool. It's not hard to make services logs viewable from the web and write a simple php file that can search for keywords such as *nick1*register*.
Searching services logs is more secure than allowing open human readable access to a database full of email address and passwords that anyone can read like a book.
-
I do agree with you that it is a security hazard. I will look to see how far back our services logs go and see if that is an option. But on our hosted space we can't save the logs forever.
However, the passwords would not be open like a book since they're encrypted. Also, not everyone would have access to this only the admins of our IRC server and once it's function was done it would be deleted.
Without the existence of services logs dating back to the beginning I don't see why this is such a terrible idea.
-
I usually don't reply several times in the same thread, because doing so tends to tell people how they should run their network. Which I'm not trying to do. I'm not going to go into all the "what if's" forever.
What I will do is share some insight with you. The largest IRC networks in the world seem to do just fine with non-human readable db files as well as perhaps mysql. They deal with hundreds of thousands of users every day. Hundreds of stolen nick/channel issues on a weekly basis. If they can do it .. so can you.
As a former DALnet Services Admin, back then they were the largest network in the world with about 140k user peak, I can tell you that you can do your job rather well with the tools already provided. I had less tools available for me than most IRCops do today on any network and if a few IRCops can hold a 100k user network together with 10% of the current available tools, there is no reason why a tiny (less than 10k users) network can't do the same.
I see no reason why the db files need to be human readable and no amount of "what if's" will change my mind.
My $0.02 worth.
-
Originally posted by katsklaw
I usually don't reply several times in the same thread, because doing so tends to tell people how they should run their network. Which I'm not trying to do. I'm not going to go into all the "what if's" forever.
What I will do is share some insight with you. The largest IRC networks in the world seem to do just fine with non-human readable db files as well as perhaps mysql. They deal with hundreds of thousands of users every day. Hundreds of stolen nick/channel issues on a weekly basis. If they can do it .. so can you.
As a former DALnet Services Admin, back then they were the largest network in the world with about 140k user peak, I can tell you that you can do your job rather well with the tools already provided. I had less tools available for me than most IRCops do today on any network and if a few IRCops can hold a 100k user network together with 10% of the current available tools, there is no reason why a tiny (less than 10k users) network can't do the same.
I see no reason why the db files need to be human readable and no amount of "what if's" will change my mind.
My $0.02 worth.
well said.
-
Wow, I see you disagree with me. Since you are a much better IRCop I had better listen to you and shut up. Right? That is what you want isn't it? I had gotten your responce, and I understood it.
If you don't want to go into all the what if's then don't. I didn't make you reply. I listened to your responce. You in fact ARE telling us how to run our network. I simply thought that this would be an EASY way to deal with it.
I'm not trying to convince you that this is the right way to do it. It is simply one way I thought of to do it. I don't need you trying to act all better than me because you were a DALnet admin. woohoo. whatever.
I realize it is POSSIBLE to do this without a human readable database, and the SQL dump will probably work just fine. But, there was really no reason for that last post except to make yourself feel bigger. I'm not trying to force the anope team to add a function that will write a human readable DB. I'm not trying to make the QA team do anything. I was just asking a general question.
-
Read the top of his post and you'll see why he wasn't enforcing his views or insight on you.
*Topic Locked*