Symphonious

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.

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.

I've learnt way more about mod_jk in the last week than I ever wanted to know. Apparently the configuration is completely different between Debian 3.1 with Tomcat 4 and the current Debian testing with Tomcat 5 (point something). Why the mod_jk package doesn't just do the configuration for you is beyond me, or at least have a debconf wizard to do it.

Anyway, with Tomcat 4, the magical directive that makes deciding what to delegate and when simple goes like:

<Location /JSPWiki>
    JkUriSet worker ajp13:localhost:8009
</Location>

You, in theory, should be able to achieve the same thing via the workers2.properties file stuff but I never got it to work. The advantage of JkUriSet is that it embeds neatly into your apache config so you can nest it in a virtual host and it does the right things. You still need to futz with workers2.properties to tell it where the tomcat instance is, but that's fairly simple if you start with the examples.

I spent some time this afternoon trying to reduce the amount of spam that gets downloaded and dumped into my spam folder. Between SpamAssassin and Mail.app's spam filters there's basically no spam that makes it through to my inbox, but the sheer amount of spam being sent to symphonious.net, then downloaded from their to my home IMAP server before finally being processed by SpamAssassin is overwhelming and takes up a lot of bandwidth and processing time. Besides, with that much spam going into my spam folder I haven't been bothered reviewing it so if there are any false positives they are pretty much doomed.

I've implemented two measures:

1. Any email with a spam score above 20 gets sent straight to /dev/null instead of going into the spam folder. That made a pretty huge difference to the amount of spam to review, but did nothing for the amount being downloaded.
2. Implemented a bunch of the postfix configuration options described at http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt Hopefully that will block out the easily identified spam before it gets accepted at all and reduce the amount of email downloaded and SpamAssassin processing.

I also submitted the server to ORDB to check it for any open relay problems. Man, those guys are persistent - it's tried connecting about 20 times so far from various addresses and trying to send to different places etc. I haven't received its report back yet, but it seems to have been rejected with every attempt so it looks like I've got it all right.

Anyway, if you have any problems emailing me, leave a comment and I'll look into it.