I recently upgrade this (and several client servers) over to the latest release of Debian (Debian Jessie). This process went relatively smoothly apart from a couple of gotchas that came when Apache got upgraded.

One of the problems I had is that mod_python and WSGI no longer sit happily together (unless you go through some complicated rebuilding of Python, which I was unwilling to do). I needed WSGI for various things on the server, and seeing as mod_python is viewed as deprecated these days, and I only used it for trac, it made sense to migrate this.

Thankfully, this is relatively straightforward to accomplish.

Create your WSGI script

The first step is to create a python executable called trac.wsgi in your trac home directory, which you then make executable touch trac.wsgi; chown www-data:www-data trac.wsgi; chmod 700 trac.wsgi

The script will look something like:

I use one domain to host all the various trac installs, therefore this one wsgi script needs to power them all. This is what the TRAC_ENV_PARENT_DIR does. Both TRAC_ENV_PARENT_DIR and PYTHON_EGG_CACHE can take their values from the existing ones you’ve presumably already set in the apache conf (assuming you’ve already got this working with mod_python).

Updating your Apache configuration

Edit your Apache configuration and comment out or remove all the mod_python entries, e.g.

You now need to add a WSGIScriptAlias directive for whatever your TracUriRoot currently is, and modify your Directory statement to add a WSGIApplicationGroup directive, as follows:

Load WSGI

Finally, activate your module: apt-get install libapache2-mod-wsgi; a2enmod wsgi

I have previously written about using Git to add revision history to existing rsync backups. Having performed a number of configuration changes and system upgrades recently, I have found another use of Git which has proven invaluable.

It’s a fairly obvious hack, but it turns out that turning selected configuration directories (for example /etc/apache2/ and /etc/exim4/) into in situ Git repositories is a very handy thing to do.

The revision log you get in a Git repo gives you a very handy place to note down the reasons behind a certain configuration change. This provides a very handy historical context for a change, meaning you’re less likely to remove something odd that turns out later on to have been important.

Having configuration under version control also means that even if you do accidentally remove or change something that later causes problems you can easily roll them back.

Another handy feature is the ability to easily branch, so you can very quickly experiment with some wild configuration settings and very quickly revert them to the original working configuration should they turn out to be problematic or if you run out of time to complete them.

So, give it a try!