I followed my usual upgrade approach, which involves upgrading a backup of the root FS of the server in a container, to test the upgrade path, followed by a config file merge.
I had one major problem, though, connecting to my php based Dokuwiki subsole.org website, which displayed a rather unwelcoming screen after the upgrade:
I was a bit unsure at first, as I thought I would need to fight my way through the nine different config files of the dokuwiki debian package in /etc/dokuwiki
However the issue was not so complicated: as the apache2 php module was disabled, apache2 was outputting the source code of dokuwiki instead of executing it. As you see, I don't php that often.
A simple
a2enmod php7.3
systemctl restart apache2
fixed the issue.
I understood the problem after noticing that a simple phpinfo() would not get executed by the server.
I would have expected the upgrade to automatically enable the new php7.3 module, since the oldstable php7.0 apache module was removed as part of the upgrade, but I am not sure what the Debian policy would recommend here, or if I am missing something else.
If I can reproduce the issue in a upgrade scenario, I'll probably submit a bug to the php package maintainers.
1 comment:
I would say this is a booby trap that should be reported as a bug. Apache maintainers should, in the same file that disables access to .ht* and .svn, disable access to PHP files if neither the PHP module nor the fastcgi php-fpm configuration are in place.
Post a Comment