I hit a number of gotchas when upgrading my home and business web server from jessie to stretch, here they are in no particular order. Hopefully will save you some hair pulling…

Broken MariaDB install

Debian now ships with MariaDB by default, but when I upgraded mariadb-server would not install, meaning their were loads of broken dependencies. Dpkg exited with an error status, but with no indication as to what the actual error actually was.

Fixes suggested elsewhere (purging and reinstalling, moving /var/lib/mysql away and reinstalling, etc) did not help.

Eventually, I was able to manually execute mysql_install_db, which actually gave me some output. For me, the problem seemed to have been caused by the slow query logging entries, which are either unsupported in MariaDB or are named something else (I’ve not had a chance to check).

I commented out the following lines as follows:

… and apt-get was able to install the package.

Isolated /tmp

The version of systemd shipping with Debian 9 includes some security enhancements, including PrivateTmp, which isolates the temporary directory from users.

So, if you use your tmp directory to store e.g. cache data when developing websites, you’re going to need to store this somewhere else, otherwise file_exists and other file functions will not be able to read or write to them.

PHP 7

Ooooooo… boy.

Biggest hitter by far for me was that Debian 9 now shops with PHP7. Usefully, 5.6 is still available, so you have to switch to 7 manually (which means installing all the appropriate module again). Gotcha here is the mysql extension has been entirely removed, good thing too… however, if you’ve been running your server for a while like I have, you’re going to have a metric shittonne of things that need to be upgraded in order to work. Biggest pain in the bum was my ownCloud 8 server (made harder by the fact you can’t cross major versions in an upgrade, and the releases for those versions were no longer available until I nudged someone on IRC, also, pro tip, do the upgrade on PHP 5).

For scripts that either don’t have newer versions, or legacy stuff you don’t have time right now to allocate significant dev resources to, there is a mysql->mysqli shim available. This seems to work quite well in most cases, although of course it should be fairly high priority for you to migrate to PDO or similar!

Elgg and PHP 7

If you’re building sites on the 1.x.x branch of Elgg, you’re either going to have to upgrade to Elgg 2.x to run on PHP7, or use the shim.

I only have development sites running on PHP 7 at the moment, all of my clients that use < Elgg 2 are running on older PHP releases for now, but the shim works well in development and until I can manage those upgrades. If you use the shim you may need to comment out the following lines in executeQuery() in engine/classes/Elgg/Database.php:

…since the resource returned by the shim is a different type than expected.

That’s all so far, hope this will save you some stress!

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:

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:

You’d now have:

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.

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