Today I worked from home because of the weather. Fortunately, Revivio is very well set up for this. Almost everything in the lab is set up with remote consoles and even remote power, and most of the connections we really care about are through switches that also allow remote management so we can simulate most kinds of failures just by turning ports on and off. Yes, we can and do even script such things for testing. As a result, most people can go for weeks without needing to step into the lab. Add the ability to connect from home, and the result is that it’s usually possible to do from one’s living room or home office things that at most companies would require physically sitting in the lab. It’s quite nice.

The situation is not quite perfect, though. Revivio does have a VPN, which I use from Windows quite happily for short stints. However, for serious programming I prefer to be in Linux, and I really don’t feel like installing and configuring the VPN under Linux (less well supported by our IT staff) just to do a couple of things that could be done other ways. Here are a couple of more interesting examples, using ssh.

One of the first things I needed to do was access our bug database, which is hosted on an internal machine. This is a very simple matter of forwarding one port to another, as follows (from my home machine, other machine names changed to protect the innocent):

$ ssh -f -L 8500:bug-database:80 my_login@revivio_dmz_host

Instead of loading “http://bug-database” I load “http://localhost:8500/” and voila! There’s my list of bugs. What’s nice about this is that it works even though (a) neither my machine nor the DMZ host at Revivio will allow me to connect to arbitrary ports from outside and (b) I couldn’t even resolve “bug-database” from my desktop. It just works because all connections except that established by the ssh command itself are within one environment (home or work) and the name resolution is done on the work side. Cool.

The one extra trick, though, is what to do with links. I did the translation from “bug-database” to “localhost:8500″myself the first time, but that won’t work for subsequent links. Enter Privoxy. I’ve written about it before and I use it anyway, so suffice it to say that it’s a trivial matter to add a filter that converts all of the links automagically. Voila again. Now, as I navigate through the bug database, everything’s being tunneled through the ssh connection and getting rewritten by Privoxy but I don’t notice. As far as I’m concerned I’m just getting my work done the same way I would in my office.

That’s fine for accessing something on the web, but what about my files? I keep most of my code and scripts on my Linux desktop, accessible via samba to my Windows desktop and via NFS to my build/test machines, but that doesn’t work from home. Sure, I could tunnel NFS through ssh from home, but as it happens I don’t have NFS installed on my home machine. I’ve implemented NFS before and I’m certainly not afraid of installing or configuring it, but this seemed like a good chance to experiment with something else I’d heard about recently: sshfs. It’s a nifty little hack based on FUSE – itself a very neat bit of filesystem technology – and supposedly allows you to access files on a remote system to which you have nothing but ssh access. Sounds like a perfect fit, but does it live up to expectations? I’m happy to report that it does. After fetching and installing the appropriate packages (nothing too awful) and without needing to reboot, here’s the incantation I used:

$ ssh -f -L 8600:my-desktop:22 my_login@revivio_dmz_host
$ sshfs -p 8600 my_login@localhost:/sandbox ~/work

For the third time, voila! There are my files, right in my ~/work directory, ready for me to work on. That’s pretty darn slick. Just a few pieces of the right technology, and working from home really is about as convenient as being in the office.