11.03.06
My Sysadmin Nightmare
I was informed this week that my and Runtime Lab’s servers are going to be disconnected and sent to me. Which of course, would be disastrous since they’d be unplugged for days and I even when I get them, I can’t see paying hundreds of dollars a month to host a couple of old Sun pizza box workstations.
I spent yesterday trying to find a reasonably priced hosting service and I went with XServ Hosting. Their colocation rates for a Mac Mini start at $30/month and after talking to them for a while, they really seem to know their stuff. And for $15 a month they’ll hot-swap in a replacement mini if yours goes out for any reason.
After signing up with them I then had to bounce around trying to find a way to get them a Mini with enough RAM to be usable. I couldn’t find anyone who would install the RAM at a reasonable price (and I’d have paid Apple’s RAM prices) and ship it overnight. But they XServ Hosting guys are very cool and are going to take it to a local Mac shop to have memory installed.
I ended up ordering a Mac Mini from Amazon and had it overnighted to Xserv Hosting’s facility. UPS said no one was there to sign for it this morning, which is ridiculous at an operations with multiple security guards at every entrance. I put a call into them tonight, and I’m going to scream bloody murder if they don’t deliver it tomorrow. If it had been delivered, it would already but up and ready for me to start setting up.
In the meantime, I’ve been working on what it will take to transition everything to a Mac Mini from the two Sun boxes and a huge Sun Enterprise database server running Oracle (not ours). While it might sound crazy to use a Mac Mini as a server instead of an Xserv, the mini is going to be significantly faster than the Sun boxes (especially since it is dual core).
But the big nightmare has been getting our data out of Oracle and into a PostgreSQL database (why I selected PostgreSQL is a subject for another post). This is where I learned to really hate SQL script exports, as moving dates and blobs from one database to another is largely impossible. I knew this would eventually be a problem, so recently I created a binary export format and added it to MacSQL’s export and import capabilities. It’s been getting heavy testing, but all seems to work great. The only problems are with some types of data conversion. For example, many tables have columns that are defined as char(1) where the value is ‘N’ or ‘Y’. Unfortunately, there’s no easy (and quick) way to add support for specifying conversions like that, so I’m just keeping the old method and not switching to the boolean type PostgreSQL supports. For a future version of MacSQL, I think I’m going to add an embedded scripting language so users can hook little scripts in various places, like say a filter for each column during an import.
The files are endian-neutral, as I have to do the exports from Oracle while running MacSQL under Rosetta, but I do the imports when running natively so I can debug any problems that crop up. They also store the data in a binary format and know the names of the columns and a basic data type (int, bigint, float, decimal, date, time, datetime, blob, string). The file size is very reasonable and performance is great. Once MacSQL 3.1 ships, I plan to document the file format in case someone else wants to use it.
So aside from migrating all the data, I have to update our WebObjects projects (store, Issue Tracker, several frameworks) to use PostgreSQL. That was complicated by the fact that the store makes use of stored procedures. So that required learning how they work on PostgreSQL (I ended up using PL/Perl since I’ve been using Perl for about 13 years) and figuring out how to get the results from them in WebObjects since there seemed to be a special condition in WO for handing Oracle functions.
Thankfully, I’ve got the store running on my MacBook Pro with no problems. Right now I’ve got an AppleScript running that is importing all the Issue Tracker data into PostgreSQL, then I’ll be able to give it a try.
Other fun things I get to do are move our mail server (we are currently using Communigate Pro, but our license isn’t current so I’ll likely have to purchase an upgrade to get it to work on a Mac), setup perl with all the modules required for various scripts we use, setup and migrate our subversion repository, setup apache2 with php, mod_perl, ssl, and subversion support, switch our dns to a new provider (I’m testing out easydns.com right now), and then relentlessly test everything before my current servers get shutdown. The actual shutdown date is unknown, but I’m hopeful I have until Wednesday at the least.
I’m sure there are a ton more things I’m forgetting right now, but this post has run a lot longer than I intended. So I’ll just say that if I were doing this as a consulting gig for someone, I’d estimate two weeks worth of work. I’m going to do it in less than a week.
