So, I’ve been using ownCloud for a while now as a convenient way to share certain files between all of my various devices. The server is a PHP application, so it’s pretty easy to set up.

Anyway, I updated my server to use PHP 7.3, in order to run the latest Known code, among other things. PHP 7.3 is the latest stable code, and so is what everyone should be running, really.

This presented a bit of a problem, as ownCloud would only run on PHP version up to and including 7.2! The next version of ownCloud will apparently support PHP 7.3, however release schedules are slow, and I really needed to get my syncing up and running again.

The obvious solution would be to run PHP 7.2 for the ownCloud server, and then PHP 7.3 for everything else.

Installing PHP-FPM

If you’re running the old school mod_php apache module, the first thing you need to do is install PHP-FPM.

I had been meaning to do this anyway, as this is essentially the modern way of running PHP. It’s faster, gives you many more options for performance, and crucially for my purposes, decouples Apache from PHP meaning you have the option of running multiple versions.

On Debian based servers (mine is Debian, with a third party PHP 7.3 apt repository set up), this turns out to be incredibly easy:

You’ll also want to install all the PHP modules you need (pdo, gd, etc), but I’ll leave that as an exercise for the reader.

Next, you want to switch over your config:

Two things to note here. Firstly, replace the a2dismod statement with whatever php version you currently have installed. Secondly, you’ll notice I didn’t enable the PHP 7.2 FPM config. This is because I want PHP 7.3 to be the default for all sites, but to be able to selectively enable PHP 7.2 on selective virtual hosts.

Checking phpinfo() should now show you something like this:

Note the PHP version and the Server API.

If you look at your server processes, you’ll also see both PHP 7.3 and PHP 7.2 FPM servers running:

# ps aux | grep php
root      1437  0.0  0.2 601224 34420 ?        Ss   Sep14   0:03 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
www-data  1936  0.2  0.7 685708 113000 ?       S    15:05   0:19 php-fpm: pool www
www-data  6650  0.2  0.7 688600 122332 ?       S    09:04   1:08 php-fpm: pool www
www-data  6657  0.2  0.7 687132 125016 ?       S    09:04   1:12 php-fpm: pool www
root      7658  0.0  0.2 591404 32916 ?        Ss   Sep14   0:03 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
www-data 19281  0.1  0.3 673936 51792 ?        S    Sep14   2:16 php-fpm: pool www
www-data 19289  0.1  0.3 673836 49044 ?        S    Sep14   2:17 php-fpm: pool www
www-data 19290  0.1  0.3 673936 49760 ?        S    Sep14   2:18 php-fpm: pool www
root     21084  0.0  0.0 132340   924 pts/0    S+   17:01   0:00 grep php

Configuring ownCloud’s VirtualHost to use PHP 7.2

So, now you need to modify your ownCloud VirtualHost to use the PHP 7.2 fast CGI server.

Again, this is really really easy, and is pretty much a cut and paste from the php7.2-fpm.conf file you’ll find in your /etc/apache2/conf-available directory.

Place the following somewhere in your ownCloud virtual host definition:

<FilesMatch ".+\.ph(ar|p|tml)$">
SetHandler "proxy:unix:/run/php/php7.2-fpm.sock|fcgi://localhost"
</FilesMatch>

Now, when you run a phpinfo() on your ownCloud domain, you should see it running PHP 7.2!

Now I can get back to syncing my files, while running the latest PHP version for other domains.

This is a useful feature, and obviously can be used to get more than just slow to update software up and running. For a start, this technique will let me run a bleeding edge version of PHP like PHP 7.4 against, for example, my development version of Known, but keep my blog running the stable release.

Anyway, I thought this was cool. Hopefully you’ll find it useful too!

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 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.