Debian on the AppleTV

It's hardly a first, but I did find some of the information out there a bit spread out. So, just incase I need to go through this again, I figured a 'blog post might be interesting - doubly so as I've not really got anything interesting from work, that I can blog about at the moment!

So, a bit of background. The AppleTV (ATV) is basically a dumb x86 PC - Pentium M 1GHz, 256MB of RAM, 40 or 160GB PATA HDD, 1x USB 2, 1x IR receiver, 10/100Mb ethernet, 801.11n Broadcom WiFi and a Nvidia Geforce GO 7300 - all which uses about 17W of power in a fairly compact and quiet, form factor. What I hadn't banked on was the very retarded power supply. I knew that the ATV wasn't able to power off, but I assumed that was a software thing. Oh no. The actual power supply has no concept of switching. It's either on or off. Which is slightly annoying.

The whole "hacking" process is largely taken care of - a bunch of enterprising invididuals have got it running, over the course of several iterations. The most recent is the efforts from the ATV-Bootloader team, who have basically built a small recovery image, which translates some of the EFI structures into BIOS compatible (allowing unpatched kernels to run) and has a very cut down Linux installation which then chainloads (using kexec) another Linux kernel. The really awesome thing is that these guys have made some nice tools to stream line the efforts if you want the ATV OS and Linux to co-habit. I didn't want this particularly.

So first thing first was the old hard disk was removed and a new one was prepared under my desktop install of Linux, via a USB to IDE converter, using the instructions on the ATV-Bootloader project wiki. Pay close attention to the requirements for a patched parted.

Next I used debootstrap to install a basic Debian (squeeze) system into /dev/sda4 (ATV-Bootloader sees all drives as /dev/sd*, where as when you boot into a kexec'ed kernel they will be seen as /dev/hd* - this confused me for a few minutes - not something you want when you're scrabbling around at stupid o'clock in the morning). At this point I then chroot'ed into it and used apt to install a kernel, but no bootloader. Since the ATV-Bootloader uses kexec all you need to do is have a valid one of the following: mb_boot_tv.conf, menu.lst (grub), syslinux.cfg (ISOLinux), or kboot.conf. Having played with grub files quite a lot I thought that I knew the syntax well, but do you think I could get it to work with a grub file? No. I ended up whimping out and using a mb_boot_tv.conf (popped it into the root of the Linux partition) which is a lot simplier[1] and is infact the first file searched for (so its slightly faster to boot). If you don't fancy that then check out boot_linux.sh from the ATV-Bootloader trunk to see all the options and example configs (in-line comments). The only other things you need to remember are the usual when debootstrapping - create a valid /etc/network/interafces (man 5 interfaces, if you're unsure), make sure udev numbers your network cards correctly (/etc/udev/rules.d/70-persistent-net.rules), and of course your root password. Exit, reboot and hey presto, you should be into a very basic Debian install.

My next annoyance was the flashing LED. By default it flashes orange to tell you that its booting, and then the ATV OS would reset it to a white light. Thankfully a great chap by the name of Peter Korsgaard has written a tool (available from git and here - note needs to be compiled) called atvtool to control the LED and the fan. It's a little basic and doesn't play well with lircd at the moment (you can set atvtool to release the controller back, at which point lircd needs to be restarted), although I'm hoping to have a poke and understand why and hopefully fix this.

WiFi is also fairly important to me since I'm going to use the ATV to replace my WRT54G bridging 2 networks here. Sadly the only real options seem to be using ndiswrapper or the Broadcom-STA drivers. I opted for the Broadcom-STA and things are going well, with no issues at present - the only special thing I did, for my own brain, was to rename the adapter to wlan0 (again, udev persistent-net.rules).

From here on out, if you're running headless, everything should be working like a dream. At this point I elected to install the nvidia kernel module only to see if I could get anything useful from lm-sensors, but there wasn't much luck on that front. if you're planning on using the ATV as a media center or with a monitor/TV, then you'll definitely need it.

What does this leave you with? A low power, almost silent, fairly capable machine to run part of your network. The only sad thing, in my eyes, is the limitation of a single USB port. From here you could run forked-daapd to share your music, any of the several network file systems, DHCP, DNS, you name it. Just watch the memory usage - don't forget that there's only 256MB of RAM to play with.

[1] Vaguely what my mb_boot_tv.conf looks like - note the /dev/hda4 instead of /dev/sda4. #try-net-boot kernel /vmlinuz append ro root=/dev/hda4 initrd /initrd.gz

Against better judgement

I've been playing around with CouchDB for a few nights, inspired by the work of Stuart Langridge and others at Ubuntu, and also J Chris Anderson.

To break myself into the CouchDB world I started poking around at the capabilities, and mostly trying to not think of SQL-isms. Understanding map/reduce and getting your brain out of the SQL world is worth it, if for no other reason than to get a different perspective on data storage.

Unfortunately I decided, rather than write what I really thought would be interesting (a Thunderbird provider for couchdb, so that I can replicate my lightning calendar and contacts to my server, laptop and desktop, without using SyncKolab[1]), that it would be best if I started simple.

I chose to develop a pure CouchDB application, using the rather nice couchapp. I write web apps and this should be a gentle introduction, and fairly quick (which is what I wanted primarily). Really, How hard could it be? So I pulled down couchapp, did a bit of reading and built a VM to run couchdb 0.9, as several newer features are required than the current version in Debian stable. What I'd failed to realise at this point was that the "API" for pure couch applications are a bit in flux. After a few hours, over the course of a few evenings I've become somewhat frustrated, until I noticed a page entitled Formatting with Show and List on the CouchDB wiki tonight. A lot of the available code out there uses the new API, which explained why a hell of a lot made bugger all sense and why I'd almost started pulling down the couchdb 0.9 to have a butchers.

Now this isn't a slur on anyone except me. I was so blinkered after the joy of understanding why non-SQL databases do have a place in the universe that I failed to search the wiki correctly.

To give the whole post a sysadmin-style slant, during this I'd started noticing the CouchDB growing quickly. Now granted I was doing a lot of pushing of attachments, shows and lists, but the growth seemed rather unproportioned. After doing some tests of my own I hit the web and found that Joan Touzet has some interesting thoughts on the subject as well, which you should go and read now. Naturally without putting my tests into the real world don't take it as gospel, but if you're using couchdb you might want to ensure that you're doing things the right way, lest your sysadmin smite you with the +2 damage hammer of server resources.

I'm trying very hard not to paint a bad picture of CouchDB here. Genuinely I think it's a good project, and although it certainly has a lot of competition, it does seem to have a lot of mindshare. There are also good points to, for one, backups are easy.

[1] Not that I have a problem with SyncKolab, it's serving me well, and probably will continue to do so.

LigHTTPD: Undecided

I've been using Apache longer and across more platforms, than almost any other single item of software. However, as I'm going through the process of moving server provider I thought that I'd give LigHTTPD (lighty) a go. After all it's an interesting bit of code that's gaining some use.

The main problem was, unsurprisingly, letting go of my Apache-isms. The configuration styles are radically different, and whilst I do like the LigHTTPD style something about it seems a bit... well messy. I expect the lighty hordes to blast me now, and I suppose thats sort of what I deserve. After all on initial inspection the lighty config is much shorter and arguably much more concise.

Or is it? Given the scripted-like nature of it's config you can acheive the same configuration in a number of different ways, some which appear (I've no solid numbers at all to back this up, it's all down to my perception for now) to have better performance than others.

I'll carry on with lighty for now on my personal server, and delve into how it all fits together. But after spending an evening with it, I'm not exactly sure that we've clicked.

IPv6, IPv4, and ARP on Xen for VPS

If Xen is your thing, Cory von Wallenstein's relatively recent article on IPv6, Ipv6, and ARP on Xen might be of interest to you.

I'm unsure if his patches have been merged into the main Xen source, but it's still an interesting read and useful if you're wanting to secure Xen domU's, or experiment with IPv6.

XCache rocks

I'm liking XCache. "It does exactly what it says on the tin", and all from the people who brought the world LigHTTPD. And that makes me wonder. Should I be taking a long hard look at Apache HTTPD?