Well, that sucked

Last week was all kinds of fun. I had planned on refactoring a lot of code while Danny took a trip to meet his girlfriend in Honduras (she’s been volunteering there). But, just my luck, a mere twelve or so hours after he left, disaster struck.
For the past few years, Danny has hosted a number of sites on a Windows 2003 server hosted by ServerBeach. It’s gotten pretty slow with all the stuff we’ve had on it and we decided Linux would be a lot better for doing real hosting, so we decided about a month ago to switch to a Linux server. Unfortunately, at the time we were very busy with other stuff, so we didn’t get to it.
Well, fate took matters into its own hands. Just after Danny left, the Windows server totally ate it. The data was there, but booting was not happening. To make things just a little more fun, I knew practically nothing about how the server was set up, and all the accounts and passwords were under Danny’s name. Oh, and since phone calls to Honduras aren’t exactly cheap (and Danny had almost zero access to the internet), we could only communicate via text messages. Good times.
So I spent around four days 1) purchasing and setting up a new Linux server b) figuring out what data needed to be moved from the old Windows box and c) figuring out which sites were down and replicating them all on the new server. I’m not exactly an expert Windows or Linux sysadmin, so I was pretty much learning everything on the fly – while the clock was ticking since the sites were all down for a few days straight.
It was stressing and frustrating, since I didn’t accomplish what I had planned to, but on the plus side, we now have a brand-spanking new, way-faster Linux server up and running, which is nice.
Lessons learned:
1. As much as possible, have company accounts for servers and other services. Otherwise it’s a real pain if one person is unavailable.
2. Apparently, just installing automatic updates on W2K3 can bring a machine to it’s knees.
3. Debian is insanely easy to set up (apt-get rules!)
4. Writing code is a lot more satisfying than playing sysadmin.
Bonus Movable Type tip:
I decided to upgrade to a newer version of Movable Type, since our old Windows server was running 3.1. After importing the data from the database, the old passwords would not work. I tried looking up the encryption code MT uses and manually setting the fields in the DB, but no dice.
Then I tried resetting the passwords via MT itself. MT will mail you a new password if you know a user’s secret phrase. Luckily, that phrase is kept in plaintext in the DB, but unfortunately, I didn’t have sendmail or smtp working. So, I included the following line in my mt-config.cgi
MailTransfer debug
and then checked the Apache logs. Sure enough, the mail showed up in the logs – but MT wouldn’t accept the new generated passwords (even though it was changing the password field in the DB!).
I spent a good two hours banging my head against the wall trying to figure out what was going on. I finally just started looking around at the MT cgi scripts and trying various ones. Eventually I stumbled upon db2sql.cgi. Bingo! This fixed everything, which I don’t really understand, since my old DB was SQL, but whatever. Give it a shot if you’re having the same problem.