Nothing if not efficient.

Category Archives: Debian

The U2F and OTP features are of some interest, but the main thing I bought it for was PGP via GnuPG. I was disappointed to discover that it works (at least as far as gpg –card-status showing the device) on current Ubuntu (15.10) and even on Windows (!), but not Debian stable (Jessie). Still, this is quite a new device…

In every case on Debian/Ubuntu, you need to apt-get install pcscd

For the non-internet-connected machine on which I generate my master PGP key and do key signing, I can just use the Ubuntu live CD, but since my day-to-day laptop and desktop are Debian, this does need to work on Debian stable for it to be of much use to me. A bit of digging revealed this handy matrix of devices, and the knowledge that support for the Yubikey 4 was added to libccid in 1.20. Meanwhile, jessie contains 1.4.18-1. Happily, a bit more digging revealed that retrieving and using the testing package’s version of /etc/libccid_Info.plist was enough to make it all start working:

I’ve raised a bug asking if the new config can be backported wholesale to stable, but meanwhile, you can copy the file around to make it work.

For U2F to work in Google Chrome, I needed to fiddle with udev as per the suggestions you can find if you Google about a bit. The OTP support works straight away, of course, as it’s done by making the device appear as a USB keyboard.

Recently, I was issued with a rather nice Thinkpad X230 for my new work laptop. Not being a huge fan of Windows 8, I decided to go for Debian as my operating system. And this presented me with a problem: my company has a local mirror of the Debian archive which I’d like to use in my /etc/apt/sources.list, as when I’m at the office, I have a fast network connection to it. But if I configure things that way, I’m out of luck outside the office if I want to install or update packages, as the private mirror isn’t visible to other networks.

Inspired by the Raspberry Pi’s mirror director (which takes advantage of the way APT follows HTTP redirects), I put together a solution to redirect me to the right mirror depending on where I am (based on a fairly naive reverse DNS lookup). Note that when you don’t have a private mirror around, you can use http.debian.net to apply the same redirection trick to point you at a nearby mirror based on geolocation of your IP address, etc.

It’s been running for a couple of weeks for my laptop’s use and seems to work. The only disappointment is that apt-get doesn’t print out the redirect chain, so you have to take it on faith that you really have been directed to the right place (of course, you can get a good idea of that by hitting up the redirector URL in a browser).

See Bitbucket for the code and deployment instructions. Let me know if you’re using it!

A few weeks ago, the story broke that hitherto unheard of (by me, at least) Austrian hosting firm EDIS was offering free co-location of Raspberry Pis in their data centre. Since I hadn’t really found a use for mine (like almost every geek I know who bought one ‘just because’), I decided to give it a go. The plan is to use it to run Nagios to keep an eye on various machines I run back here in the UK.

This guy describes how you can make a start, and I pretty much followed his lead – install the basic Debian image from the official RPi site, then rip out everything graphical, set up an SSH server, firewall it and expand the root partition to fill the SD card. In my case, I didn’t bother shipping a USB stick in it – the 16GB SD card should be all the storage a basic monitoring installation will ever need.

The last thing to do before posting it (along with a USB cable to power it) is configure the IP addresses they gave you (you were cool enough to ask for IPv6 too, right?). I wrote /etc/network/interfaces like this:

Obviously, replace the ws, xs, ys and zs with the settings they e-mailed you.

It’s worth noting (I had to ask EDIS to clarify this) that they don’t provide IPv4 DNS servers for you to use – go for Google public DNS or similar, with /etc/resolv.conf like this:

nameserver 8.8.8.8
nameserver 8.8.4.4

There’s not much you can do to test you’ve got the networking right, but I did boot it and check eth0 came up when a cable was plugged in, with the right IPs on it. You can also check the output of ‘sudo route -a’ to make sure the default route goes via the gateway it should.

You can tone down the (perfectly reasonable) check for these iffy characters by exempting centrica.com from it: edit /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt and edit the domains line of the second ‘restricted characters in address’ ACL to read:

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:

We‘ve been having a spot of bother with update-grub not working on our DebianXen 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.

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.