Lawrence Lessig declares that the two camps of the Net Neutrality debate are those who built the Net vs. those who never got it. I don't think that's accurate, the telecomms and cable networks have been a pretty key part of the Net. (Found via Rafe, btw).

I think the real division here is content providers vs. pipe owners, and the attempt to do away with network neutrality is essentially a coup attempt by the people who own the pipes.

People use the Net for the content, so that's where the value is. The pipes are just a commodity, which are expected to simply deliver the content. Selling a commodity service means competing on price, which means low margins.

My first experience with the RedHat Network reminds me of a major limitation of commercial platforms that doesn't get much press. You actually get less than you do with free alternatives like apt-get and yum.

I'm setting up a new hosting infrastructure for a client which, among other things, involves moving from the free Fedora to commercial Redhat Linux. Although I've managed Redhat machines before, this is my first time using the Redhat Network (RHN) for installing and updating software.

In the past I've used apt-get on Debian, and yum on Fedora, and found them a godsend. Set up properly, it takes minimal effort to keep multiple systems up to date and consistent, whereas when I've had to go the "by-hand" route, machines invariably ended up with older versions of software. It's just too hard to keep up with all the various packages installed on various servers, not to mention the headache of chasing down various dependencies and resolving conflicts when you do upgrade or install a new package.

I like to have the Tomcat manager webapp installed on each instance, so I can play with the webapps, and see how many active sessions there are. To do this, make a file called manager.xml file in the webapps directory of your Tomcat instance. One I like to use is this:

    <Context path="/manager"
        docBase="/usr/local/tomcat/server/webapps/manager"
        debug="0"
        privileged="true">

    <ResourceLink name="users"
            global="UserDatabase"
            type="org.apache.catalina.UserDatabase"/>

    <Valve className="org.apache.catalina.valves.RemoteAddrValve"

Here's a brief step by step guide to running more than one instance of Tomcat on a single machine.

Step 1: Install the Tomcat files

Download Tomcat 4.1 or 5.5, and unzip it into an appropriate directory. I usually put it in /usr/local, so it ends up in a directory called /usr/local/apache-tomcat-5.5.17 (5.5.17 being the current version as of this writing), and make a symlink named /usr/local/tomcat to that directory. When later versions come out, I can unzip them and relink, leaving the older version in case things don't work out (which rarely if ever happens, but I'm paranoid).

I've started tinkering with puppet for configuration management. It's a far more flexible and extensible tool than cfengine, so it looks like the best way to go.

It's main drawback is lack of maturity. The documentation is fair, there's a decent reference, but there are only two examples of configuration files that I've seen so far, and neither one is very complex. It's also fairly buggy, although the author is quick to respond when told about specific problems.

I'll most likely be using Puppet to build a J2EE infrastructure based on Red Hat. I'd like to be able to contribute bug fixes, but I'm not sure how many spare cycles I'll have, given that I don't know Ruby. But hopefully I can at least contribute some example files, and some manifests related to Tomcat and general J2EE web application deployments.

There are a lot of things you can do to make sure that when disaster strikes, you can get back online. Even in environments where you don't have automatic failover, you can take some basic steps so that when you get the alert or the phone call, you can bring things back online.

Let's say you have a single server running a web application with a local database. However, you need to have a second server available. Maybe it's doing something else normally, maybe it's in a less than ideal location, like in your office at the end of a slower Net connection, but as long as you can fire up your application, repoint DNS, and be online, it'll do in a pinch.

First, make sure you have the base server software ready, so your web, application, and database software are installed.

Second, make sure you have a copy of your application code and configuration files handy. I always like to have these in source control, on a server other than my live one, so in the worst case I can pull them down to my emergency location.

Third, you need your live data, that is, your database contents. Take frequent dumps of the data and have them handy, again away from your live server. Do this outside your system backups, use your database tools such as mysqlbackup to dump a file, then zip it and ship it somewhere else. How frequently you do this depends on how often the data changes, and how important it is to have fresh data. In the most extreme case, you might have the database continually dumping a log to a shared file store, where the backup server is reading it in.

A sticking point may be the DNS. You can change the DNS, but users will have the old DNS information cached. How long it takes for them to get the new IP address depends on the TTL you have set in your DNS configuration, and changing this to a lower value after the crash ain't gonna help. A two hour TTL is probably a good setting.

Of course, better yet is if you have multiple servers behind a firewall and/or load balancer, so you don't need to change your DNS at all, just reconfigure and go. But if you're running a budget setup, these are simple steps to follow to make disasters a little less stressful.

Why would someone pay £500 per month for a server when they could pay less than £100 from a different provider? The short answer is support. But it's a more complicated story than that.

One of my clients had a key server die this week, one of many they have with a cheap hosting provider. After investigating a bit, it was clear that it was not a system error - I was briefly able to examine the system logs using the provider's web based recovery tool, with no evidence of problems, but then the server stopped responding even to the tool.

So I called support. The first-line support guy verified that the machine wasn't responding and couldn't be recovered with the online tool, so he referred it to engineering at the data center.

However, he couldn't tell me when they would investigate the issue. It depends on how busy they are. With a real hosting provider, you get an SLA that includes response times. You also get someone who will communicate with you, to make you feel like they're on the case. I only got the promise that I would get an email when it was fixed, no direct contact, no phone call.

In the end it took three hours for them to fix the server. This isn't an unreasonable amount of time, given the cost of the service, but during those three hours my client decided that the three new servers they had decided to add that very morning should be gotten from another provider instead. They'll probably end up paying five times the price, but they know they'll get better support.

The key point here isn't that the service was poor. They fixed the problem fairly quickly. It isn't even just that they could not promise a response time - with thousands of customers paying less than a hundred pounds a month, they can't afford to make guarantees.

But even a cheap and cheerful support organisation should have a way to give updates on their progress, even if it is just via semi-automated emails. Let me know when your engineers have started investigating the problem. Let me know when they've identified the cause, and when they've fixed it.

The frosting with these guys came when they sent the form-email that the problem was fixed. I replied, asking if they could tell me what went wrong. The reply came the next day: look at your server logs.

That's lame. That's passing the buck. It's not in the server logs, because it's not an OS problem. Hard booting didn't fix the issue, and whatever did fix it didn't involve changing any configuration files or such on the server. So it was a hardware or network issue of some kind.

I guess I'll never know. And I guess I'll never use these guys again.

I've been working up a cfengine-based setup to manage a new server infrastructure. This will be my third cfengine-based infrastructure, so I should have learned enough to make a cleaner, tighter configuration. Unfortunately I'm still finding cfengine to be too damned awkward.

So, I'd like to put together a list of alternatives to cfengine. I'll add them to this page, and hopefully add on notes and reviews as I learn more. If you have experience with these or others, please add a comment.

• Puppet seems to be an up and comer. It looks to be designed to be much more extensible than cfengine is. It also lets you make sure each host only sees its own configuration, which is one of my peeves about cfengine. It's my leading candidate at the moment.

My Fellow Syzygy alum Piers Fawkes interviews Iain Tait, another of our former colleagues now with Poke, about their recent win of two (count 'em!) Webbie awards for their work.

It's a fairly brief piece, but for more of Iain, check out his weblog, where he keeps up an admirable pace of quality posts.

I would call cfengine a configuration management tool. I just can't get into graphical and web-based tools for managing servers, I much prefer having a set of configuration files that I can check into version control. Once I've got a decent configuration set for an infrastructure, setting up, updating, or changing the role of a machine is a simple matter of tweaking the configuration files and running a command.

I find cfengine to be a bit awkward, it's configuration system suffers from being an academic research project. But so far I haven't found anything better.