When I am developing a website, I usually use at least two machines. I have a workstation where I do developing and testing, and a separate production server, which is accessed by the public. When I am finished making changes to the development version of the website, I move it over to the production server for testing there. However when I do this, I usually don't copy it immediately over the existing production version, because there are sometimes issues with Perl modules which haven't been installed on the server, or other issues which break the code on a different machine. So I use a separate virtual server and subdomain (which is easy if you run your own DNS) to test the new version. For example if the production version of the server is at www.mydomain.com, then I might do testing on the production server under test.mydomain.com, or beta. or whatever subdomain you like. This means you have to create a new virtual server in the httpd.conf file. You also obviously create a new directory for the test server (see below for an example).

When you do all this, you end up with a very nice, isolated testing environment on the same server as production. Obviously you hopefully did all your major testing on your workstation, where you can crash the machine and it doesn't matter too much. The production server testbed is a last staging area before production, to get rid of any lingering glitches or omissions. When you're sure it's all working correctly you just copy the files from one directory tree (test) to another (production) on the same machine. This test server can also be used as a beta of the new production version. Friendly users can be given access to the new version, while the old version is still running.

One issue that comes up when you do this is that of databases. It is very likely that you will be using a special test database rather than the live one to test your new version. It would be very unwise to use a production database for testing. So your production database might be called "mydatabase", and the test one called "mydatabase_test". This is fine, but it means that you have to remember to change the database name in your code when you copy the files over to production. This is very error prone. The solution is to set variables like the database name in httpd.conf, by setting an environment variable. You just add it to the virtual server section.

Here is a real example of two virtual servers on the same production machine, which use two different directories, separate log files and different databases. The website is crazyguyonabike.com, which is a journal of a bicycle ride I did across America in 1998. I decided to expand the site to allow other cyclists to upload their own journals, which resulted in substantial changes to the code. I wanted to keep the original site up while testing the new version, which I put under new.crazyguyonabike.com. Here are the relevant apache settings:

/etc/apache/httpd.conf

# The production server <VirtualHost 10.1.1.2:80> ServerName www.crazyguyonabike.com SSLDisable ServerAdmin neil@nilspace.com DocumentRoot /www/crazyguyonabike/com/htdocs DirectoryIndex index.html ErrorLog /www/crazyguyonabike/com/logs/error_log TransferLog /www/crazyguyonabike/com/logs/access_log ErrorDocument 403 / ErrorDocument 404 / PerlSetEnv WEBSITE_DATABASE crazyguyonabike PerlSetEnv WEBSITE_ROOT /www/crazyguyonabike/com/htdocs PerlSetEnv EMBPERL_DEBUG 0 PerlSetEnv EMBPERL_ESCMODE 0 PerlSetEnv EMBPERL_OPTIONS 16 PerlSetEnv EMBPERL_MAILHOST mail.nilspace.com PerlSetEnv EMBPERL_OBJECT_BASE base.html PerlSetEnv EMBPERL_OBJECT_FALLBACK notfound.html </VirtualHost>

<VirtualHost 10.1.1.2:80> ServerName crazyguyonabike.com Redirect / http://www.crazyguyonabike.com </VirtualHost>

# Set EmbPerl handler for main directory <Directory "/www/crazyguyonabike/com/htdocs/"> <FilesMatch ".*\.html$"> SetHandler perl-script PerlHandler HTML::EmbperlObject Options ExecCGI </FilesMatch> </Directory>

# The test server <VirtualHost 10.1.1.2:80> ServerName new.crazyguyonabike.com SSLDisable ServerAdmin neil@nilspace.com DocumentRoot /www/crazyguyonabike/com/new Alias /pics /www/crazyguyonabike/com/pics DirectoryIndex index.html ErrorLog /www/crazyguyonabike/com/logs/new_error_log TransferLog /www/crazyguyonabike/com/logs/new_access_log ErrorDocument 401 /user/register/ ErrorDocument 403 / ErrorDocument 404 / PerlSetEnv WEBSITE_DATABASE crazyguyonabike_new PerlSetEnv WEBSITE_ROOT /www/crazyguyonabike/com/new PerlSetEnv EMBPERL_DEBUG 0 PerlSetEnv EMBPERL_ESCMODE 0 PerlSetEnv EMBPERL_OPTIONS 16 PerlSetEnv EMBPERL_MAILHOST mail.nilspace.com PerlSetEnv EMBPERL_OBJECT_BASE base.html PerlSetEnv EMBPERL_OBJECT_FALLBACK notfound.html </VirtualHost>

# Set EmbPerl handler for new directory <Directory "/www/crazyguyonabike/com/new/"> <FilesMatch ".*\.html$"> SetHandler perl-script PerlHandler HTML::EmbperlObject Options ExecCGI </FilesMatch> </Directory>

# Restrict access to test server <Directory /www/crazyguyonabike/com/new> AuthType Basic AuthName CrazyTest Auth_MySQL_DB http_auth Auth_MySQL_Encryption_Types Plaintext require valid-user PerlSetEnv EMBPERL_OPTIONS 16 PerlSetEnv EMBPERL_MAILHOST mail.nilspace.com </Directory>

Note that the test and production servers each get their own databases, directories and log files.

You can also see that I restrict access to the test server (which is generally wise, unless you actually like hackers potentially screwing with your head while testing). For basic authentication I use mod_auth_mysql, which is available from the MySQL website. It is nice because it allows you to authenticate based on a MySQL database.

When you use PerlSetEnv to pass in variables, you access these variables in your code as follows:

$db_name = $ENV{WEBSITE_DATABASE};

If you move those constants which differ between the test and production versions of the same code into the httpd.conf file, then you can just copy the files over from the test directories to the production directory without any alterations. This cuts down on editing errors and also documents specific constants in one place.