Inzwischen läuft mein Heimserver nach den ersten drei Etappen des Upgrade-Marathons seit einer knappen Woche auf Debian Bookworm und nachdem die diversen offensichtlichen Probleme durch die Upgrades beseitigt waren, tauchen jetzt nach und nach die etwas weniger offensichtlichen Probleme auf, die es zu beheben gilt. Bislang habe ich derer zwei gefunden:
Zeitzone in PHP
Cron-gesteuert wird bei mir mehrmals am Tag ein PHP-Skript zum sammeln von externen Daten gestartet. Innerhalb des Skripts entscheidet sich dann noch einmal basierend auf der aktuellen Uhrzeit, was genau geschieht. Zum Glück lasse ich mir die Ausgabe des Skriptes immer per E-Mail zuschicken, wodurch dann doch relativ schnell auffiel, dass die Ergebnisse irgenwie komisch waren und nicht zu dem Erwarteten passen. Die U(h)rsache war dann ebenfalls schnell gefunden: in früheren Versionen verwendete PHP für die date()-Funktion anscheinend implizit die lokale Zeitzone des Systems, das ist jetzt anscheinend nicht mehr der Fall. Daher arbeitete das Skript mit Zeitangaben in UTC-Zeit statt wie erwartet in lokaler Zeit (aktuell MEZ) und lag demnach um eine Stunde falsch. Der Eintrag date.timezone = "Europe/Berlin" in der php.ini behob dieses Problem.
Bind und AppArmor
Der zweite Fehler war etwas weniger offensichtlich. Dazu muss ich vorausschicken, dass ich schon seit längerem Bacula zum Anfertigen von Backups einsetze. Bacule erzeugt bei mir Backups nicht nur vom Heimserver selbst, sondern auch von diverse Raspberry Pis im LAN sowie von meinem Windows-Notebook. Da das Notebook mit mir zwischen Stockstadt und Bayreuth pendelt, hat es an den beiden Orten jeweils eine unterschiedliche LAN-IP-Adresse. Um dieses Problem zu lösen, habe ich schon vor längerer Zeit im ohnehin laufenden Bind sozusagen einen Mini-DynDNS-Dienst eingerichtet (mit ddclient als DynDNS-Client auf dem Windows-Notebook). Als ich nun nach dem Update-Marathon in Stockstadt das erste Mal wieder in Bayreuth war, schlug prompt das abendliche Backup des Notebook fehl. Gleich der erste Check per nslookup zeigte, das dir URL des Notebooks immer noch auf die Stockstädter IP-Adresse auflöste. Auch ein Neustart des ddclients änderte daran nichts. Zum Glück hatte ich mir ebenfalls vor längerer Zeit für Bind schon extra Logfiles für die DNS-Updates eingerichtet und diese Logfile zeigt zahlreiche „error: journal open failed: unexpected error“-Einträge. Erfahrungsgemäß sind solche Fehlermeldungen unter Linux Hinweise auf nicht passende Zugriffsrechte im Dateisystem, diese sahen jedoch vordergründig gut aus: sowohl /etc/bind als auch die Journal-Dateien darin, waren für den User „bind“, unter dem der Bind-Daemon läuft, les- und schreibbar.
Eine Google-Suche gab mir dann den Schubs in die richtige Richtung: bereits seit Buster ist in Debian AppArmor standardmäßig aktiviert und offensichtlich bei mir auch im Rahmen des Updates installiert und aktiviert. Allerdings sind die Debian-Macher(?) der Meinung, dass dynamisch updatebare DNS-Zonen und die zugehörigen Journal-Dateien in /etc/bind nichts verloren hätten, weswegen AppArmor Schreibzugriffe auf dieses Verzeichnis bzw. die Dateien darin blockiert, obwohl die Dateisystemrechte es eigentlich zulassen würden. Zum Glück ist das in der AppArmor-Konfigurationsdatei wenigstens mit aussagekräftigen Kommentaren dokumentiert, zusammen mit den Hinweis, dass dynamische Zonen-Daten doch bitteschön nach /var/lib/bind zu packen seien. Nachdem ich die Dateien dort verschoben, die Bind-Konfiguration angepasst und Bind neu gestartet hatte, wurde auch prompt die Notebook-URL wieder aktualisiert und die Backups des Notebooks funktionieren seither auch wieder.
Manchmal muss man zur Fehlersuche wirklich zweimal um die Ecke denken…