Symphonious

We need to move our company wiki and JIRA instance to a server with more RAM and CPU to spare as they're pretty slow on the current overloaded virtual server, so we've been looking at a few different options. One that came up was using Amazon's EC2 and S3 services. We knew straight off that we didn't need the scalability they offered but getting some experience using them could be beneficial and we really didn't know anything about what they actually offered so it was worth a quick look.

Those familiar with EC2 won't be surprised to hear that we won't be going with the service for three reasons:

1. It's at least as expensive as the dedicated server we'd need.
2. The filesystem gets reset everytime the server reboots (S3 provides a REST API to store and retrieve data, not a filesystem)
3. The server gets a new IP address every time it reboots.

The cost only applies to us because we don't need scalability - our needs are really quite consistent so we're not avoiding purchasing large amounts of redundant hardware. We also have the ability to just pay a hosting company to set up one dedicated server for us instead of setting up our own server farm. If you were offering software as a service however, Amazon's offering is likely to save you a lot of money.

The filesystem resetting is a challenge for deploying most existing web applications, but not for software designed to run with S3. For instance, it's pretty easy to imagine a wiki implementation that uses S3 as it's "database" for storing data directly (probably with some local caching etc). Wikis are somewhat ideal for this because search is about the only query you perform on the data - otherwise you just retrieve pages by name which S3 is perfectly suited for. The fact that so many wikis use flat files instead of databases is an indication that it'd work pretty well. There would be a few hurdles but nothing insurmountable.

The dynamic IP however is a real pain. There are examples of using dynamic DNS to work around it but the lag in DNS updates seems like a problem to me. The better solution would of course be to have a load balancer in front of your EC2 instances - the load balancer would have a static IP address and the EC2 instances would just register with it when they start up. Unfortunately this means you have to have a server outside of EC2 to do the load balancing which means another hosting provider to work with and it just seems odd to have the load balancing server in a different data center to the rest of the servers. If Amazon added an option to build an EC2 machine that could only ever have one instance but had a guaranteed IP address it would be the perfect solution.

It's certainly something interesting to play with - I'll have to chase up a corporate credit card and see if I can get access to do some experimentation some time.

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.

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.

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.

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.