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.


Ooooooo… boy.

Biggest hitter by far for me was that Debian 9 now ships 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.

Gitosis is a GIT server system which, using ssh, lets you run a central git repository in much the same way as github does. This let you manage multiple developers easier, as well as providing a convenient place to access repositories while out and about, and for deployment.

Unfortunately, gitosis is no longer maintained, and has been removed from more recent versions of the major linux distributions. This was preventing me from performing some much needed server upgrades, so it was therefore necessary to migrate to another bit of software.

Gitolite is the recommended replacement for Gitosis, and acts as a drop in replacement. Perform the migration right, and you’re users will never notice that you did anything at all.

So, in hopes that this may be useful to someone, here’s how I migrated my gitosis server over.

The initial setup

The initial server configuration was as follows:

  • Debian server
  • Gitosis installed as user “git”

My goal was to replace the gitosis server, still on the GIT user, so my users would not need to modify any of the remote repository paths in any checked out repositories.


Start off by taking a backup, just incase this goes horribly wrong, then…

  1. Belts and braces, get rid of the old gitosis update hooks and prevent any new sessions by removing the authorized_keys file: mv git/repositories/gitosis-admin/hooks/post-update git/repositories/gitosis-admin/hooks/post-update.old; mv git/.ssh/authorized_keys git/.ssh/authorized_keys.old
  2. Move the old gitosis home directory out of the way: mv git git_old
  3. Install gitolite: apt-get install gitolite
  4. I then needed to reconfigure gitolite so it used the same user id as the previous gitosis install: dpkg-reconfigure gitolite
  5. Copy your old repositories to your newly created git directory: cp -a git_old/repositories git/
  6. Gitolite had trouble using my existing public ssh keys for the admin account, probably because they were already used as login keys, or perhaps because they were in the foo@bar.pub format. Either way, the simplest thing was to generate an admin key specifically for gitolite administration.
    1. Generate a new key, making sure you have at least one “.” after the “@”, so that the key looks like an email address: ssh-keygen -t rsa -C "gitoliteadmin@myserver.local" -f gitoliteadmin@myserver.local
    2. Make sure root, or whoever is going to admin your gitolite repo has a copy of these keys, as you’ll need them to make any configuration changes. You can simplify this somewhat by making a host alias for the gitolite admin user in the ~/.ssh/config file

      Host gitolite-admin
          HostName myserver.local
          User git
          IdentityFile ~/.ssh/gitoliteadmin@myserver.local

  7. On the server, change to the git user: su git
  8. Then initialise the gitolite repository, passing the location of your newly created admin key: gl-setup /path/to/gitoliteadmin@myserver.local
  9. Clone the gitolite-admin repository, note the use of the gitolite-admin host repository: git clone git@gitolite-admin
  10. Convert your gitosis settings file using gl-conf-convert, which if you’re running this on the server, can be found in /usr/share/gitolite. This script can be run in isolation, so it’s ok to copy it about if you need to run this on a different machine: /path/to/gl-conf-convert < /path/to/gitosis-admin/gitosis.conf >> /path/to/gitolite-admin/conf/gitolite.conf
  11. Now, check your gitolite.conf for errors, and if ok commit and push your changes. Since I had a number of keys in the format of user@machine, I had to change the occurrence of those users in the file to just the username before the “@” character. E.g. foo@machine becomes just foo
  12. Things should now be working on gitolite. You can verify that gitolite rather than gitosis is fielding your requests using ssh: ssh git@myserver.local info, you should see a list of the repositories on the server that your user has access to.

All being well, your migration over to gitolite should now be complete, and remotes in any existing clones of repositories on the server should still function.

Hope this helps!