Symphonious

Living in a state of accord.

Category Archives: System Administration

Server Problems Here And With Some Ephox Sites

In case people are wondering, there was a major failure at our hosting provider which is causing down time. Both this server and the server that hosts the Ephox release blog, LiveWorks!, people.ephox.com and the internal Ephox wiki and JIRA installations have been affected. While (obviously) this site is back up, the Ephox sites didn't fair so well and are still down.

We'll get them back up and running as soon as possible. In the mean time, if you see any problems here please let me know. For a short while after the system came back WordPress switched to the default theme (but with all other settings in tact) so I really don't know what else might have been damaged.

UPDATE: The systems now appear to be fully restored without the need for us to manually restore backups.

Moving WordPress To A New URL

Every so often I want to play around with something new on my blog without trashing the public site. I have a local instance of WordPress that I do most of my playing around on but it generally doesn't have the some database configuration as symphonious.net so I can't be sure that things I develop there will work here.

It is however simple to completely clone a WordPress instance to a new URL – but I never remember precisely how, so this is a note to myself so that next time I'll remember.

  1. Copy over the WordPress files to the new location.
  2. Use WordPress Database Backup to dump the database – or you could use mysqldump.
  3. Reload the database content into the test database and adjust the wp-config.php file if needed.
  4. update wp_options set option_value='%TEST_SITE_URL%' where option_name like 'siteurl';

Step 4 is the bit I forget the details of – it lets you log in to your WordPress admin page instead of just being redirected back to the original blog. From there you can adjust the public URL in the options page and whatever other things you want to do.

Server Down-Time

I felt brave this evening and upgraded this server to run Debian Etch since it's been marked stable now. The upgrade was not without it's flaws and the server experienced some down time so if you found the site unavailable in the past few hours, now you know why.

I still have no idea what kernel I'm supposed to use with the fancy virtualization – I suspect that it doesn't really matter since the virtualization software seems to handle that level of things. Either way, the server rebooted and came back with everything working so I don't really care.

If you see any remaining problems let me know. I'll probably make an attempt to upgrade to PHP5 and fiddle with the SSL set up now that the most annoying bug in the world is fixed. There's probably a bunch of other stuff I can actually do now that the OS has entered the new millennium.

Most Annoying Bug Ever

I've just spent the past three or four hours setting up Apache, Subversion, all my browsers etc etc to use SSL connections and client certificates for authentication with my Debian stable server. I'm sure the mod_ssl devs already know what's coming here and are either chuckling gleefully or ripping their hair out right now. Anyway, the joke for all those who are mod_ssl devs, is that you can't get subversion to use client certificates with a Debian stable server because Debian stable has Apache 2.0.54, complete with everybody's favorite mod_ssl bug. It's fixed in Apache 2.2, but not in 2.0.

So, back to basic authentication over SSL. Sigh, I had that working about two hours ago.

Auto-Updating Systems via Subversion

One technique that I've started to use a lot around the different systems here is to store everything in subversion. It's a pretty commonly recommended technique and the nicest benefit is that if your changes don't do what you wanted you can easily roll back to an earlier version.

I've found though, that my favorite benefit is that it makes it easy to set up automatic updates for systems. Generally I just add an 'svn update' as the first step in running the appropriate system. When that's not suitable, a simple cron job does the job just as well. For our cruise control server we actually have a "config" project which builds every 30 minutes and all it does is update cruise control's config files.

When you're dealing with windows servers remote log-ins can be difficult and even UNIX servers are annoying to SSH into across the pacific so being able to edit files locally and have them deploy automatically is a real time saver.