I’d noticed for years that sending outbound e-mail from Thunderbird to my server on port 587 took far longer than it should have – about six seconds of staring at the progress bar.
Today, I was finally bored enough to work out the cause: Exim is configured to perform ident checks, which take 5 seconds to time out. Since port 587 only accepts mail from authenticated users, we can disable the ident checks for it:
rfc1413_hosts = ${if eq{$interface_port}{25}{*}{! $sender_host_address}}
If you’re running Debian, change the above in /etc/exim4/conf.d/main/02_exim4-config_options.
We‘ve been having a spot of bother with update-grub not working on our Debian Xen guests since upgrading them to squeeze.
The symptom: update-grub (as run after the installation of a new kernel package) fails because it’s ‘unable to find [a] GRUB drive for /dev/sda2 – check your device.map’. This happens using both grub-legacy and the new grub-pc package.
You’ll probably have run into this if your guests were created using xen-tools.
Skipping over the related bugs, the long and short of it seems to be:
- The way Xen pokes /dev/sda1 and /dev/sda2 (which are probably LVMs on your dom0) into your guests without a corresponding block device confuses grub
- grub used to be dumb enough to ignore the mysterious presence of ‘partitions’ with no block device and carry on anyway
- The versions in Debian Squeeze are just clever enough to be dangerous and fall over in this situation
Happily, we’ve worked out the fix. Grub is hard-coded to do the right thing in this situation if your disk devices are called ‘/dev/xvd[a-z]‘, so you need to:
- Fix all references to ‘/dev/sda2′ to read ‘/dev/xvda’ (and /dev/sda1 to /dev/xvdb). In practice this means grub’s menu.lst and possibly your /etc/fstab if that isn’t by UUID
- Edit the /etc/xen/guest-name file on the dom0 to rename the partitions (change the ‘root’ specifier and the lines in the ‘disk’ list)
- Destroy (sudo xm destroy) your guest. Note that you must destroy and recreate it; rebooting won’t give Xen a chance to rename the devices.
- Bring it up again with xm create -c config-file
- Profit.
In no particular order…
- That Debian Squeeze will release in Q1 2011
- That I’ll discover a J2EE Servlet Container which isn’t totally horrible
- That some kind of reconciliation between the JCP and Apache will occur
- That Java 7 won’t be delayed forever
- That Python 3 will get adopted faster than PHP 5 or Java 1.5 did
- That we’ll finally see some major UK ISPs offering IPv6
Leave a comment if you can see anything I’ve missed, and we’ll check on them all at the end of the year…
The problem
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…
It’s been over a year since I deployed Django in production, and I wasn’t looking forward to it. Last time, I had a lot of trouble with mod_python, sessions and decimal objects refuising to pickle.
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.
Just over 18 months ago, I signed up for a 256slice from Slicehost to host this website, my email, etc. Later this week, I shall be shutting the machine down and cancelling my account with them.
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.
Edit: As Michael points out in the comments, Oxford users can avoid the mess below by simply disabling hybrid mode.
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.
I finally got round to putting Linux on my Advent 4211 yesterday. There are various ways and means of doing this; the ones which worked for me were:
The end results are really rather impressive; here’s a pretty picture:
Ubuntu Linux running on my Advent 4211
I’ve been aware for some time that my DNS isn’t quite as securely configured as I’d like. http://crashrecovery.org/named/ looks pretty good, but the two main issues bugging me were:
- 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.
- 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:
- 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).
- 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.
gq has been a necessary evil in my life for some time now. I need a graphical LDAP client for use on the CompSoc systems, but gq (to be fair, the versions of gq packaged for Ubuntu) seems to be very buggy, segfaulting all over the place if you try to do anything other than browse with it.
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.
