Betriebssysteme

unattended-upgrades

16. November 2024 · Betriebssysteme · andreas · Kein Kommentar

In der Vergangenheit habe ich Server so konfiguriert, daß Updates automatisiert über cron-apt heruntergeladen und installiert wurden. Seit der Einführung von systemd steht mit den uattended-upgrades eine weitere Möglichkeit zur Verfügung, welche eine detailliertere Konfiguration erlaubt.

$ sudo apt-get install unattended-upgrades

Die Grundkonfiguration erfolgt über die Datei “/etc/apt/apt.conf.d/50unattended-upgrades”, in der nach erfolgter Installation zumindest die Parameter “Unattended-Upgrade::Mail” sowie “Unattended-Upgrade::MailReport” angepasst werden sollten.

/etc/apt/apt.conf.d/50unattended-upgrades
... Unattended-Upgrade::Mail "an.wen.auch.immer@wo.auch.immer"; ... Unattended-Upgrade::MailReport "always"; ...

“Unattended-Upgrade::MailReport” kann nach erfolgreicher Testphase auch wieder zurück auf den Default-Wert “on-change” gestellt werden, falls das tägliche “es gab nix zu tun” nervt.

Um die Funktionalität zu aktivieren, kann entweder die Datei “/etc/apt/apt.conf.d/20auto-upgrades” manuell angepasst oder “dpkg-reconfigure” verwendet werden. Nach dem Aufruf von

$ sudo dpkg-reconfigure unattended-upgrades

die Frage “Aktualisierungen für Stable automatisch herunterladen und installieren?” mit “ja” beantworten.

Für einen Testlauf kann “unattended-upgrade” mit dem Parameter “-d” für Debug manuell gestartet werden:

$ sudo unattended-upgrade -d

Anpassung Zeitsteuerung

Der Zeitpunkt, zu dem das Herunterladen bzw. Installieren tatsächlich durchgeführt wird, lässt sich über zwei Overrides definieren. Wichtig ist hierbei, im ersten Schritt mit “OnCalendar=” erst einmal bestehende Einträge zu löschen, bevor dann die eigenen Werte gesetzt werden - sonst werden die angegebenen Werte zusätlich übernommen.

$ sudo mkdir /etc/systemd/system/apt-daily.timer.d $ sudo vi /etc/systemd/system/apt-daily.timer.d/override.conf
/etc/systemd/system/apt-daily.timer.d/override.conf
[Timer] OnCalendar= OnCalendar=04:00 RandomizedDelaySec=0
$ sudo mkdir /etc/systemd/system/apt-daily-upgrade.timer.d $ sudo vi /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
[Timer] OnCalendar= OnCalendar=05:00 RandomizedDelaySec=0

Anschließend müssen die geänderten Konfigurationsdateien noch eingelesen und die Timer neu gestartet werden:

$ sudo systemctl daemon-reload $ sudo systemctl restart apt-daily.timer $ sudo systemctl restart apt-daily-upgrade.timer

Der Status der Einplanung lässt sich mittels “systemctl” einsehen

$ sudo systemctl status apt-daily.timer ● apt-daily.timer - Daily apt download activities Loaded: loaded (/lib/systemd/system/apt-daily.timer; enabled; preset: enabled) Drop-In: /etc/systemd/system/apt-daily.timer.d └─override.conf Active: active (waiting) since Tue 2024-09-17 11:29:25 CEST; 46s ago Trigger: Wed 2024-09-18 04:00:00 CEST; 16h left Triggers: ● apt-daily.service
$ sudo systemctl status apt-daily-upgrade.timer ● apt-daily-upgrade.timer - Daily apt upgrade and clean activities Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled) Drop-In: /etc/systemd/system/apt-daily-upgrade.timer.d └─override.conf Active: active (waiting) since Tue 2024-09-17 11:29:33 CEST; 53s ago Trigger: Wed 2024-09-18 05:00:00 CEST; 17h left Triggers: ● apt-daily-upgrade.service

Was unattended-upgrades tatsächlich so angestellt hat, lässt sich auch mit Hilfe von “journalctl” auswerten:

$ sudo journalctl --since yesterday -u apt-daily.service $ sudo journalctl --since yesterday -u apt-daily-upgrade.service

Drittanbieterquellen

In der Standardkonfiguration aktualisiert unattended-upgrades nur die vom System bereitgestellten Quellen, alle weiteren Quellen müssen in der Datei “/etc/apt/apt.conf.d/50unattended-upgrades” noch hinzugefügt werden. Dies sieht man im Debug-Modus hier auch am Beispiel von “zammad”:

# unattended-upgrade -d | grep zammad Marking not allowed <apt_pkg.PackageFile object: filename:'/var/lib/apt/lists/dl.packager.io_srv_deb_zammad_zammad_stable_debian_dists_12_main_binary-amd64_Packages' a=,c=main,v=,o=https://packager.io/gh/zammad/zammad,l=Debian 12 packages for zammad/zammad arch='amd64' site='dl.packager.io' IndexType='Debian Package Index' Size=56880 ID:33> with -32768 pin Applying pin -32768 to package_file: <apt_pkg.PackageFile object: filename:'/var/lib/apt/lists/dl.packager.io_srv_deb_zammad_zammad_stable_debian_dists_12_main_binary-amd64_Packages' a=,c=main,v=,o=https://packager.io/gh/zammad/zammad,l=Debian 12 packages for zammad/zammad arch='amd64' site='dl.packager.io' IndexType='Debian Package Index' Size=56880 ID:33> Checking: zammad ([<Origin component:'main' archive:'' origin:'https://packager.io/gh/zammad/zammad' label:'Debian 12 packages for zammad/zammad' site:'dl.packager.io' isTrusted:True>]) adjusting candidate version: zammad=6.3.1-1726553725.106af4c8.bookworm Package zammad has a higher version available, checking if it is from an allowed origin and is not pinned down.

Die benötigten Angaben kann man direkt aus der Debugausgabe entnehmen

"origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad"

und die Zeile dann der Sektion “Unattended-Upgrade::Origins-Pattern” hinzufügen:

/etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern { ... "origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad"; ... };

Anschließend wird Zammad wie geplant aktualisiert:

# unattended-upgrade -d | grep zammad Erlaubte Ursprünge sind: origin=Debian,codename=bookworm,label=Debian, origin=Debian,codename=bookworm,label=Debian-Security, origin=Debian,codename=bookworm-security,label=Debian-Security, origin=https://packager.io/gh/zammad/zammad,component=main,label=Debian 12 packages for zammad/zammad Checking: zammad ([<Origin component:'main' archive:'' origin:'https://packager.io/gh/zammad/zammad' label:'Debian 12 packages for zammad/zammad' site:'dl.packager.io' isTrusted:True>]) pkgs that look like they should be upgraded: zammad ... Pakete, welche aktualisiert werden: zammad ... zammad (6.3.1-1726721589.817498f6.bookworm) wird eingerichtet ...

x86/cpu: SGX disabled by BIOS

19. Juni 2024 · Betriebssysteme · andreas · Kein Kommentar
Intel Software Guard Extensions

Nach dem Update von Debian 11 auf Debian 12 zeigte ein Dell 7280 bei jedem Systemstart kurz die Meldung

[ 0.076930] x86/cpu: SGX disabled by BIOS.

was zu der Frage “Was ist SGX und wer braucht das?” führte.

Bei SGX handelt es sich um die Intel Software Guard Extensions, eine Erweiterung der Prozessorarchitektur, um Programme innerhalb des RAMs voneinander abzuschotten.

Die Erklärung, warum die Meldung nach dem Debain-Update plötzlich ausgegeben wurde, hängt mit dem verwendeten Kernel zusammen: während Bullseye noch mit dem 5.10’er Kernel lief, wird Debian Bookworm mit Kernel 6.xx ausgeliefert - der Support für Intel SGX wurde mit Kernel 5.11 eingeführt.

Seit Prozessor-Genration 11 ist SGX wohl aber wieder Geschichte, denn sowohl in den Core-i-Prozessoren der Generationen 11 als auch 12 fehlten die Software Guard Extensions wieder, was zu Problemen mit sich darauf verlassender Software führt.

Die Extensions können im BIOS mit Hilfe der Option “Intel SGX Enable” aktiviert werden. “Software Controlled” ist hierbei nicht ausreichend, die Option muß auf “Enabled” gesetzt werden, damit der Kernel zufrieden ist.


DSM-Aktualisierung findet keine Updates

26. Mai 2024 · Betriebssysteme · andreas · Kein Kommentar

Während in der Vergangenheit mehr oder minder regelmäßig Aktualisierungen für den Synology Disk Station Manager gefunden wurden, war die autmatische Suche neuerdings verdächtig lange der Meinung, daß alles Bestens wäre.

DSM-Aktualisierung

Ein Klick auf die Versionshinweise zeigte allerdings, daß sehr wohl Aktualisierungen verfügbar waren. Aktuell ist “7.2.1-69057 Update 5” vom 08.04.2024, während die noch installierte “7.2-64570 Update 3” auf den 03.08.2023 datiert.

Während die Updates 1 bis 5 zur 7.2.1 tatsächlich wohl auch nur nach Bedarf angeboten und eingespielt werden

Your Synology NAS may not notify you of this DSM update because of the following reasons.

Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version. [Quelle]

enthält die “7.2.1-69057” u.a. Korrekturen für einige Sicherheitslücken (u.a. Sudo, OpenSSL und Zlib) und eine Installation scheint somit sinnvoll. In den Notes steht auch die Erklärung, warum der DSM die Aktualisierung nicht anzeigt

For the models below, you can only download the upgrade patch from Synology Download Center because you won’t receive notifications for this update on your DSM.

Plus Series: …, DS218+, … [Quelle]

allerdings ohne weitere Begründung, warum diese Vorgehensweise gewählt wurde.

Eine weitere Unstimmigkeit gibt es dann noch im Download-Zentrum:

Download-Zentrum

Während angezeigt wird, daß nach dem Herunterladen und Installieren von “7.2.1-69057 (with Update 1)” noch das Herunterladen von Installieren von “7.2.1-69057 Update 5” notwendig ist, meldet sich die DSM-Aktualisierung bereits nach dem Einspielen des ersten Pakets mit “DSM 7.2.1-69057 Update 5”.


Fehlerhafter Kernel in Debian 12.3

10. Dezember 2023 · Betriebssysteme · andreas · 2 Kommentare

Gestern wurde die Verteilung von Debian 12.3 gestoppt. Grund dafür ist ein Fehler im Kernel 6.1.64-1, der zur Beschädigung von Daten auf ext4-Dateisystemen führen kann.

Debian 12.3 image release delayed

December 9th, 2023

Due to an issue in the ext4 file system with data corruption in kernel 6.1.64-1, we are pausing the planned Debian 12.3 point release images for today while we attend to fixes.

Please do not upgrade any systems at this time, we urge caution for users with UnattendedUpgrades configured.

Genauere Informationen gibt es im Debian Bug-Report “linux: ext4 data corruption in 6.1.64-1

Sofern die Systeme nach der Aktualisierung des Kernels noch nicht neu gestartet wurden, war der fehlerhafte Kernel auch noch nicht aktiv und es wird weiterhin der Vorgänger benutzt:

$ uname -a Linux *** 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux

Es ist noch der Kernel 6.1.55-1 vom 29. September (Debian Paket 6.1.0-13) aktiv, welcher den Fehler nicht enthält.

$ apt list --installed | grep linux-image WARNING: apt does not have a stable CLI interface. Use with caution in scripts. linux-image-5.10.0-26-amd64/now 5.10.197-1 amd64 [Installiert,lokal] linux-image-6.1.0-13-amd64/stable,now 6.1.55-1 amd64 [Installiert,automatisch] linux-image-6.1.0-14-amd64/stable,now 6.1.64-1 amd64 [Installiert,automatisch] linux-image-amd64/stable,now 6.1.64-1 amd64 [installiert]

Der fehlerhafte Kernel ist installiert und würde beim nächsten Systemstart verwendet werden. Das fehlerhafte Kernel-Paket wird deinstalliert, so daß auf jeden Fall sichergestellt ist, daß bei einem Neustart weiterhin der Kernel 6.1.55-1 verwendet wird.

$ sudo apt remove linux-image-6.1.0-14-amd64 ... Die folgenden Pakete werden ENTFERNT: linux-image-6.1.0-14-amd64 linux-image-amd64 ...

Soweit im Debian Forum zu lesen, schlägt ein Versuch, die Kernel-Installationsdatei “linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.deb” herunterzuladen mit einen “403 Forbidden”-Fehler fehl, so daß der fehlerhafte Kernel auch nicht mehr heruntergeladen werden kann.


apt ignoriert Zammad beim Distributionsupgrade

30. November 2023 · Betriebssysteme · andreas · Kein Kommentar

Beim Upgrade von Debian 11 (Bullseye) auf Debian 12 (Bookworm) wurde das komplette System wie vorgesehen aktualisiert, lediglich das Zammad-Paket zeigte in der Weboberfläche die falsche Version:

Dies ist Zammad Version 6.1.0-1700492762.96ac5a60.bullseye

Was auf auch ein Anzeigefehler in Zammad hätte sein können, wurde von dpkg bestätigt

$ dpkg -s zammad ... Version: 6.1.0-1700492762.96ac5a60.bullseye ...

und apt zeigte keinerlei Motivation, das Paket zu aktualisieren.

$ sudo apt update ... Alle Pakete sind aktuell.

Daß die eigentlich richtige Datei zur Installation zur Verfügung stand, bestätigte ein Aufruf von “apt-cache policy”

$ sudo apt-cache policy zammad zammad: Installiert: 6.1.0-1700492762.96ac5a60.bullseye Installationskandidat: 6.1.0-1700492762.96ac5a60.bullseye Versionstabelle: *** 6.1.0-1700492762.96ac5a60.bullseye 100 100 /var/lib/dpkg/status 6.1.0-1700492762.96ac5a60.bookworm 500 500 https://dl.packager.io/srv/deb/zammad/zammad/stable/debian 12/main amd64 Packages ...

Trotz offensichtlich verfügbarer Bookworm-Installationsdatei hielt apt die Bullseye-Version für geeigneter. Die Suche nach der Ursache bzw. deren Lösung führte zum Beitrag “Distupgrade debian buster to bullseye - zammad still shows buster version” im Zammad-Forum, der für das Upgrade von Bullseye auf Bookworm noch genauso gilt. Dort erklärt MrGeneration vom Zammad-Core-Team:

Due to the way our version numbers are generated, you end up in

6.0.0-1692176490.0e2399eb.buster
6.0.0-1692176490.0e2399eb.bullseye

those versions. Versioning is done alphabetical. So buster vs bullseye apart from the rest of the version string being the same is your issue.

Das gleiche Verhalten tritt auch hier auf: beim Vergleich der beiden Versionen “6.1.0-1700492762.96ac5a60.bullseye” und “6.1.0-1700492762.96ac5a60.bookworm” ist apt nach Vergleich der Versionsnummern der Meinung, daß “bullseye” neuer als “bookworm” ist und behält deshalb die Bullseye-Version, statt auf die Bookworm-Version zu aktualisieren. Dies kann man auch mit dpkg evaluieren:

$ dpkg --compare-versions 6.1.0-1700492762.96ac5a60.bookworm lt 6.1.0-1700492762.96ac5a60.bullseye && echo "älter" älter

Die im oben verlinkten Beitrag vorgeschlagene Lösung eines “apt remove zammad” gefolgt vom einem “apt install zammad” ist zumindest im Fall des Upgrades von Bullseye auf Bookworm nicht notwendig, da Zammad auch in der Bullseye-Version problemlos arbeitet.

Mit der nächsten Änderung der tatsächlichen Versionsnummer wurde dann auch auch auf das Bookworm-Paket aktualisiert:

... Preparing to unpack .../zammad_6.1.0-1701163867.5a81e629.bookworm_amd64.deb ... Unpacking zammad (6.1.0-1701163867.5a81e629.bookworm) over (6.1.0-1700492762.96ac5a60.bullseye) ... Setting up zammad (6.1.0-1701163867.5a81e629.bookworm) ... ...