Netz - Rettung - Recht

Hinweise zu bestimmten Softwarepaketen

Ein paar Notizen:

• phpMyAdmin ist in Debian Buster nicht enthalten, kann aber aus den Backports installiert bzw. geupdatet werden, das ist also kein Problem.

• Bei Spamassassin ändert sich die Art und Weise der Aktivierung; das ENABLED-Flag aus /etc/default/spamassassin entfällt.

• Dovecot bekommt per Default ein selbstsigniertes SSL-Zertifikat; wenn man schon selbst eines hat, will man diese Änderung natürlich nicht.

• Angeblich soll duply zu der Version aus Stretch nicht kompatibel sein, da haben sich bei mir aber keine Probleme ergeben.

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

• su behält nunmehr das Environment des bisherigen Users, insbesondere PATH, bei, hat also standardmäßig bspw. /usr/sbin/ nicht mehr im Pfad. Der Aufruf mit su - hilft.

• Die in den NEWs hervorgehobenen Änderungen an gnupg2, OpenSSH und OpenSSL haben mich nicht betroffen.

logrotate nicht mehr als Cronjob, sondern als systemd-Timer

Wenn man Exim als MTA verwendet und weiterhin über den bei Debian inkludierten Cronjob den dort generierten täglichen Report erhalten will, muss man dessen Erzeugung auf den Zeitpunkt der Logrotation abstellen. Bei Stretch - und zuvor - ist das kein Problem, weil sowohl die Erzeugung des Reports als auch die Logrotation über Cronjobs in /etc/cron.daily erfolgen, die in alphabetischer Reihenfolge ausgeführt werden, und da kommt exim4-base vor logrotate. Debian Buster aber setzt bei Logrotate stattdessen auf einen systemd-Timer; ist systemd auf dem System aktiv, wird der Cronjob deaktiviert:

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi

Die Timer-Unit für logrotate findet sich in /lib/systemd/system/logrotate.timer und wird täglich ausgeführt:

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Bedauerlicherweise läuft cron.daily bei Debian standardmäßig um 06.30 Uhr, und der systemd-Timer bereits um Mitternacht. Daher enthält der Exim-Report nur noch sechseinhalb von vierundzwanzig Stunden, und zudem die eher wenig aktiven Nachtzeiten.

Für dieses Problem gibt es verschiedene Lösungen; man kann den Zeitpunkt von cron.daily verlegen, den Exim-Cronjob auslagern und auf einen eigenen Zeitpunkt verlegen und was der Dinge mehr sind. Ich habe mich stattdessen dazu entschieden, den Zeitpunkt der Logrotation zu verlegen, und zwar “hinter” cron.daily. Das erscheint mir aus verschiedenen Gründen vorzugswürdig: der Eingriff betrifft nur ein Element (logrotate) und nicht den Zeitpunkt zur Ausführung zentraler Systemdienste, er verschiebt keine bei Debian mitgelieferten Dateien an einen anderen Ort, und der Gedanke ist nicht fernliegend, dass auch andere tägliche Cronjobs möglicherweise damit rechnen, dass ihnen die Logs nicht vor der Nase wegrotiert werden.

Technisch ist das minimalinvasiv machbar: systemd-Units in /etc/systemd haben Vorrang vor denen in /lib/systemd; es genügt also, einen /etc/systemd/system/logrotate.timer mit angepasstem Inhalt zu erstellen, indem man /lib/systemd/system/logrotate.timer nach dort kopiert und die Zeile OnCalendar anpasst:

OnCalendar=*-*-* 06:35:00

Das führt die Logrotation nunmehr täglich um 06.35 Uhr, also fünf Minuten nach cron.daily, aus. Mit systemctl reenable logrotate.timer wird die Änderung übernommen (d.h. der Symlink der Timer-Unit gelöscht und - auf die neue, vorrangige Einheit - neu erstellt, mit systemctl list-timers kann man sich den richtigen Zeitpunkt der Timer-Ausführung bestätigen lassen.

Änderungen an Konfigurationsdateien

Insbesondere folgende Konfigurationsdateien waren bei mir von Änderungen betroffen:

• /etc/dovecot/conf.d/10-mail.conf
• /etc/dovecot/conf.d/10-ssl.conf
• /etc/mysql/mariadb.conf.d/50-server.cnf
• /etc/munin/plugin-conf.d/munin-node
• /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; es gab praktisch nichts zu tun.

Umstellung von PHP 7.0 auf PHP 7.3

Mit Buster kommt PHP 7.3; man will also ggf. zum einen PHP 7.0 runterwerfen und muss in jedem Fall die PHP-FPM-Konfiguration mal wieder anpassen, weil die Konfigurationsdateien für PHP 7.3 “natürlich” in einem anderen Verzeichnis als die von PHP 7.0 liegen. Andererseits hat das den Vorteil, dass man PHP 7.0 zunächst auch weiterbetreiben kann, wenn man das möchte, oder beide Versionen parallel betrieben werden können.

Für die notwendigen Änderungen für den Wechsel kann ich auf meinen Beitrag zum Update auf Debia Stretch verweisen; es sind dieselben Schritte zu gehen wie beim Update von PHP 5.

Der größte Aufwand waren dann tatsächlich Umstellungen an PHP-Scripts - und der Kampf mit der aktuellen Version von nanoc, meinem static site compiler. (“Kampf” ist vielleicht etwas zuviel gesagt; ich habe primär einen Fehler beim Updaten der Ruby-Gems gemacht und hatte dann noch einige Anpassungen in eher speziellen Modulen vorzunehmen. Der Aufwand war v.a. deshalb größer, weil dieses Ökosystem für mich noch unvertraut ist.)

Zusammenfassung

Jedenfalls bei diesem Host war das Update unter dem Strich wirklich ereignislos. Möglicherweise sieht das anderswo noch anders aus, wenn bspw. INN und Mailman betroffen sind. Andererseits erlaubt Buster es, einmal Mailman 3 auszuprobieren …