11.07.06
Posted in Personal at 5:09 pm by Mark Lilback
[slug]sysadmin-nightmare-2[/slug]Well, we got a bit of a stay on having to move the servers, but I’m still working on it as fast as I can. I’ve got everything except perl modules installed on the new server.
I’ve already moved: the rtlabs subversion repository, www.rtlabs.com, and all our WebObjects applications. Our databases have been moved, too, but I’ve got a final import of the data from the Oracle server running right now.
I’m also in the process of setting up mail and mailing lists. Then I just need to move blogs.rtlabs.com and www.lilback.com. After that, a switch of dns and all should be good.
An interesting thing I never realized: network solutions’ domain registration also includes dns hosting. If you consider what a lot of places want to charge for dns hosting, that makes their registration fees pretty reasonable.
Permalink
11.03.06
Posted in Politics/Economics at 6:11 pm by Mark Lilback
I just got back from early voting, and once again I’m disgusted by the ballot. Fortunately it was still optical scan, not one of the disastrous touch-screen system. But I really can’t stand seeing the majority of the races only have one candidate listed and no spot for a write-in.
I’m sure some of my elected officials are doing a great job and that’s why no one runs against them. But I can’t believe that is true for all of them. My family has pretty good name recognition (I’ve never gone anywhere with my step-mother without running in to people who know her) and in a small town (approx 20,000) that is really all that is needed. I think I’ll register myself as a candidate for something in 2008. I don’t know if I’ll actually campaign, but there should at least be a challenger on the ballot for every race.
Permalink
Posted in Programming, Cocoa, WebObjects at 1:31 am by Mark Lilback
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.
Permalink
