OK, another one for posterity. I’ve a desktop PC that I’ve converted into a Ubuntu-based server by putting it in my utility room with no monitor connected to it (that’s what makes it a server, see?). I’ve attached a 750GB external USB HDD to it and run SMB/CIFS and netatalk (for my OS X machines). That’s what makes it a file server, right?

I occasionally run into problems when Ubuntu reboots though – the partitions on the external drive can’t be mounted for whatever reason (usually because they weren’t dismounted properly before the reboot). Ubuntu’s boot process stops and it displays a prompt directing the user to press ‘S’ to skip mounting or ‘M’ to manually fix whatever the problem was. Although you can ping the server, you can’t SSH to it. Once you’ve figured out that that’s why it won’t boot, all you need to do is connect a keyboard, press ‘S’ a couple of times (once for each partition on the external HDD) and Ubuntu will complete its boot cycle. That gets a bit tedious though, so to fix this once and for all, edit your fstab (/etc/fstab) and add ‘nobootwait’ to the options for each drive.

/dev/disk/by-label/STUFF /mnt/STUFF hfsplus auto,users,rw,uid=dermot,nobootwait 0 0
/dev/disk/by-label/MOARSTUFF /mnt/MOARSTUFF hfsplus auto,users,rw,uid=dermot,nobootwait 0 0

I was going to write a post about how straightforward it is to live stream from OS X to iOS, especially when compared to doing the same thing for Android. But then I discovered that Apple have put the HTTP Live Streaming tools behind the iOS ADC pay-wall. Boo! Hiss!

I’ll probably just do a more generic *nix guide instead.

I’m posting this here for posterity since I’m sure that I’m not the only person who’s ever wanted to do this and I had to piece it together from a few sources. And yes, I know, this is made much easier if you use Time Machine. Shut Up!

I decided to upgrade the HDD in my MacBook and didn’t want to start afresh with a clean OS. I don’t have a spare external drive lying around, so I don’t use Time Machine (I know, I know, I should, but my preferred back-up strategy works for me). What I did instead was use SuperDuper! to clone my current HDD to a SparseBundle on a network share. I then shutdown, swapped out the old disk for the new one and booted up the original install DVD for my MacBook.

My assumption was that I could go into Disk Utility, partition my new HDD and then restore the SparseBundle to it. Of course, things didn’t quite go according to script.

Partitioning went fine of course, that’s straightforward enough. My first issue was actually mounting the AFP share that hosts my backup. I’m not sure if it’s a peculiarity of my file server – which runs Ubuntu with netatalk to share via AFP – but even though the server itself showed up in the network sidebar of the ‘Select Image to Restore From…’ file dialog, none of its shares did. The shares on my Macmini did, however. Thankfully this was an easy one to solve: quit Disk Utility, start Terminal and mount the share from there:

mount_afp afp://dermot:hahayeah@porkboy.local/Backup /tmp

(Yes, I mounted it to /tmp – there are almost certainly better places to do this but it worked out OK so I’m not bovvered).

Exit Terminal, back into Disk Utility to try restoring again. No dice. I could see the share in the dialog now, but the SparseBundle was greyed out. Bah! After some Googling I found my answer. Exit Disk Utility, back into Terminal and…

hdiutil attach /tmp/backup_20110728.sparsebundle

Back into Disk Utility to try restoring again. This time I just had to drag the mounted backup from the side-panel on the left into the ‘Source’ field, drag my HDD into the ‘Destination’ field and click ‘Restore’. Job done (after a couple of hours!).

If you’re having trouble logging into your MSN (aka Windows Live Messenger) account in Pidgin this morning then there’s a good chance that it’s because the certificate for omega.contacts.msn.com has expired. Thankfully the solution is easy:

Quit Pidgin completely, open a terminal, cd into ${HOME}/.purple and move certificates to certificates.old. Restart Pidgin and you should be able to log in to the MSN network.

Update:

And it’s broken again. Moving/deleting the above directory doesn’t have any effect now. Sad face.

Update 2:

Found a solution, thanks to some pointers on Twitter. Handiest way to fix this is to go to https://omega.contacts.msn.com/ and export that site’s SSL cert to a file called omega.contacts.msn.com. Move that file to ${HOME}/.purple/certificates/x509/tls_peers/ and everything should be fine.

God knows how that can be changed in Empathy, which seems to be having a similar problem – I can’t for the life of me figure out where Empathy stores its certificates etc.

Anyone who grew up or lives in Ireland is familiar with BBC television thanks to cable and satellite TV. Because of our proximity to Wales and especially Northern Ireland, we in the east and north of the country have been able to receive BBC broadcasts for decades despite not paying a license fee in that country. I’ve long felt that this state of affairs should continue even into the Digitial Era despite BBC’s best efforts to lock iPlayer down to only those people who live in the United Kingdom (a.k.a., license fee payers). My attempts to circumvent their geo-location recognition mechanisms have always been fruitless until one day lest week when I was reading through the man page for SSH.

As I scanned the various command line flags for whatever it was that I was looking for my eyes settled for a moment on the description of the -D parameter and I had a minor epiphany. When you ssh to a remote host using the -D flag, ssh establishes an encrypted tunnel that listens on a TCP port on your local host. You can then direct traffic across this tunnel by specifying the port as a SOCKS proxy. Traffic pops out the other side and is forwarded to its destination, where it looks as though it originated on the device to which you SSHed. Clear as mud, so let’s try an example:

localhost$ ssh -D 8080 myuser@remotehost

This will establish an SSH session on remotehost and will open port 8080 on localhost. What you then do is open your web browser and set localhost:8080 as your SOCKS proxy server. All of your web traffic will be sent across the SSH session and will appear to originate on remotehost.

A few years ago a colleague of mine gave me a shell account on a server he runs in the UK. Up to now I haven’t had much use for the account other than for testing my routing configurations from an offnet server. Not any more!

Now, I don’t necessarily want to send all of my traffic across the SSH tunnel. For one thing, the encryption and compression inherent in the SSH connection limits the amount of bandwidth that I can send/receive. For another, if the SSH tunnel goes down for any reason (for example, if I close the lid on my laptop then the SSH session times out) all of my web traffic is being sent to a non-existant web proxy. Carnage, especially when my wife is trying to browse the Asos catalogue or watch ‘Home & Away’ in the RTE Player. Nor do I want to have to reconfigure my browser’s proxy settings every time I feel like looking at an episode of ‘Seven Ages of Britain’ or ‘QI XL’.

One of the neat things about the -D flag is that other PCs can use the tunnel that it creates as a SOCKS proxy. The neat thing about my router is that it runs Linux (OpenWRT to be exact). So I got to thinking: is there any way that I can use my router to selectively redirect web traffic into my SSH tunnel? Of course there is!

The first thing to do was to install Screen on my router. Screen is a terminal multiplexer – a program that acts as a wrapper around Linux/Unix shells, allowing you to attach and de-attach from them without losing your shell sessions. I start my SSH session in a Screen and then de-attach, leaving the session running in the background (and meaning that I don’t need to remain logged into my router from my laptop).

I then installed Privoxy, a proxy server. Privoxy has lots of great features but I chose it over Squid (which I’m more familiar with) for one reason: Privoxy supports forwarding into SOCKS proxies whereas Squid doesn’t. Privoxy seems to be lighter as well, always a concern on a device with limited memory. I’ve configured Privoxy to listen on port 8118 and to accept intercepted connections.

This last configuration point is the final and key piece in this puzzle. I added the following rule to my iptables ruleset:

iptables -t nat -A PREROUTING -i br-lan -p tcp -d 212.58.240.0/20 --dport 80 -j REDIRECT --to-ports 8118

This command is straightforward. Any traffic received on br-lan (i.e., any of my LAN interfaces) destined for BBC’s network (212.58.240/20) and with a destination TCP port of 80 (the port that webservers listen to) should be redirected (i.e., intercepted) to port 8118 on the router (8118 as I mentioned above is the port that Privoxy is listening on).

Now when I want to watch BBC iPlayer I don’t have to do anything – my BBC-destined web traffic is redirected to the SSH tunnel via Privoxy and my non-BBC traffic is allowed to exit via the router’s WAN interface unmolested. Sweeeeeeeet.