Netz - Rettung - Recht

Erneut war ich positiv über die geringe Zahl von Änderungen in conffiles überrascht; insgesamt verlief das Upgrade auch grundsätzlich problemlos. Es “hakte” dann aber im Vergleich zu früheren Upgrades doch ungewohnt oft - jedenfalls für Debian, das normalerweise nach meiner Erfahrung einen nahezu hindernisfreien Upgrade-Pfad bietet.

Konkrete Einzelfallprobleme

Es begann damit, dass das initiale Upgrade und das folgende Dist-Upgrade nicht ohne Schwierigkeiten durchliefen, sondern abbrachen und mehrfach neu gestartet werden mussten; ohne längere Suche im Log kann ich den Grund dafür gar nicht benennen, was letztlich aber auch egal ist - solange am Ende das Upgrade durchläuft, soll’s mir recht sein.

Ganz tat es das allerdings nicht; die Datenbank-Upgrades von phpMyAdmin und Roundcube scheiterten, weil der Datenbank-Server nicht richtig lief. Das wiederum lag darum, dass das Upgrade / die Umstellung von mySQL auf MariaDB nicht vollständig funktioniert hatte:

mysqld_safe[6933]: 2017-09-01 13:52:40 139724014662208 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
mysqld_safe[6933]: 2017-09-01 13:52:40 139724014662208 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 6959 ...
mysqld_safe[6933]: 
mysqld_safe[6933]: Installation of system tables failed!  Examine the logs in
mysqld_safe[6933]: /var/lib/mysql for more information.
mysqld_safe[6933]: 
mysqld_safe[6933]: The problem could be conflicting information in an external
mysqld_safe[6933]: my.cnf files. You can ignore these by doing:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/scripts/scripts/mysql_install_db --defaults-file=~/.my.cnf
mysqld_safe[6933]: 
mysqld_safe[6933]: You can also try to start the mysqld daemon with:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/sbin/mysqld --skip-grant --general-log &
mysqld_safe[6933]: 
mysqld_safe[6933]: and use the command line tool /usr/bin/mysql
mysqld_safe[6933]: to connect to the mysql database and look at the grant tables:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/bin/mysql -u root mysql
mysqld_safe[6933]:     mysql> show tables;
mysqld_safe[6933]: 
mysqld_safe[6933]: Try 'mysqld --help' if you have problems with paths.  Using
mysqld_safe[6933]: --general-log gives you a log in /var/lib/mysql that may be helpful.
mysqld_safe[6933]: 
mysqld_safe[6933]: The latest information about mysql_install_db is available at
mysqld_safe[6933]: https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
mysqld_safe[6933]: MariaDB is hosted on launchpad; You can find the latest source and
mysqld_safe[6933]: email lists at http://launchpad.net/maria
mysqld_safe[6933]: 
mysqld_safe[6933]: Please check all of the above before submitting a bug report
mysqld_safe[6933]: at http://mariadb.org/jira
mysqld_safe[6933]: 

Ich mutmaße, dass die Rechte in /var/lib/mysql nicht ganz stimmten - was auch immer. Mehrere Versuche mit mysql_upgrade und /usr/bin/mysql_install_db --defaults-file=~/.my.cnf waren jedenfalls schlussendlich erfolgreich; die Einzelheiten habe ich nicht debugt.

Änderungen für bestimmte Softwarepakete

Abgesehen von dem vorstehend geschilderten Einzelfallproblem ergeben sich einige generelle Merkpunkte, die ich auch beim Upgrade meiner anderen Maschinen im Blick behalten werde:

• Der Account uucp bekam - wie beim Upgrade auf Jessie - wieder /usr/sbin/nologin als Shell verpasst.

• fail2ban startete nicht mehr, weil in der /etc/fail2ban/jail.local ein nicht mehr existenter Filter aktiviert wurde. Nach Berichtigung der Konfiguration ließ sich der Dienst problemlos starten.

• Der isc-dhcp-server startet jetzt per Default für ipv4 und ipv6; jedenfalls bei mir fehlte ihm aber für letzteres die passende Konfiguration, so dass er mit einer Fehlermeldung stehenblieb. Das bisherige Verhalten lässt sich wiederhestellen, indem man in /etc/default/isc-dhcp-server folgendes setzt: INTERFACES="eth0". Da aber INTERFACES offenbar demnächst wegfällt, kann man es auch direkt richtig machen und stattdessen INTERFACESv4="eth0" setzen.

• Wer duply und duplicity für sein Backup nutzt, muss aufgrund der neuen Version von gpg die Konfiguration anpassen: in der conf-Datei ist zu setzen: GPG_OPTS='--pinentry-mode loopback'

• offlineimap verifiziert jetzt TLS-Zertifikate, will also immer dann, wenn ssl = yes in der Konfiguration gesetzt ist (aber wohl auch dann, wen SSL jedenfalls möglich wäre), entweder den Pfad zu den Root-Zertifikaten angegeben haben (wenn die Gegenstelle ein Zertifikat einer anerkannten CA hat) oder den Fingerprint des Zertifikats (wenn es sich um ein selbst-signiertes handelt). Zum jeweiligen remotehost gehört also entweder sslcacertfile = /etc/ssl/certs/ca-certificates.crt oder cert_fingerprint = ....

• Außerdem müssen bei offlineimap Sonderzeichen in Passworten - konkret hier % - teilweise gequoted werden (konkret hier als %%).

• Jedenfalls wenn bei offlineimap das Feature Name translation genutzt wird, muss überdies die Konfiguration auch insoweit angepasst werden - offlineimap synchronisiert Folder jetzt beidseits, was beim Umschreiben von Foldernamen zum Chaos führen kann, weil externe Folder lokal anders heißen und dann ggf. unter ihrem lokalen Namen neu auf den entfernten IMAP-Server synchronisiert würden. Die Name translation muss daher beidseits erfolgen, daher auch für das lokale “Repository” (“Reverse namentrans”). Der Aufruf von offlineimap --info kann beim Debugging hier sehr hilfreich sein.

• Wer gitolite genutzt hat und nun auf gitolite3 umstellen will, wird jedenfalls die bisherige Konfiguration übernehmen bzw. anpassen müssen und muss auf den Clients im Auge behalten, dass der lokale Benutzer auf dem Server jetzt nicht mehr gitolite, sondern gitolite3 heißt. (Ob es einen automatisierten Upgrade-Pfad gibt, wenn man gitolite3 nachinstalliert, kann ich nicht sagen, weil ich so “klug” war, erst das gitolite-Paket zu entfernen und dann gitolite3 zu installieren …)

Hinweis: In den Kommentaren finden sich noch Ergänzungen, auf die ich später gestoßen bin. So muss man als Nutzer von suck daran denken, den Injection-Info:-Header auszufiltern, und wer noch DSS-Keys für (automatisierte) SSH-Verbindungen nutzt, sollte im Blick haben, dass ssh-dss nicht mehr zu den PubkeyAcceptedKeyTypes gehört.

Neue Software und geänderte Defaults

• vim hat per Default ärgerlicherweise eine aktivierte Maussteuerung verpasst bekommen, die sich zudem (aufgrund der Reihenfolge, mit der die Konfigurationsdateien eingelesen werden) nicht systemweit deaktivieren lässt, sondern zumindest eine leere ~/.vimrc für jeden Nutzer erfordert (weil sonst stattdessen /usr/share/vim/vim80/defaults.vim geladen wird, und zwar zur selben Zeit wie sonst die .vimrc und damit nach /etc/vim/vimrc.local). Alternativ kann man das Laden der defaults.vim in /etc/vim/vimrc deaktivieren (wenn man dieses conffile um den entsprechenden, auskommentierten Inhalt ergänzt hat, wie beim Upgrade vorgeschlagen). Für die Einzelheiten sehr informativ ist hier der entsprechende Bugreport.

• Mit Debian Stretch kommt PHP7; es mag sich daher empfehlen, PHP5 zu deinstallieren. Außerdem wird man im Zweifel spätetens jetzt auf php-fpm umstellen wollen.

Zusammenfassung

Das Upgrade verlief - in einer Gesamtbetrachtung - ohne echte (reproduzierbare) Fehler, erforderte aber ungewöhnlich viel manuellen Nacharbeit. Andererseits wurden zumindest manche Punkte vermutlich im jeweiligen NEWS-Eintrag angesprochen (ich muss gestehen, ich lese die Upgrade-Anleitung immer sehr genau, aber NEWS habe ich bisher allenfalls überflogen - keine gute Idee), und meine Konfiguration hier zuhause ist eher komplex und historisch gewachsen; eine schlechte Kombination.

Weitere Hinweise zum Upgrade gibt es auch in Jonathan McDowell’s Blog.