Eine Sammlung an Notizen zum release upgrade von 14.04 LTS auf 16.04.1 LTS oder: Was alles zerbrach, wie es zu heilen war und was noch ungelöst verbleibt.
phpMyAdmin
Schon während des Upgrades konnte das Paket phpmyadmin für Xenial nicht konfiguriert werden. Die angezeigten Fehlermeldungen verwiesen auf dieses Problem, das sich allerdings im Zuge des Upgrades nicht rund umsetzen ließen. Also blieb phpmyadmin unkonfiguriert.
Unter Xenial habe ich mir mit apt-get purge phpmyadmin ; apt-get install phpmyadmin das Paket frisch an Bord geholt.
Begrüßt wurde ich dann von einer schier unendlichen Anzahl von Deprecation Notices nach dem Muster
Deprecation Notice in ./../php/php-gettext/streams.php#48 Methods with the same name as their class will not be constructors in a future version of PHP; StringReader has a deprecated constructor Backtrace ./../php/php-gettext/gettext.inc#41: require() ./libraries/select_lang.lib.php#477: require_once(./../php/php-gettext/gettext.inc) ./libraries/common.inc.php#569: require(./libraries/select_lang.lib.php) ./phpmyadmin.css.php#14: require_once(./libraries/common.inc.php)
Weder gettext noch mbstring (wie in einigen Threads zum Problem behauptet) lösten das Problem. Dieser Hinweis war für mich der richtige:
error_reporting = E_ALL & ~E_DEPRECATED
Pydio
Pydio meinte, es hätte unter Xenial keine MySQL Verbindung mehr. Das Problem ist wohl bekannt, die Lösung sieht bei mir so in der $PYDIOINSTALLDIR/data/plugins/boot.conf/bootstrap.json aus:
"DIBI_PRECONFIGURATION":{
"mysql_username":"pydiodbuser",
"mysql_password":"pydiodbpasswort",
"mysql_host":"localhost",
"mysql_driver":"mysql",
"mysql_database":"pydiodbname",
"group_switch_value":"mysql",
"mysql_use_mysqli":"true"
}
Danach läuft auch ein Update auf die nächste Pydio-Version reibungslos durch.
ownCloud
ownCloud startete nicht mehr, weil einerseits memcache nicht funktionierte (unter php7 eigentlich nicht verwunderlich) und weil die PHP Module php-zip, php-memcached, php-redis und php-curl fehlten. Die waren zwar unter Trusty schon einmal an Bord, aber gingen im Laufe des Upgrades wohl verloren. Ich sollte an dieser Stelle wohl eh umsteigen auf APCu.
DokuWiki
Viele Plugins von Dokuwiki werfen mit Fehlermeldungen im Muster
PHP Warning: Declaration of syntax_plugin_gcalendar::render($mode, &$renderer, $indata) should be compatible with DokuWiki_Syntax_Plugin::render($format, Doku_Renderer $renderer, $data) in /pfad/zu/dokuwiki/lib/plugins/gcalendar/syntax.php on line 0 PHP Warning: Declaration of syntax_plugin_include_div::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /pfad/zu/dokuwiki/lib/plugins/include/syntax/div.php on line 0, referer: https://www.domain.tld
nach dem Apachen. Hier half es, alle Plugins neu zu installieren, auch wenn diese nicht als mögliches Update von DokuWiki angezeigt wurden.
opendkim
Die Rechte auf /etc/postfix/dkim.key lagen bei root.root und verhinderten den Start von opendkim. Ein chown opendkim dkim.key stellt das richtig.
fail2ban
Die jail.local musste ich komplett überarbeiten. Der Hintergrund scheint zu sein, dass die Pfade für die Logs der einzelnen Dienste aus der jail.local bei Trusty unter Xenial nicht mehr stimmten: Einige nutzen jetzt systemd, andere schreiben weiterhin in ihren herkömmlichen Logpfad.
Außerdem zeigten sich die von mir aktivierten Apache jails extrem empfindlich gegenüber Arbeiten im Backend von DokuWiki, so lange dieses Fehlermeldungen rund um PHP7 wirft. Nach nur wenigen Klicks sperrte mich mein Server komplett aus und am Ende des Tages (und auf Grund einer von mir einst hoch festgelegten bantime) half nur der Boot mit einem über die Hetznerkonsole gestarteten Notfalllinux.