Farewell, Node1 server.

Long live Node2.

Email has been on Google Apps for a couple weeks now with no problems, websites are all migrated to the new box, and nothing remains of any use on the old system. So, I just turned off and removed the Linode VM of the old server. Had to do it by month’s end or get dinged for another $75, so today was a good day to make that happen.

It’s always a bit of a downer, shutting off a server you worked so hard to build in the first place. But that’s the way of things.

I… may have only just a few minutes ago fixed a setting that prevented WordPress (and anything else PHP-based) on this new server from sending email.

Whoops. No comment notifications, for instance.

On the upside, if this is the worst mistake I make throughout this process then I’ve done pretty damned well.

If you can read this, then the website migration worked.

If I get email notification of any comments left for this post, then the email migration worked.

Okay, the email migration worked and I know it, because I got my daily Ello “inspirational” email newsletter today. Oh, Ello, when are you going to become something people other than froofy artsy-fartsy types will actually want to use?

Anyway. The email accounts are over on Google Apps now, and all but one of the hosted websites are migrated to the new Linode server. Hopefully I’ll have the last website and the NTP Pool configuration done in a couple of days and I will be able to turn off the old server. Huzzah!

It’s been a bit quiet here because this month I’ve started on a long-overdue project: Migrating the webserver to a… new webserver.

I’ll try to sum up.

The current webserver, aka Node1, is a legacy Linode system. It’s a 6GB virtual Linux server of a configuration they don’t even offer anymore, and it started life as an Ubuntu 10.04 LTS system. I upgraded it a while ago because 10.04 LTS went out of support… last year.

I’d like to get to the current PHP and MySQL versions, but that means either doing a lot of crazy backporting or doing an in-place upgrade. Considering I upgraded from 10.04 to 12.04 and had… issues… I don’t like the idea of performing yet another in-place major OS upgrade. So, I’ve purchased a second Linode system, a 4GB rig this time, and if I can get everything moved in the next two weeks I won’t need to pay the full monthly price for the old box and new box combined.

We’ll see how that goes.

Since the 4GB box costs less, I’m using the cost difference to fund getting email into some kind of hosted environment, because damn me but I’m tired of wrangling mail server configurations. Pay someone else to handle that headache? Yes please.

So that’s what I’m up to. Once this is complete, then I’ll be looking into a couple of creative projects. Honest!

I just completed an important and long-neglected task: The backups for my webserver have been reinvented and improved. This isn’t to say I haven’t been making backups previously, mind you! I had a (somewhat) cumbersome system of weekly tarballs and nightly rsync-over-ssh jobs going on. It was a bit I/O intensive, though. The opposite of efficiency.

The new system consists of:

• My home QNAP with the rsync app.
• My home firewall configured to route rsync traffic to the QNAP, but only from my webserver’s IP address. (There’s still a good username/password involved as well.)
• A group of organized, nested target directories on the QNAP.
• A string of rsync commands in a nightly cron job script which update the QNAP’s copy of each of the websites, each email account’s mail store, the website database dumps and a few key configuration directories out of /etc.

This setup should cut down on disk I/O on the webserver as well as nightly transfer rates. (I look forward to not seeing any more Sunday morning “hey, we noticed that your disk I/O is higher than normal” alert emails from the fine folks at Linode, if nothing else.) Note that this backup scheme is in addition to Linode’s nightly server snapshots for disaster recovery.

I configured the IP address for our home as a ‘hosts’ file entry, so when (inevitably) Frontier changes it on us, all I have to do to fix the backup job is to update that entry appropriately. (A near-future project: Detecting and alerting on communication errors in the backup script…)

Next up? A bunch of software upgrades and migrations, particularly now that the Gallery Project has shut down. D’oh!