UnrealIRCd Forums

Hello ---

I was just setting up UnRealIRCd and Anope services on Windows, storing the services database in MySql...and everything was going well, until I rebooted the server after installing a NTP client.

Even since, the passwords don't work.

I know what you're thinking...I fat fingered the passwords...well, I thought maybe, as well, except I run a keylogger and I went back and looked, and I was putting in the correct password. And since I am security conscience, guess what? I encrypted the passwords in the DB. -Sigh-

Ok, since this server isn't "in production", how do I wipe the databse and start over? I'd really like to know why this happened! Are the services time-dependant? Would installing the NTP client cause the passwords go into the toilet? I actually deactivated the Windows time service, because it was polling every 2 seconds, then installed Tardis. Help.

What error do you get when you attempt to identify?

If you rebooted without properly shutting down services, most likely is the database never got saved anyway.

When I change my Nick, I get the "Nick is protected message:

[07:57] -NickServ- This nickname is registered and protected. If it is your
-
[07:57] -NickServ- nick, type /msg NickServ IDENTIFY password. Otherwise,
-
[07:57] -NickServ- please choose a different nick.
-
[07:57] -NickServ- If you do not change within one minute, I will change your nick.
-


When I attempt to identify, it simply states:

[07:57] -NickServ- Password incorrect.

Although, you are correct I didn't shut it down properly, I just rebooted the entire box. However, there are database records for the 3 registered nicks in question.

Yeah, improperly shutting down like that can do that. I wouldn't be surprised if other data (nick settings, for example) was damaged as well.

If you're using anope, you can fix this without having to wipe the databases and start new ones. You'll need to temporarily use a nick that is not registered. Add it to the ServicesRoot directive in services.conf and also disable NSSecureAdmins (just put a # in front) while you're there (you might need to if any of the affected nicks are services (root) admins) and restart services. (I don't know if /operserv reload is enough but even if it was, you probably don't have SA access anyway since you can't identify.) When services are back up, /nick to that nick, make sure you are /oper'd, and register the nick which will then become an SRA. You can then use /nickserv SET nick PASSWORD newpass to reset the password of the affected nicknames (if they are grouped together you should only need to do this for one of them). After that you can /nickserv drop the temporary nick, remove it from ServicesRoot (re-enable NSSecureAdmins if appropriate) and restart (again, /operserv reload might be enough, this time you get to find out though ) services and you should then be able to identify to your nick.

If you can't /oper for some reason, you can try #'ing out NSStrictPrivileges which should allow you to use the service-admin syntax of /ns set without needing to /oper. It's not recommended that you leave this on, however .

Ok, great, that worked. If was far more elegant than the sledge-hammer approach I was suggesting. I was thinking along the same lines, but I was going to drop the registered nicks, this was was much better.

Ok, so this problem is fixed for now, but it begs the question, Is there a way to set up Anope so it writes to its DB earlier so that it won't get corrupted if there is a power-off emergency (such as loss of electrical power, BSOD, dumb admin just reboots the box)?

Yep.
So set to be more frequent if you want. Note that it may be affected by the ReadTimeout and TimeoutCheck settings as well.

Ok, I see that in the service.conf file, and it was set to the defaults (which are fine), yet the DB still corrupted when the box rebooted. Who knows what happened, but thanks for giving me a good solution for resetting the passwords, I appreciate your help.

I hate to revisit this issue, and I know no one wants to support anything on Windows, but I shut down my server nicely while I wired in a dedicated electrical circuit for my server cabinet, and after I powered the thing back up, not only had the NickServ database become corrupt again, the ChanServ also forgot some of its settings as well, notably channel modes and channel founders.

Ok, for your entertainment, here's the really annoying thing: this server has been rebooted at least one time in between, and it did NOT lose these settings, but this power down it did!

Now, I know how to replace all this information, but I shouldn't have to.

Does anyone have any recommendations on how to prevent this?

* I was thinking: write a script that shuts down the services nicely, dump the database, and start it all up again. Perhaps maybe that will give me something to restore the next time (in about 5 minutes) I have to do a Windows update that requires a reboot?

* Does this happen on *nix? NickServs are notorious for losing their settings, but is that just a Windows thing?

MrBugSir wrote:I hate to revisit this issue, and I know no one wants to support anything on Windows, but I shut down my server nicely while I wired in a dedicated electrical circuit for my server cabinet, and after I powered the thing back up, not only had the NickServ database become corrupt again, the ChanServ also forgot some of its settings as well, notably channel modes and channel founders.

Ok, for your entertainment, here's the really annoying thing: this server has been rebooted at least one time in between, and it did NOT lose these settings, but this power down it did!

Now, I know how to replace all this information, but I shouldn't have to.

Does anyone have any recommendations on how to prevent this?

* I was thinking: write a script that shuts down the services nicely, dump the database, and start it all up again. Perhaps maybe that will give me something to restore the next time (in about 5 minutes) I have to do a Windows update that requires a reboot?

* Does this happen on *nix? NickServs are notorious for losing their settings, but is that just a Windows thing?

use an SQL database... ?

Actually, I am using the MySql database...

MrBugSir wrote:Actually, I am using the MySql database...

I've just setup anope, restarted the services many times.. no data corruption at all.

but then again, i'm on nix.....

It's happened to me twice, although I have rebooted several times. I don't know what causes it. I am planning to migrate all this good stuff to a *nix box, but there's a small learning curve I must deal with it. Thanks for looking into this and doing some tests.

MrBugSir wrote:It's happened to me twice, although I have rebooted several times. I don't know what causes it. I am planning to migrate all this good stuff to a *nix box, but there's a small learning curve I must deal with it. Thanks for looking into this and doing some tests.

good linux primer.. http://www.floppix.com/labs.html (from one of my college teachers)

Cool, thanks Matridom. What flavor of *nix do you use? Um, I actually asked for *nix opinions on the Off Topic forum. I hope I don't get yelled at for asking.

Hm. If you're using a MySQL database there is the possibility of problems with MySQL. I don't know how forgiving Windows is of a service that takes a long time to close down when it's asked to stop [1]. I personally don't use MySQL with anope, so I don't really have this problem. You might want to try getting MySQL to commit whatever it needs to prior to shutting down, though it's probably getting to the point where one would have to do X0000 things before shutting down or things go splat... personally I hate that . It might just be easier to at least move the MySQL server to a seperate system that doesn't need to be rebooted a lot (Linux?).

[1] Though, I think Windows is more forgiving than Linux's default which is to fry the process if it doesn't exit within 5 seconds .