Systemd

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 ...

Systemd vs. SysVinit

04. November 2020 · Betriebssysteme · andreas · Kein Kommentar

Die Diskussion “Systemd vs. SysVinit” nimmt fast schon religiöse Züge an und erinnert in mancher Beziehung an ein Phänomen, das oft zu beobachten ist, wenn sich irgendwo irgendetwas ändert: Neumodischer Krams? Kann nur schlecht sein!

METALLICA anyone? Da gibt es auch eine Fraktion, die “alles seit dem schwarzen Album” “grottenübel” findet, und trotzdem verkaufen sich die Scheiben und Konzertkarten noch immer recht gut.

Ich persönlich hätte nichts dagegen gehabt, wenn sich Debian für ein Verbleiben beim “alten” Init-System entschieden hätte, das hat schließlich jahrzehntelang problemlos funktioniert. Mich ärgern an Systemd täglich so Dinge, wie daß ich z.B. mit einem journaldingens arbeiten muss, statt mit grep um mal schnell ein Protokoll zu durchsuchen.

Über die tatsächlichen Vor- und Nachteile und was vielleicht besser ist und was weniger haben sich eine ganze Menge kluge Köpfe ihre Gedanken gemacht, die deutlich tiefer in der Materie stecken als Meinereiner und ich habe die Hoffnung, daß die auch zu einem klugen Ergebnis gekommen sind. Nicht alles ist nur schwarz oder weiß, wir bewegen uns im Normalfall irgendwo zwischen Grauschattierungen.

Letztendlich ist mir ein zuverlässig funktionierendes System wichtig und wenn ich mich komplett von allen Datenkraken lösen möchte, dann müsste ich den Netzstecker ziehen, das Mobiltelefon wegwerfen und hätte immer noch ein Problem, wenn das nächste Mal ein Google Streetview-Auto vorm Haus vorbeirollt.


Zeitsynchronisierung mit systemd

27. April 2020 · Betriebssysteme · andreas · Kein Kommentar

Sofern ein Linux-System systemd verwendet muß zum Abgleich der Systemzeit – sofern dieses nicht als Zeitserver für andere Systeme arbeiten sollen – kein ntp mehr insalliert werden.

Es reicht die Anpassung der Datei “/etc/systemd/timesyncd.conf” in welcher dann in der Zeile “NTP=” der gewünschte Zeitserver eingetragen wird.

/etc/systemd/timesyncd.conf
[Time] NTP=zeitserver.local FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org RootDistanceMaxSec=5 PollIntervalMinSec=32 PollIntervalMaxSec=2048

Nach Änderung der Datei wird der Dienst “systemd-timesyncd.service” neu gestartet - das war’s.

$ sudo systemctl restart systemd-timesyncd.service

Anschließend kann die Konfiguration des Diensts mittels

$ timedatectl status Local time: Mo 2020-04-27 21:19:40 CEST Universal time: Mo 2020-04-27 19:19:40 UTC RTC time: Mo 2020-04-27 19:19:40 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no

überprüft werden. Wird der Status des “NTP service” als “inactive” angezeigt, so ist ein

$ timedatectl set-ntp true

notwendig, um die Synchronisation zu aktivieren. Detaillierte Informationen erhält man entweder über

$ timedatectl timesync-status Server: 1.2.3.4 (zeitserver.local) Poll interval: 1min 4s (min: 32s; max 34min 8s) Leap: normal Version: 4 Stratum: 4 Reference: AF0149C Precision: 1us (-21) Root distance: 31.249ms (max: 5s) Offset: -1.759ms Delay: 1.972ms Jitter: 0 Packet count: 1 Frequency: +17,237ppm

oder mit Hilfe von

$ timedatectl show-timesync SystemNTPServers=zeitserver.local FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org ServerName=zeitserver.local ServerAddress=1.2.3.4 RootDistanceMaxUSec=5s PollIntervalMinUSec=32s PollIntervalMaxUSec=34min 8s PollIntervalUSec=2min 8s NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=4, Precision=-21, RootDelay=17.333ms, RootDispersion=18.478ms, Reference=AF0149E, OriginateTimestamp=Mon 2020-04-27 21:05:29 CEST, ReceiveTimestamp=Mon 2020-04-27 21:05:29 CEST, TransmitTimestamp=Mon 2020-04-27 21:05:29 CEST, DestinationTimestamp=Mon 2020-04-27 21:05:29 CEST, Ignored=no PacketCount=2, Jitter=329us } Frequency=1353001

journalctl

15. Oktober 2015 · Betriebssysteme · andreas · Kein Kommentar

Eine der unschönen Neuerungen die mit der Einführung von systemd Einzug halten ist daß Logdateien statt im jederzeit problemlos les- und verarbeitbaren Textformat nun mittels journald gesammelt, verwaltet und vor allem als Binärdateien gespeichert werden.

Will man Einsicht in ein Log erhalten, so benötigt man hierzu den Befehl

journalctl

welcher bei Aufruf die bisher erstellten Logeinträge in chronologischer Reihenfolge ausgibt.

Sollen nur die Einträge eines bestimmten Dienstes angezeigt werden, so kann mittles “-u Dienstname” ein Filter gesetzt werden:

journalctl -u shairport-sync

listet zum Beispiel nur die zum Dienst “shairport-sync” gehörenden Einträge auf.

Sofern man einem Dienst bei der Arbeit über die Schulter schauen möchte, kann dies durch den Parameter “-f” (analog zu z.B. “tail”) erreicht werden:

journalctl -f -u shairport-sync

zeigt die letzten Einträge sowie die neu hinzukommenden Einträge an.

Standardmäßig werden die Einträge seitenweise ausgegeben, dies kann durch den Parameter “–no-pager” geändert werden.

Eine Liste der möglichen Parameter und ihrer Verwendung erhält man durch die Eingabe von

journalctl --help