lsmod | grep stupiduser
It all started so simply.
It occurred to my yesterday that it might be nice to be able to conveniently lay my hands on some local data and media while away from home. Sounds simple enough, right? That’s what SSH is for. So this morning, over coffee, I boot up the big beige box that’s been lurking, abandoned, under the spare desk in the office. Immediately, my sensibilities are affronted: that crufty old Fedora Core install was so two years ago. It had to go. Besides, I wanted lean and mean for this application, something that could run five nines on hardware that wheezes audibly even when powered off.
Twenty minutes and another cup of coffee later, Ubuntu Server 8.10 is settling into its cozy new home. Now what? Well, SSH first, naturally. After all, what fun is server administration if you have to sit in front of the actual server the whole time? Then came Fuse/sshfs, AutoFS, and SAMBA. Then my old buddy Vim and I put in some quality time together, and, when the dervish of config files had subsided, we were cooking with gas.
Sort of.
Except that two of the Windows machines wouldn’t talk to the server, and one of them was invisible to every other host on the network, despite the fact that they’d all been chatting happily just the day before. After what was certainly no more than 45 minutes and fifteen reboots, everyone was playing nicely, and it was freshly mapped network drives all around. Then I was free to focus on the actual ‘remote accessibility’ aspect of this remotely accessible server.
Have I mentioned that it was nearly 11:00 AM now?
At this point, ominous phrases like ‘dynamic IP’, ‘NAT’, and ‘multiple virtual hosts behind two different routers’ began to chime in my head. Fortunately, there was one cuppa left, and I was able to steady my nerves long enough to not only acquire a DynDNS account, but to also invoke enough iptables voodoo to make everything map reasonably sanely. If you squint a little. Not, of course, that I could tell without first hopping on the neighbor’s WiFi, because I failed my Diplomacy check and couldn’t convince the external router to let me reach the WAN address from inside the network.
So now I’m on a roll. Over my turkey sandwich, I start thinking: Ok, so, SSH, scp, etc, etc are good, and they’ll do for quick-and-dirty operations. But–and call me spoiled if you must–I like a little polish in my workflow. I’ve got a spankin’ new network back in the fortress of solitude, and meanwhile me and my trusty portable dual-core steed are riding the lonesome trail. What I’d like to do is tunnel back into the local network and, via SAMBA, keep my drives mounted just like they were when I left home. Well, it’s fine and good to do that–to simply tunnel ports 139 and 445, if I’m on a Windows box–and let it go at that. The problem is that that b0rks Windows filesharing over any other peer-to-peer net you might be on. Like, say, the one in the lab. That I use all the time.
So I do some googling, and the first three or four promising hits mention things like installing virtual network interfaces. Yawn. Then it hits me that I’ve got a JeOS server appliance running in the background on the laptop anyway. Could I maybe…
Nah. That’s too crazy, even for me.
But out of sheer morbid curiosity, I ask the internets.
Sure enough, I’m not the only one to have thought of it.
Remember the sshfs install earlier? That’s going to come into play here. What I decided to do is this: I use Fuse on the JeOS appliance to remotely (and securely) tunnel to and mount the germane drives on the gateway server, which are in turn simple CIFS mounts of the same network resources I would have access to behind the firewall. Then, I install another SAMBA server–again on the JeOS device–that will share the net-mounted drives with the host laptop,
When you stop laughing, I’ll go on.
Ideally, I would then fall back on some Powershell scripting goodness on the Windows side and some preexec/postexec handwavery Linux-ward to make the the mounting and transitioning as seamless and transparent as possible.
Ideally.
In reality, what happened was that everything worked fine up until I had to reboot JeOS a few times and there somehow came to be issues with the known_hosts file, making SSH panic comically. Then there were problems with NTLM and login-mode compatibility. Then I found out the fun way that running a VMWare appliance in NAT mode–ie, with both of those clever virtual network interfaces running–means that Vista is bloody well determined that you are on an unidentifiable netowork, say what you will. This means, of course, that the ever-helpful firewall slams shut, and alas, no filesharing. Two quick registry tweaks later, and that was more or less straightened out.
…by which time it was nearly 5:00, and I had completely forgotten just why it was that I wanted remote access to my network anyway.
Home networking: my anti-job.
**EDIT**
I realized as I was falling asleep last night that VMWare Workstation has guest-to-host virtual drive sharing capabilities. So much for that extra SAMBA server.


RSS - Posts