Netz - Rettung - Recht

Konkrete Einzelfallprobleme

• Wie schon damals geschildert gab es Probleme beim Upgrade von fail2ban, weil sich die Bezeichnungen einiger Filter geändert haben, die noch unter der alten Bezeichnung in /etc/fail2ban/jail.local eingebunden waren. Dadurch endete das dist-upgrade später mit einem Fehlercode und musste neu gestartet werden, um die restlichen Pakete zu initialisieren. Nach dem ersten Durchlauf habe ich das dadurch behoben, dass ich schon vor dem Upgrade statt des Filters ssh den Filter sshd und statt apache den apache-auth eingebunden habe.

• Auch das Upgrade von phpMyAdmin verlief nicht störungsfrei; das Update der Datenbanken lief in einen Fehler (die Datenbankdateien seien korrumpiert) und ein entsprechendes debconf-Prompt. Es stellte sich heraus, dass ein Aufruf von /usr/bin/mysql_upgrade notwendig war, den ich dann in einem anderen Terminal vorgenommen habe; danach lief das Upgrade durch. Bei den anderen Servern habe ich dann schon beim ersten Prompt wegen des Updates der phpMyAdmin-Datenbanken in einem anderen Terminal /usr/bin/mysql_upgrade gestartet; das Upgrade lief dann problemlos.

• In manchen Fällen wurde der mySQL-Server nach dem Upgrade nicht richtig neu gestartet. Ein service mysql restart behebt das, wenn man nicht ohnehin zeitnah rebootet.

Solche Probleme sind bei Debian-Updates ungewöhnlich, waren aber gut managebar; dafür lief an der Configfile-Front alles sehr schön, es waren diesmal kaum Änderungen vorzunehmen.

Änderungen an Konfigurationsdateien

Bei mir bekamen u.a. folgende Konfigurationsdateien größere und kleinere Änderungen mit, die ich dann mit eigenen Änderungen zu konsolidieren hatte (was aber wegen des geringen Umfangs sehr einfach und flott ging):

• /etc/apache2/mods-available/userdir.conf
• /etc/dhcp/dhclient.conf
• /etc/munin/plugin-conf.d/munin-node
• /etc/news/inn.conf
• /etc/news/innfeed.conf
• /etc/vim/vimrc
• /etc/phpmyadmin/apache.conf
• /etc/ssh/sshd_config

Das ist natürlich eine sehr spezifische Aufzählung, hängt sie doch von der installierten Software und von vorgenommenen Änderungen an deren Konfiguration ab. Sie ist aber m.E. erfreulich übersichtlich; so wenig Nacharbeit hatte ich selten.

Änderungen für bestimmte Softwarepakete

• Der Account news bekam /usr/sbin/nologin als Shell verpasst; das mag ich nicht, ich arbeite damit häufiger und setze die Shell daher auf die Bash. Das ist im Hinblick auf externe Logins kein Problem, weil ich die passwortbasierte Anmeldung per SSH deaktiviert habe und der User news keine authorized_keys hat.

• duply und duplicity benötigen, wie schon damals geschildert, GPG_OPTS='--pinentry-mode loopback'. Wer - wie ich - damit in die Amazon-Cloud (S3) sichert, muss zudem ggf. TARGET_USER in der Konfiguration durch export AWS_ACCESS_KEY_ID und TARGET_PASS durch export AWS_SECRET_ACCESS_KEY ersetzen.

• Ggf. braucht phpMyAdmin ein längeres blowfish_secret als früher, das man in /var/lib/phpmyadmin/blowfish_secret.inc.php setzen kann.

• Wie immer möchte debsecan per dpkg-reconfigure debsecan das aktuell installierte Release beigebogen bekommen.

Neue Software und geänderte Defaults

• vim hat diese furchtbare Maussteuerung bekommen, die man - wie schon beschrieben - aufgrund der Reihenfolge, in der die Konfigurationsdateien geladen werden, nicht so einfach deaktivieren kann, wie man das denken sollte. Entweder braucht jeder Nutzer (!) eine (leere) ~/.vimrc, oder man klemmt das Laden der defaults.vim in /etc/vim/vimrc in der dort beschriebenen Weise ab. Ich tat letzteres.

• Der INN setzt jetzt statt NNTP-Posting-Host, NNTP-Posting-Date und X-Trace die Header Injection-Info und ggf. auch Injection-Date; ich habe die damit verbundenen Änderungen bereits 2017 beschrieben.

• Wer seinen INN von einer anderen Maschine aus bspw. per nntpsend füttert, muss darauf achten, dass die Gegenstelle (also quasi der Client) in der passwd.nntp nunmehr zwingend einen Usernamen gesetzt haben muss, auch wenn der gar nicht ausgewertet wird; dies entspricht der Doku. Aus news.szaf.org::SECRETPASS muss also news.szaf.org:blafasel:SECRETPASS werden, sonst kann der “Client” sich nicht mehr anmelden,

• Mit Debian Stretch kommt PHP7; ich habe daher auch direkt komplett von PHP5 auf PHP7 umgestellt.

Umstellung von PHP 5 auf PHP 7

In meiner Konfiguration waren dafür folgende Änderungen erforderlich:

apt install php7.0-fpm
cp /etc/apache2/conf-available/php5-fpm.conf /etc/apache2/conf-available/php7.0-fpm.conf
vim /etc/apache2/conf-available/php7.0-fpm.conf

Dort wird dann die Zeile

<Proxy "unix:/var/run/php5-fpm.sock|fcgi://php-fpm">

geändert auf

<Proxy "unix:/run/php/php7.0-fpm.sock|fcgi://php-fpm">

Weiter geht es mit

a2disconf php5-fpm
a2enconf php7.0-fpm
service apache2 reload

Ggf. sind auch benutzerbezogene Konfigurationen anzupassen.

Schließlich kann man PHP5 abräumen, bspw. mit

apt remove php5-fpm php5 php5-gd php5-mysql php5-mcrypt php5-imagick php5-curl; apt autoremove

Das hängt natürlich davon ab, was man so alles installiert hatte.

Und dann kommt ggf. der größte Aufwand: alte PHP-Scripts so anzupassen, dass sie mit PHP7 laufen …

Zusammenfassung

Echte Arbeit ist ggf. die Umstellung vorhandener PHP-Scripts von PHP5 auf PHP7 (die man aber nicht zwingend zusammen mit dem Upgrade durchziehen muss); ansonsten ist der Aufwand sehr überschaubar. Es gibt m.E. einen echten Fehler (das Upgrade von phpMyAdmin und einen vermutlich häufigeren Stolperstein (die geänderten Filterbezeichnungen von fail2ban); alle übrigen Anpassungen sind konfigurationsspezifisch. Die Änderungen an Conffiles fielen diesmal angenehm überschaubar aus.

Alles in allem ein überschaubarer Aufwand, insbesondere, wenn man beim zweiten Durchgang (und allen weiteren) den Großteil der Fallstricke bereits kennt.