SSH Tunneling and Drupal 5

At last! The answer to a persistent problem that's been stymying my Drupal 5 efforts. First, some brief background for the non-techies:

A very common way of developing code for use on the web is to run a local copy of the site on your own machine's webserver while tunneling traffic to a central development database. The dev writes his code and saves it on his machine. He then points his web browser at his own machine. The web server picks up the request and runs the code. Whenever it needs to talk to the database, it does so by talking to a central DB server over an encrypted tunnel. This is made possible by SSH, a handy program that can let you securely pipe TCP traffic between servers like magic.

This is useful because when multiple people are working on a site, it's important to be able to combine their work while simultaneously preventing them from stepping on one another's toes. There are a number of well-developed tools for combining files within a project (we use Subversion). But it's very hard to have people work on separate copies of a database and then combine their work into something useful. It's much easier to just have everyone work off the same development database. It's also not as big a deal, because if someone makes an incorrect change to the database it's generally less likely to negatively affect other developers (well, unless they did something really unwise). Tunneling makes it easy for devs to keep their code separate and their databases unified.

Or it did, anyway, until Drupal 5. Suddenly my development methodology stopped working. When looking at the locally-hosted version of a site I could sometimes log in but not access restricted areas. Sometimes I couldn't log in at all. Large parts of the site worked, but there were erratic failures related to authentication and permissions. The process usually culminated in me mangling my password hash in a last-ditch effort, then being forced to reinstall Drupal. However, none of these problems occurred when I eschewed the SSH tunnel and connected directly to our central development server.

Today I finally figured out why, thanks to this post. When you've got a bunch of local development sites running you need to provide a way for your machine to tell which one to serve when you point your web browser at localhost. Making different sites run on different ports is a simple way to do this, and was in fact the technique I used. But it turns out that Drupal 5 doesn't like this, for reasons related to request_uri() that I haven't bothered to fully grok.

The upshot is that if you run your local Drupal 5 dev sites off of the same port as your central dev server, all will be well. The easiest way to do this is to use the standard HTTP port 80 and use hostnames to differentiate sites instead of ports.

Here's a quick example of how to do this (in a *nix-like environment, anyway). I added the following line to /etc/hosts:

127.0.0.1     clientname

Then configured a vhost in /etc/httpd/httpd.conf like so:

<VirtualHost clientname:80>
    DocumentRoot /path/to/client's/documentroot
    ServerName clientname
    ErrorLog /var/www/logs/error_log
</VirtualHost>

You'll have to restart your web server after making this change, but that should be it. The only other difference is that you'll access your local copy of the site by navigating to http://clientname instead of http://127.0.0.1:1234 (or whatever port you were running). It looks nicer this way, too.

The fix is Apache 101, but diagnosing the problem was decidedly harder, since most of Drupal 5 was perfectly happy to live life straddling ports. If you've moved to Drupal 5 and suddenly found your old 4.x development methodology doesn't let you log in, give this a try.