May 2006 Archives

I am getting slammed by comment spam right now, so I'm turning them off until either the spammers go away, or until I can find some kind of upgrade for my movable type. Sorry.

I used OpenVPN about 2 years ago to connect our US development office with our engineering lab in Bangalore, India. Unfortunately, the dual-site development thing didn't work out, and I haven't used OpenVPN since. But recently I was faced with creating a secure yet inexpensive (read: free) remote access solution for my wife's medical practice. The doctors are, shall we say, not major computer geeks. So an ssh tunneling system, while it would work, would be too difficult to explain, and be too prone to human error. I remembered OpenVPN, and thought it might work well. I was heartened to see that OpenVPN now has a bunch of GUI clients, which will make setup a lot easier. First, I had to set up port forwarding from the Linksys router to the Linux server where I would run the OpenVPN server. This was a simple matter of setting port 1194 to forward from the internet to the internal IP address of the Linux server. Ideally, I would have made the internal network of the office something that would not collide with common home routers (usually 192.168.x.x). But the office net was already set up as 192.168.1.x, so I'm going to have to work around that by changing people's home routers to be something else. Once that was done, I built openvpn from source, installed on the linux machine and created a local certificate authority. The OpenVPN documentation and scripting in this area has greatly improved in the last two years. In the server.conf, I enabled the TUN device only, since I'm only dealing with IP protocols. Aside from that, the interesting parts of the server.conf were:

# I picked 10.68.0.0/24 as my VPN subnet, since it is unlikely to collide
# with anything.  
server 10.68.0.0 255.255.255.0
# allow clients to see the rest of the office subnet
push "route 192.168.1.0 255.255.255.0"

Then I created client config files that match. Interesting parts of the the client.conf:

# this is the outside address of the office
remote office.example.com 1194
# these are the key files. I call them the same thing on all
# client machines; I then give each doc a different client key and cert
ca ca.crt
cert client.crt
key client.key

I used both the OpenVPN GUIs for Macintosh and Windows. They worked great except for one problem: the clients could only see the openvpn server machine and nothing else on the office subnet. I knew it was a routing problem, but I couldn't figure out what. First I had to put a route on the office Linksys router, so that machines on the subnet would route packets for 10.68/24 to the openvpn server, instead of out the internet. I figured I was home free once I saw that you could actually do this on the linksys. But no! Packets dropped into the void somewhere between the clients and the LAN machines. I did some more reading of the doc, and found the missing link. And a little light flicked on in my dim noggin. This was the same (and final) problem I had struggled with two years ago. To wit, on the server I needed:

echo 1 > /proc/sys/net/ipv4/ip_forward

Once IP forwarding was enabled, everything worked like a charm.

My friend julie pointed me at this package. Possible recommendation for mom and sister, looks like nice simple backup solution for mac.

I just upgraded my Ubuntu box to the latest beta. I ran into the same problem I ran into when I first installed the last release, and I could not remember the fix. So I'm writing it down so I won't forget. Ubuntu disables network socket connections to the X11 server by default. For "security" reasons. (Um, I thought that's what xhost access control was for...)

Anyway, you can fix the problem by editing /etc/X11/gdm/gdm.conf and changing

DisallowTCP=true

to

DisallowTCP=false

This is hilarious, a short film about video game characters that are self aware: Deviation.

"How much more black could it be? The answer is none. None more black."

The new consumer-grade Apple notebook computer, the MacBook, is available in black or white. However, as far as I can tell, the black one is $1499, and the white one is $1299. The only difference aside from the color is that the black one comes with a 20GB bigger hard disk. But you can upgrade the white one to the same hard drive for $50.

So being stylish will cost you $150. That's either very clever or very stupid. There's such a fine line between the two.

We use memcached at work to vastly reduce load on the application servers and on mysql. The problem is that on Mac OS 10.4 Tiger it was so slow as to be worse than not using it: one query would take 5 seconds, instead of like 5 milliseconds on Linux. It was never a huge deal, because we deploy on Linux, and there are lots of Linux machines around the office. But it made it hard to run a self-contained deployment environment on the developer's Mac. My friend Derek found this article, which details the fix. I tested it, and it works for me. Super short summary: Edit memcached.c and add (anywhere above line 105, which reads #ifdef TCP_NOPUSH) the line: #undef TCP_NOPUSH Then make install setenv EVENT_NOKQUEUE 1 /usr/local/bin/memcached -m 128 -p 11211

When I debug web sites (something I'm sure everybody does, right?), I like tools that let me look at the HTTP headers and such. Too what cookies actually are set, etc. One tool I liked was the Live HTTP Headers FireFox extension. Jeff just showed me an even better one: Tamper Data. It basically does the same thing, but there are two big differences.

First, it's formatting of the data is vastly better: there is a table of entries for each request with performance and summary data. This lets you figure out where your pages are fat: like included images or js or whatever. Then you can click on each request to find out more.

Second, you can go into "tamper mode," where you can edit the requests coming from your browser before they get to the server. This can be very handy.