Tag Archives: debian

Posted on
by

I recently upgraded my webserver to Debian Jessie, which included an upgrade for Apache and PHP. This resulted in a few gotchas…

Mod_python and WSGI don’t play nicely

See my previous post on the subject…

Some PHP extensions not installed

Some PHP extensions didn’t seem to be automatically upgraded/reinstalled (these may have been ones previously only available through PECL), so:

apt-get install php5-gnupg php5-mongo
/etc/init.d/apache2 restart

New permissions

Apache 2.4 uses a different permissions (access / deny) arrangement than before, so you need to change these over.

So for example, where you have:

Order deny,allow
Allow from all

You’d now have:

Require all granted

Apache have a good guide here.

Random crashes with XCache

If you have XCache installed, you might start getting random crashes, often with an error about:

“`PHP Fatal error: Cannot redeclare class …“`

This is caused because the installer installs and activates the Zend Opcache module automatically, and you can’t run two opcode caches safely.

php5dismod opcache; /etc/init.d/apache2 restart

Posted on
by

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:

#!/usr/bin/python
import os

os.environ['PKG_RESOURCES_CACHE_ZIP_MANIFESTS'] = '1'
os.environ['TRAC_ENV_PARENT_DIR'] = '/path/to/trac/parent/html/'
os.environ['PYTHON_EGG_CACHE'] = '/path/to/trac/parent/cache/'

import trac.web.main
application = trac.web.main.dispatch_request

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.

#       
#               SetHandler mod_python
#               PythonInterpreter main_interpreter
#               PythonHandler trac.web.modpython_frontend
#               PythonOption TracEnvParentDir /path/to/trac/parent/html/
#               PythonOption TracUriRoot /
#
#               PythonOption PYTHON_EGG_CACHE /path/to/trac/parent/cache/
#

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:

WSGIScriptAlias / /path/to/trac/parent/html/trac.wsgi


    ...

    WSGIApplicationGroup %{GLOBAL}

    ...

Load WSGI

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

Posted on
by

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!