A word document (plain old .doc, not 2007) should be received by e-mail, fed to a script, turned into a PDF and published on a website.

At my disposal

My server running Debian ‘Lenny’, which does not have a display of any kind.

How hard can it be?

Harder than it should have been, as ever. Here are my steps:

# aptitude install python-uno xvfb openoffice.org-java-common openoffice.org-writer unoconv

You’ll note the inclusion of Xvfb there, because it turns out that “headless” mode in OpenOffice isn’t really headless at all. Sigh. Also sigh some more at the broken dependencies of the unoconv Debian package.

Now we can write our script to do the actual conversion. Shame it took twice as long as it should have…

Thankfully, all this really seems to have grown up in the last year – mod_wsgi is now the recommended way of deploying Django in production, and following the mod_wsgi django instructions, I was in business in 20 minutes. No fuss, no mess, no drama, and best of all, using daemon mode, no noticeable performance hit when serving static files and PHP off the same Apache installation. The ability to run the django project as its own unprivileged user when using daemon mode is also real handy.

For the record, this has nothing to do with the level of service I’ve received from them – I’ve always found their support team quick to respond and helpful, and their articles site and wiki are both very handy.

However, a combination of fluctuations of the pound against the dollar, a surge in demand for RAM by my applications and sites, and my getting increasingly fed up with transatlantic ping times of 130ms meant the machine was becoming unfit for purpose and overloaded.

Thus, I have now found a reasonably cheap way to bring “my stuff” home to hosting in the UK. About which, I will be writing more shortly!

So goodbye, Slicehost, and keep up the good work. I’d certainly recommend you to anyone who lives in America and needs a VM.

So there I am, firing up the Advent to read my email between lectures when…

$ sudo vpn-connect oxford
vpnc-connect was built without openssl: Can't do hybrid or cert mode.

Gah? The VPN client has always worked in the past, but following the upgrade to Ubuntu Intrepid, it doesn’t. A quick search lead to a solution which can be summarised as:

$ cd /tmp
$ apt-get source vpnc
$ cd vpnc-0.5.1r275
$ $EDITOR Makefile

Uncomment the lines beginning with OPENSSL
Read this and despair for the future of open source software

$ sudo apt-get build-dep vpnc
$ dpkg-buildpkg

Wonder why it all collapses in a heap
Search and find this.

$ apt-get install libssl-dev
$ dpkg-buildpkg
$ cd ..
$ sudo dpkg -i vpnc_0.5.1r275-1ubuntu1_i386.deb

Wonder why this has changed between Hardy and Intrepid
Seriously consider going back to Windows on this machine.

Sigh.

• Use the installation image optimised for small screens
• Follow these instructions to make a bootable USB drive from the image (note: it’s ‘cat’, not ‘zcat’ as the ubuntu image is not zipped. I know they’re Debian instructions, but they seem to work)
• Use the script given in this forum post (run as root) to get the WiFi working.

The end results are really rather impressive; here’s a pretty picture:

Ubuntu Linux running on my Advent 4211

1. Anyone could do a ‘dig @ns.dnorth.net dnorth.net AXFR’ to retrieve a listing of all my DNS records – not great from a security point of view. This is a capability that should only be turned on for secondary DNS servers which need to fetch from the master.
2. The server would perform arbitrary lookups [for any domain] on request. This means it’s operating in ‘recursive mode’, which is a Bad Thing for various reasons.

The solutions were:

1. Add “allow-transfer { “slaves”; };” (without the double quotes) to the section of the configuration beginning “zone ‘dnorth.net’”. Then add a section defining the “slaves” access control list to be the local server, plus the secondaries: “acl slaves { 127.0.0.1; 123.45.67.89; }” replacing 123.45.67.89 by the IP address(es) of your secondary nameserver(s).
2. Add “recursion: no;” to the “options” section of the configuration.

Then restart the BIND9 service – on Debian, this is “/etc/init.d/bind9 restart”.

Health warning: Don’t do (2) above if you rely on your server to do its own DNS resolution – follow the crashrecovery tutorial above instead.

Last week, after upgrading to a 64bit version of Ubuntu for the first time, I finally ditched gq, after running into identical symptoms to this Debian bug.

The good news is that there’s an alternative that actually works: it’s called Luma.

Have fun.

My personal email has been on a rough ride over the years: from a reasonably nice (Microsoft based!) school email setup in 1999, which sadly got removed when Windows 98 was introduced, I went through three Hotmail accounts. I had a brief flirtation with GMail, but not being all that keen on the means of delivering advertising, I ended up back on Hotmail.

Registering dnorth.net last year at least ensured my email address would no longer change, but the technical capabilities of the two mail servers holding the mail still left much to be desired: flaky, unreliable spam scoring, no facilities for server-side filtering/sorting, sheer lack of customisability…

Last week, I finally did something about it. At my disposal was my VPS, running Debian Linux 4 (‘etch’). On the wishlist were:

• Accurate server-side spam scoring with SMTP-time rejection of the most obvious spam
• Sender verification
• Sieve filters for server-side sorting into folders
• All mail stored on the server and accessible over secure IMAP

Thankfully, none of the above is too difficult: some pretty good instructions are Out There for most of it. The ones I used were:

• Exim4 on Debian with SpamAssassin, ClamAV, Virtual Domain Alias Files and Message Size Limits per Domain
• Exim + Sieve + Avelsieve Howto
• Handling mail for multiple virtual domains with exim4

Please remember, I am not responsible for the content of external sites (e.g., the links above), nor can I accept any responsibility for the consequences of acting on the points below…

I ran into a couple of issues:

• Permissions on the .sievesource files generated by AvelSieve – I needed to chmod g+w on /var/lib/squirrelmail/data and chown it to www-data:www-data in order to reach a state where Exim could read the file, and Avelsieve could write it.
• Exim4′s native sieve implementation only has the core features in it, not the extensions defined in RFC 3431. I dodged the issue by matching the number of *s in the X-Spam-Score header using string matching, rather than numeric checks on the X-Spam-Score.

All in all, though, it’s working a treat. Email perfection at last!