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.

The last two or three weeks have seen to ‘first proper’ events for Finn. To begin with, this was his first proper Christmas; that is to say, the first Christmas that he’s really been aware of what’s going on though he didn’t really understand all of it.

He knows who Santa is, for example, and will point him out when he sees a picture of him or someone dressed as him (or if he sees a polar bear, for some inexplicable reason). He’ll also tell him that Santa says ‘ho ho’ if you ask. But I don’t think he quite grasps the concept of Santa as a bringer of presents. Before we opened the sitting room door on Christmas morning, Áine and I told him that we could hear Santa trying to get back up the chimney. Finn got a bit frightened when we said this so we had to hold his hands while we opened the door for him and lead him into the room.

His reaction to his presents was funny; his main gift from Santa was a bike and he got a few other knick-knacks such as a ‘Roary the Racing Car’ racetrack, some books, a Fisher Price Noah’s Ark and so on. Santa had quite helpfully unpacked everything and set it up before heading off, leaving the bike at the front of the pile. Áine and I felt a bit relieved when we saw Finn race over and grab his bike – we had, after all, written his letter on his behalf. Imagine our dismay then when he pushed it out of the way so that he could get to Roary! The bike hasn’t had a look-in but that’s probably the weather. Right?

The other ‘first proper’ for Finn this year was snow. Last time he was too young to go out in it (and couldn’t walk anyway) so this year we brought him out for a few minutes. It had started to thaw so we couldn’t build him a snowman but he enjoyed stomping about in it. He wasn’t too impressed when he tried to pick some up and discovered how cold it can be though!

And here he is (pre-haircut) in his current default mode (eating):

That last pic was taken at Powerscourt Waterfall the day of my birthday. Absolutely gorgeous place, I love having stuff like that so close to Dublin – literally a thirty minute drive.

So, Finn is just over 14 months old now and is coming along in leaps and bounds. Not literally – he’s just starting to find his feet as it were and is pretty close to walking. I’m guesstimating that this time next month he’ll have taken his first few tentative, unaided steps. For the moment though, he has us holding his hands while he walks stiltedly everywhere (he may have found his feet but his knees are a different story). He usually insists that you hold both hands but sometimes he’ll settle for just his right hand; for some reason he puts his left hand over his ear when you walk with him like this. Try to let go of his right-hand in favour of the left and he’ll just plop himself back down on the ground.

He’s confident enough at this stage to be able to walk up and down the living room (and the path outside the house) using his walker for balance. Trying to explain to a one-year-old that it’s time to go in because it’s just started raining is great craic.

When it comes to cruising though, he’s flying around and is well able to pull himself up on pretty much everything he can reach and that isn’t likely to topple over – sofas, beds, chairs, Thomas the Tank Engine thingie, your legs and the TV stand. I used to think that that last one was Finn being pragmatic; instead of moaning that 32 inches just isn’t a large enough screen size, he figured that if he got closer to the screen it would seem bigger. But then he started hitting the screen and I was quickly disavowed of that belief. Little rascal.

Anyway, here are some videos:

So how do you do it?

First things first – we need to enable web sharing. Open System Preferences, click Sharing and click the box next to ‘Web Sharing’.

Next we need to enable PHP. Although it’s installed with Leopard, the PHP module is disabled in Apache’s configuration by default. Let’s enable it – open a Terminal and type:

sudo nano -w /etc/apache2/httpd.conf

(Note that the ‘-w’ is important – it disable line wrapping). Press CTRL-W and type php5 then press return – the cursor should jump to the line that loads the PHP module:

#LoadModule php5_module        libexec/apache2/libphp5.so

Delete the hash mark at the start of the line and then press CTRL-O to save the updated config, followed by CTRL-X to exit the Nano text editor. Back at the command prompt, we need to restart the Apache server:

sudo apachectl restart

Give it a few seconds to come back up and then check that it’s working by browsing to localhost. You should be greeted by the default Apache home page. That’s the messy stuff done – it’s all downhill from here.

Download my EasyStream scripts and extract them to the Sites folder in your home directory. Make sure you keep them in their own subfolder (i.e., Sites/EasyStream). Create a directory under this one (call it whatever you like, I suggest ‘Movies’) – this is where you’ll store the video that you need to stream.

Open your browser again and go to http://localhost/~User/EasyStream/ (make sure you substitute ‘User’ for whatever your short user-name is). You should see the EasyStream interface but it’ll probably look a little barren with no videos to watch. The easiest way to create some is to use Handbrake to convert some existing ones, using Handbrake’s ‘iPhone & iPod Touch’ profile.

Once you have some video, it’s time to test with your iPhone/Touch – connect your device to your WLAN and then open Safari and browse to http://yourdevice.local/~User/EasyStream/ (substitute ‘yourdevice’ for your Mac’s hostname and ‘User’ for the short form of your username). EasyStream should list the video in your EasyStream/Movies folder; tapping on one should cause QuickTime to open and after a short pause to buffer, your video should start playing.

Like most things, this trick has some pros and cons. First the pros – you no longer have to fill your iPhone/Touch up with videos; just stick them in your EasyStream folder instead. Secondly, if you forward port 80 on the outside of your firewall to your Mac’s IP, you can view your videos remotely provided you have a working internet connection for your device and know your public IP address (I’ve no idea how well this works over 3G). Finally, as our first test demonstrated, you can view the EasyStream pages in your ordinary browser – you can also view the videos (provided QuickTime is installed). The non-iPhone version of QuickTime downloads the entire video before it starts playing but you can fix that by ticking the ‘web optimised’ box in Handbrake before you start your conversion.

As far as cons go, I’ve built in a ‘compact view’ that breaks the videos into an alphabetical hierarchy but with lots of videos in your EasyStream/Movies folder, things could still become cumbersome. Secondly, there’s no way to bookmark where you are in a video, so if you stop playing something midway through and then go back, you’ll have to scrub through until you find where you where. Luckily the iPhone makes this relatively painless and it’s a worthwhile trade-off not to have to store the videos on your iPhone.

Everyone had a great day, particularly Finn – although he did have us all tormented, wanting us to hold his hands so that he can walk around. Both he and Eoin also discovered the joy that is chocolate rice krispie cakes – Eoin made the even more joyous discovery that they’re even tastier when broken up and eaten off the floor. Yum!

As I mentioned above, Finn is mad to walk – if we put him standing at the sofas or our bed, he’ll ‘cruise’ back and forth. It’s only a matter of time before he starts walking unaided but for the moment we’ve finally found a surefire way to keep him out of trouble: he can pull himself up in the cot and he can maintain his balance so long as he has something or someone to hold on to but he hasn’t mastered sitting back down again. Good times.

All of this development has been fascinating to watch; it’s something that you don’t get a real appreciation for until you’ve experience it first hand and close up. They grow from being a tiny creature whose mind is little more than a collection of instincts and responses to a miniature person who knows his own mind and isn’t shy about letting you know (one year-olds having tantrums are hilarious, by the way – for about 5 seconds).

They also become adept at entertaining themselves:

That’s a little plastic chicken, by the way and he spent about five minutes doing that before the amusement wore off.

Finally, an illustration of how persistent he can be – like the above video, this is just a minute or so of something that went on for a few.

This left me with something of a conundrum – I use my Macbook for pretty much everything from the trivial (browsing the web) to the crucial (processing and cataloguing my photos and videos and so on). Obviously I wanted to continue to use Time Machine to back my data up but a second external HDD isn’t an option for me at the moment. So, I decided that I’d share the Time Machine partition attached to the Macmini on my LAN. My reasoning was that if I mounted this network partition on the Macbook and told Time Machine to use it as its backup volume, it would detect that it already had a backup store there and just continue using it. Except, of course, that it isn’t that straightforward.

When you direct Time Machine to use a network drive as its backup volume, it creates a sparse bundle on the volume. A sparse bundle is a type of disk image, similar to the ones that are used by virtually every Mac software developer/publisher to distribute their applications. The difference is that whereas a disk image is a single file, a sparse bundle is actually a directory that contains loads and loads of other directories, each of which contain individual files. Each of these files contains some of the data that comprises the disk image data. When one of the files inside the disk image changes, only the files in the sparse bundle that pertain to that dat need to be update; this makes Time Machine much more efficient when using network volumes as a backup store. When you try to open the sparse bundle directory in Finder, it will be mounted as though it were a normal disk or disk image.

What this meant for me was that when when I told Time Machine to use my network mounted Time Machine Volume – which, remember, had all of the previous backups I’d taken of my Macbook – it ignored the existing Backup.backupdb directory. Instead it created a new sparse bundle image, mounted it and started backing up – from scratch – to that virtual disk. This wasn’t satisfactory from three points of view. Firstly, backing up approximately 60GB of data across a WLAN would take forever. Secondly, it meant that I was consuming far more space on the volume than I wanted to what with two seperate Time Machine instances now living there. Thirdly, and most importantly, it meant that if I wanted to go further back in time than today, I’d have to physically disconnect the HDD from the Macmini, plug it into the Macbook and then return it to the Macmini every single time. Inconvenient once, pain in the arse forever after.

My solution was to copy the data from the original backup set into the sparse bundle, again on the assumption that this would cause the Macbook to pick up where it left off. As it turned out, this was the correct assumption but it wasn’t as straightforward as I had hoped, for reasons that I’ll explain in another post.

To make a boring story shorter, my ultimate solution was to use Super Duper! to copy the data into the sparse bundle. This took about eight hours, even doing it locally on the Macmini and once it was done I had to delete the contents of the Time Machine partition and copy the sparse bundle back to it.

It worked though and my Macbook is happily backing up across the network and I can use Time Machine to go all the way back to my initial backup in September of last year. I’ve also learned far more than I ever wanted to know about hard links.