I’ve moved (only a couple of blocks from where I was before), and as the new place has Webpass I’ve reluctantly given up my Sonic.net connection, along with its static IPv4 address and ISP IPv6 tunnel. Hard to resist a 200Mb/s ethernet connection for the same price I was paying for 18Mb/s ADSL2 though.

However that leaves my DGN3500 router somewhat inappropriate for providing my net connection. Freed from the need for an ADSL/cable router I decided it was time to build an all in one house server (I’m a believer in as few always on boxes as possible). I already had a nettop acting as a media box, but wanted to build something that would handle:

• Gateway for the external network connection
  • Routing to internal ethernet
  • 2.4GHz wifi router
  • 5GHz wifi router
• Printer server
• House NAS
  • Backup server (syncing externally as well)
  • DLNA server
• mpd server
• ATSC based PVR

Probably in that order if it turns out I’m asking too much. The intention is the box is the only one that always needs to be on, so I wanted it to be low power consumption. I also wanted the option of hooking it up to the TV if it turned out to have enough grunt, so the case needed to be something suitable for the living room.

I like Intel’s approach to graphics drivers, in particular the existence of Free video acceleration support, so I went with an Intel Core i3-3220T as the processor. It’s a 35W Ivybridge processor with HD 2500 graphics, plus I got it for a decent price.

For the case I chose a CFI A2059. There’s a local supplier I was able to pick it up from, it has a couple of large fans which helps keeps the noise down while keeping things cool and as I was aiming for backup / file sharing being more important than a media box the 2 hot swap bays tipped the balance away from an AV style case.

The small case limits the motherboard options. I wanted twin GigE ports so the external was entirely separate from the internal (my switch does VLANs so I could have made do with a single port, but with a 200Mb/s connection I didn’t really want to share the port). The Gigabyte GA-H77N-WIFI seemed to fit the bill, with the added advantage of a built in WiFi card (an Intel 2230 in a mini PCI-E slot) which leaves the PCI-E slot free for either a TV tuner or a second WiFi card to cover 5GHz.

I maxed out the board with 2 8G G.SKILL DDR3-1600 DIMMs. I normally go Crucial because I’ve found them reliable, but these were slightly cheaper and available from the same place as the motherboard.

Finally I added a Seagate ST4000DM000 for storage. It actually came from a Backup Plus that Costco were selling for about $20 less than the bare drive sells for. The plan is to add at least another 1T drive to RAID1 the most important bits (or possibly a 2T - it depends which of my existing drives I can tidy stuff off most easily).

Of course it’s running Debian and I took the opportunity to try out the RC1 Wheezy image. For extra giggles I did an EFI install; this all worked fine except I didn’t end up with grub-efi installed at the end, instead I had grub-pc. I booted with legacy BIOS enabled and followed Tanguy’s switch to UEFI boot instructions.

Further notes on software setup to follow…

(This is something I did a few months ago, and I really should have noted down all the details then so I covered everything. However hopefully these notes will remind me enough next time.)

When I first wanted to reverse engineer a USB device that only had Windows drivers the “easy” option was to take a Windows machine, install usbsnoop on it and capture the traffic as a bunch of verbose text files. It was a cumbersome procedure.

Recently I wanted to do a firmware upgrade of a ZTE 3G modem dongle, partly to provider unlock it and partly to try and enable some voice functionality. I was also hoping to sniff the traffic to see how to drive the voice side of things. These days I don’t have a dedicated Windows box, but I do have a Windows 7 KVM virtual machine. I hadn’t yet used the USB support in this, but I thought I’d see what it was capable of.

Firstly I had to explicitly enable USB2 - the device wasn’t happy with the default USB1 only stack that KVM enabled. That involved passing -usb -device usb-ehci,id=ehci to KVM. I also told KVM to grab all the ZTE devices with -device usb-host,bus=ehci.0,vendorid=0x19d2. I dropped a udev rules file into /etc/udev/rules.d to ensure any device nodes created belonged to my normal user.

This gave me a Windows setup that could see the USB dongle and install the appropriate drivers. It was also happy to do the firmware update (along with various device resets on the way as it changed USB ID - this is why I needed the udev rule, to ensure every time the device re-appeared it would be seen by the KVM instance without manual intervention).

After that was complete I investigated usbmon. modprobe usbmon created the appropriate /dev/usbmon<n> files and I chowned the appropriate bus to my normal user. Once this was done I was able to start Wireshark which rather nicely has full USB decoding support. Firing up the custom app in the Windows KVM guest I could see the traffic going back and forth to each of the device endpoints and work out what was going on.

All of this was much more flexible than using a standalone Windows box. Once I figured out that I needed to explicitly enable USB2 I was quite pleased with how simple USB access under KVM was. I also used lvm to create a snapshot of the Windows guest so at the end I could roll back all of the drivers I’d installed for the dongle. And being able to use Wireshark instead of trawling through dense text files helped a lot in seeing the command stream.

The SPI 2012 board election voting opened up on Sunday and is open until the end of Saturday 28th July. My 3 year term has come to an end, so I’m standing for re-election. Michael Schultheiss (our current treasurer) is also standing again. There are also 2 new candidates in the shape of Gregers Petersen and Selena Deckelmann.

My nomination statement doesn’t have anything earth shattering in it. I’m largely of the opinion that SPI itself should be a boring organization, dealing with the common admin tasks of its associated projects and letting them get on with the job of changing the world. There are some challenges about how we scale larger that I’d like to see solved, but on the whole I see my role as a board member as being one of ensuring that SPI continues to function in a sensible fashion, rather than one of engaging in altering it in any serious fashion.

If you’re an SPI contributing member please vote - obviously I’d like you to vote for me if you think I’ve done a decent job over the past 3 years, but even if you don’t I’d still like you to take the time to be involved and vote.

I generated 0x94FA372B2DA8B985 (my 4096R GPG key) back in 2008, and revoked my old 1024R v3 key around the same time. However I left my main 1024D key alone, figuring I’d get round to revoking it at some point once the new one was sufficiently trusted. This probably happened some time ago, so today I have finally revoked this key:

pub   1024D/0xF1BD4BE45B430367 1999-10-26 [revoked: 2012-07-13]
uid                            Jonathan McDowell <noodles@earth.li>

If you’re not in the habit of refreshing your GPG keyring regularly now might be a good time to (gpg --refresh-keys) or at the very least pull my updated key (gpg --recv-key 0xF1BD4BE45B430367) to make sure you don’t accidentally continue to use it.

(If I haven’t signed your key with my stronger one please do wave a fingerprint/ID at me next time we meet, and ask me for the same in return.)

I’m at DebConf 12 and I’ve decided to use my time to clear out some minor bits and pieces I’ve been planning for a while. One of these was to do some graphing of the Debian keyrings over time. The bzr repository goes back to March 2008, but I’ve also got copies of keyrings for releases back to slink (February 1999). I’ve been a long time user of GD::Graph under Perl, but recently discovered SVG::TT::Graph and have been meaning to play with it. So I did. First up, number of keys in each keyring:

Most of the interesting data is towards the right, but we can also see the point where our v4 keyring overtook v3 keys back in 2001. More recently there’s the end of our v3 support in 2010, and the steady increase of Debian Maintainers. The tiny green line is the Debian non-upload keyring.

Next I looked at key size (limiting myself to the DDv4 keyring to make things simpler):

Here we can see the steady increase of 4096 bit keys since 2009, and to a lesser extent 2048 bit keys. There are a few other sizes - 1 10k key, 1 8k key and 2 3k keys (I suspect these are tied to OpenPGPv2 cards). We’re up to 28% of the keyring being stronger keys, but there’s still a long way to go. (Interestingly the Debian Maintainer keyring is much better with 65% of keys being 2k or larger. The non-upload keyring is all 2k or greater.)

Finally I graphed key type, again limiting myself to the DDv4 keyring:

No real surprises here; DSA far and away the most common with RSA usage increasing as part of the move to larger key sizes. In the past we had a few Elgamal signing keys, but these were shown to be compromised thus disappeared entirely.

What do these graphs show me? At least the following:

• Debian has a steady rate of growth, for both DDs and DMs. As Zack mentioned in his keynote yesterday it would be nice to see more non-packaging contributors.
• We’ve made a noticeable effort towards transitioning to stronger keys, but there’s still a lot of people who need to make the switch.
• Our rate of growth has slowed over the years (not really surprising).

(You should be able to click on the graphs for larger version.)