Das MQTT-Passwort lässt sich auf der Konsole des Home Assistant Systems in der Datei /mnt/data/supervisor/homeassistant/.storage/core.config_entries finden. Der entsprechende Eintrag sieht bei mir wie folgt aus:
Dieses Tutorial führt in den RHEL image mode ein und zeigt, wie ein solches Image in einer virtuellen Maschine (VM) installiert werden kann. Es wird ebenfalls gezeigt, wie ein installiertes Image aktualisiert und bei Bedarf zurückgerollt werden kann.
Während diese Einführung in Deutsch gehalten ist, liegen die Dokumentation und weitere verwendete Quellen ausschließlich in englischer Sprache vor.
Das Tutorial richtet sich in erster Linie an Sysadmins, die bereits Erfahrung mit dem Betrieb von RHEL oder einer verwandten Enterprise Linux Distribution haben. Es bietet keine allgemeine Einführung in die Installation und den Betrieb von Red Hat Enterprise Linux.
Zum Inhalt
Die folgende Liste bietet einen Überblick über den Inhalt:
RHEL image mode ist eine Technology Preview und stellt eine neue Methode dar, um RHEL zu konfigurieren, installieren bzw. deployen und zu verwalten.
Durch Nutzung von Container-Tools wird ein Container-Image erstellt, welches neben dem RHEL-Userland auch den RHEL-Kernel, Boot Loader, Firmware und Treiber umfasst. Dieses RHEL-Container-Image (auch RHEL Bootc Image genannt) kann anschließend genutzt werden, um RHEL im Datacenter oder in der Cloud – auf Bare-Metal-Servern, virtuellen Maschinen oder Edge-Geräten zu deployen. Das RHEL-Container-Image kann direkt als Container ausgeführt werden, um die Funktionalität zu testen. Für das Deployment kann das Container-Image in ein Disk-Image für die entsprechende Zielplattform konvertiert werden. Ein installiertes oder als Disk-Image provisioniertes System läuft anschließend nativ auf der Hardware bzw. in der virtuellen Maschine und wird dort nicht als Container ausgeführt.
Konsolidierung von Bereitstellungsprozessen
In vielen Unternehmen kommen heute neben klassischen virtuellen Maschinen auch Linux-Container zum Einsatz. RHEL image mode bietet die Möglichkeit, Bereitstellungsprozesse zu konsolidieren, indem für die Bereitstellung von RHEL-Images die gleichen Werkzeuge genutzt werden, wie für die Bereitstellung von Container-Images für Anwendungen.
Immutable RHEL
Mit Ausnahme von /etc und /var ist das Wurzel-Dateisystem in RHEL image mode immutable (read-only).
Anwendungen und Updates werden durch aktualisierte RHEL-Container-Images verteilt. Ein provisioniertes System lädt dazu das aktualisierte Image auf die lokale Festplatte und startet dieses nach einem Neustart. Im Fehlerfall kann durch einen weiteren Neustart einfach das vorherige Image gestartet werden. So können fehlgeschlagene Updates einfach zurückgerollt werden.
Dies bietet dem Admin die Sicherheit, bei Bedarf zum vorherigen Zustand zurückkehren zu können, ohne dafür auf VM-/Storage-Snapshots oder andere Mechanismen außerhalb des Betriebssystems zurückgreifen zu müssen.
Deklarative Konfiguration des Betriebssystems
RHEL image mode macht es einfach, zu konfigurieren und zu verfolgen, welche Pakete in einem Basis-Image enthalten sind und wann welche Pakete hinzugefügt wurden.
Red Hat veröffentlicht in der Container-Registry registry.redhat.ioRHEL Bootc Base Images, welche die Basis für eigene Images darstellen. Zu jeder Version wird eine Liste der enthaltenen Pakete veröffentlicht. Diese ist über den Red Hat Ecosystem Catalog einsehbar:
Ansicht der Paketliste eines RHEL 9 Bootc Base Image
Hier ist zu beachten, dass obwohl amd64 als Architektur ausgewählt wurde, die Liste Pakete aller verfügbaren Architekturen zeigt. Natürlich sind im Basis-Image nicht 2302 Pakete enthalten. Die Filtermöglichkeiten und die Ergebnisliste zeigen leider unerwartete Ergebnisse. Ich habe dies bereits intern gemeldet und hoffe, dass sich bald jemand der Sache annimmt.
Das in obiger Abbildung gezeigte Image enthält für die amd64-Architektur 441 Pakete. Vergleiche ich dies mit zwei meiner RHEL 9 Installationen, die auf der Minimalinstallation basieren, so umfassen diese 591 bzw. 510 Pakete. Der Vergleich hinkt allerdings, da ich auf den RHEL package mode Installationen bereits weitere Software nachinstalliert habe. Ich bin jedoch erfreut, dass das Basis-Image nicht mehr Pakete als eine Minimalinstallation enthält.
Pakete, die zusätzlich hinzugefügt werden sollen, werden im Containerfile aufgeführt, welches üblicherweise einer Versionskontrolle unterliegt. Änderungen können so jederzeit nachvollzogen werden.
Meine Laborumgebung besteht aus zwei virtuellen Maschinen, welche auf einem Laptop ausgeführt werden. Beide VMs verfügen über 2 vCPU, 8 GB RAM und 40 GB Speicher.
Auf VM 1 werden folgende Tätigkeiten ausgeführt:
Erstellung und Ausführung einer einfachen Container-Registry
Erstellung und Pflege eines oder mehrerer rhel-bootc-Container-Images
Erstellung von Disk-Images
Anhand von VM 2 werden folgende Dinge demonstriert:
Installation von RHEL image mode
Aktualisierung der Installation
Wechsel des verwendeten Images
Rollback
Die in diesem Tutorial verwendeten Containerfiles, Dateien und Skripte habe ich in einem Git-Repository gesammelt. Fühlt euch frei, die dortigen Dateien auf eigene Gefahr für eigene Versuche zu verwenden. Repository-URL: https://github.com/tronde/image-mode-demo
RHEL Bootc Image erstellen
Dieser Abschnitt wurde aus Kapitel 2 der Dokumentation Using image mode for RHEL to build, deploy, and manage operating systems abgeleitet. In ihm wird das RHEL-Container-Image erstellt, welches im nächsten Schritt für das Deployment in einer VM vorbereitet wird. Dieser Abschnitt behandelt folgende Schritte:
Containerfile(5) erstellen
Container-Image mit podman-build(1) erstellen
Container-Image auf dem Build-System testen
Containerfile
Mit dem folgenden Containerfile(5) wird konfiguriert, wie das RHEL Bootc Base Image ‚rhel-bootc:9.5‚ angepasst werden soll:
Die Dienste httpd und sshd werden aktiviert, damit sie nach dem Boot-Vorgang automatisch starten
Die im Containerfile aufgeführten Pakete sind eine persönliche Auswahl, die ich gern auf meinen Systemen habe. Ihr könnt hier natürlich die Pakete eurer Wahl eintragen.
Für dieses Tutorial installiere ich den Dienst httpd. Das von dem Image provisionierte System wird also einen Webserver hosten. Dass ich die index.html-Datei ebenfalls dem Image hinzufüge, soll mir lediglich den späteren Test in diesem Tutorial vereinfachen. Je nach Aufbau, Inhalt und Änderungsrate der auszuliefernden Webseite bzw. Webanwendung ist es nicht sinnvoll, diese in das Image zu integrieren.
Build
Login registry.redhat.io
Bevor das erste Container-Image erstellt werden kann, ist eine Anmeldung an der Container-Registry registry.redhat.io notwendig:
$ podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
Mit dem folgenden Befehl kann nun ein Image aus obigen Containerfile erstellt werden:
$ time podman build -t localhost/rhel9.5-bootc:test .
…
Successfully tagged localhost/rhel9.5-bootc:test
c958185aa4c578af37b5bca796c7c5e50a270f7b7de38126c31fa6ab97046f41
real 2m52.574s
user 2m31.787s
sys 0m59.680s
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test c958185aa4c5 40 seconds ago 1.68 GB
registry.redhat.io/rhel9/rhel-bootc 9.5 7cf5466a7756 2 days ago 1.56 GB
Das Container-Image wird unter dem Namen localhost/rhel9.5-bootc:test im lokalen Dateisystem gespeichert.
Der Build-Vorgang dauerte insgesamt knapp 3 Minuten. Darin ist die Zeit zum Herunterladen des Basis-Image registry.redhat.io/rhel9/rhel-bootc:9.5 enthalten. Ist dieses Image bereits vorhanden, dauert der Build-Vorgang nur knapp über 1 Minute.
Test
Der nun folgende Code-Block zeigt, wie das soeben erstellte Container-Image mit Podman im interaktiven Modus gestartet werden kann. Es wird geprüft, ob die index.html-Datei vorhanden ist und wie viele Pakete das Image enthält.
$ podman run -it --rm --name mybootc localhost/rhel9.5-bootc:test /bin/bash
bash-5.1# ls -l /var/www/html
total 4
-rw-r--r--. 1 root root 342 Jan 11 11:20 index.html
bash-5.1# rpm -qa | wc -l
465
bash-5.1#
Als nächste teste ich, ob die index.html-Datei auch ausgeliefert wird:
$ podman run -d --rm -p 127.0.0.1:8888:80 --name mybootc localhost/rhel9.5-bootc:test
fa9c1f5110cd58c3f28760fb5a5d69cdc4595a5cba2f29ff67f85eaa076204ab
$ curl http://127.0.0.1:8888
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bootc Demo Page</title>
</head>
<body>
<p>Diese Seite wird von einem Webserver ausgeliefert, der mit RHEL Bootc Image Mode bereitgestellt wurde.</p>
</body>
</html>
Test erfolgreich! Die konfigurierte Webseite wird wie erwartet ausgeliefert. Der Container wird mit podman stop mybootc gestoppt und der Test ist beendet.
Zwischenfazit
Bis hier wurde ein Containerfile erstellt, welches das zu verwendende Basis-Image, die zusätzlich zu installierenden Pakete und die auszuführenden Dienste definiert. Mit Hilfe dieses Containerfiles und Podman wurde anschließend das Container-Image localhost/rhel9.5-bootc:test erzeugt. Mit einem einfachen Test konnte auf dem Build-System verifiziert werden, dass die index.html-Datei wie gewünscht ausgeliefert wird.
Das Image enthält keinerlei Passwörter oder SSH-Schlüssel. Es sind somit bisher keinerlei Geheimnisse enthalten, die mit dem Image verloren gehen könnten.
Verglichen mit einer klassischen RHEL-Minimalinstallation, die als Basis für ein Golden-Image dient, konnte der Vorgang deutlich schneller abgeschlossen werden.
ISO-Image mit dem bootc-image-builder erstellen
Der bootc-image-builder ist eine Container-Variante des RHEL Image Builder. Mit diesem wird in den folgenden Schritten ein ISO-Image aus dem zuvor erstellten Container-Image erzeugt. Mit dem ISO-Image wird anschließend eine Installation in einer VM durchgeführt.
Mit dem bootc-image-builder können auch Disk-Images wie AMI, GCE, QCOW2, RAW und VMDK erzeugt werden. Ich habe mich für ISO entschieden, da dies am vielseitigsten verwendbar ist. Man kann damit VMs unter KVM/Qemu und VMware genauso installieren, wie Bare-Metal-Server.
Benutzer, Passwort und SSH-Schlüssel hinzufügen
Um sich nach der Installation interaktiv am System anmelden zu können, werden dem ISO-Image ein Benutzer mit Passwort und SSH-Schlüssel hinzugefügt. Dafür wird die folgende Datei toml.config genutzt:
$ cat config.toml
[[customizations.user]]
name = "alice"
password = "changeme"
key = "ssh-ed25519 AAAAC3NzaC…cr alice@example.com"
groups = ["wheel"]
Durch Hinzufügen des Benutzers zur Gruppe wheel darf dieser privilegierte Kommandos mittels sudo ausführen.
Das Container-Image in den passenden Benutzerkontext kopieren
Das Image localhost/rhel9.5-bootc:test wurde mit einem rootless-Benutzer erstellt. Der Befehl im folgenden Abschnitt muss jedoch mit root-Rechten ausgeführt werden. Rootful-Podman kann jedoch nicht auf das Image zugreifen, welches wir mit rootless-Podman erstellt haben. Der Vorgang würde fehlschlagen mit der Meldung: Error: localhost/rhel9.5-bootc:test: image not known.
Um dies zu verhindern, gibt es zwei Möglichkeiten. Möglichkeit 1 bietet sich an, wenn man das ISO-Image auf dem gleichen System wie das Container-Image erzeugen möchte. Hierbei wird das Container-Image einfach in den passenden Benutzerkontext kopiert. Die zweite Möglichkeit besteht darin, das Container-Image in eine Container-Registry zu pushen, aus der es dann im nächsten Schritt wieder gepullt werden kann.
Möglichkeit 1
Das Container-Image wird mit folgendem Befehl aus dem Kontext des Benutzers ‚alice‘ in den Kontext des Benutzers ‚root‘ kopiert.
$ podman image scp alice@localhost::rhel9.5-bootc:test
…
$ sudo podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test fb6237fff684 21 minutes ago 1.68 GB
Selbstverständlich kann das Container-Image auch in einer Container-Registry gespeichert und im root-Kontext von dort wieder heruntergeladen werden. Für die spätere Aktualisierung eines installierten RHEL image mode Systems ist die Nutzung einer Container-Registry von Vorteil.
How to implement a simple personal/private Linux container image registry for internal use beschreibt die Einrichtung einer einfachen Registry. Ich habe die auszuführenden Schritte in dem Skript create_simple_container_registry.sh zusammengefasst. Die zur Ausführung notwendigen Parameter werden in der Datei registry.vars konfiguriert. Diese Datei ist bereits mit Standardwerten gefüllt, die direkt verwendet werden können. Installiert und konfiguriert wird die Registry mit dem Kommando:
$ sudo bash create_simple_container_registry.sh
Ich trage die IP-Adresse und den Hostnamen meiner VM 1 in die Datei /etc/hosts ein, damit die Namensauflösung funktioniert. Der folgende Code-Block zeigt, wie das Image localhost/rhel9.5-bootc in die Registry gepusht wird.
Die Option --tls-verfiy=false ist notwendig, da ein selbstsigniertes TLS-Zertifikat verwendet wird. Mit dem folgenden Befehl kann überprüft werden, ob sich das Image in der Registry befindet.
Der folgende Code-Block zeigt, wie mit dem bootc-image-builder eine ISO-Datei erzeugt wird, die sich für eine RHEL-Installation in einer Offline-Umgebung eignet. Der Befehl muss mit sudo ausgeführt werden, da erweiterte Benutzerrechte erforderlich sind.
Da das Container-Image des bootc-image-builder noch nicht lokal vorliegt, muss zuerst ein Login bei registry.redhat.io erfolgen. Dies wurde weiter oben bereits für den rootless-Benutzer durchgeführt, muss für den rootful-Benutzer jedoch wiederholt werden, da Logins nicht zwischen verschiedenen Benutzerkontexten geteilt werden.
Achtung: Der folgende Befehl funktioniert nur, wenn das Image localhost/rhel9.5-bootc:test für root verfügbar ist. Dies kann durch eine der Methoden, die im vorherigen Abschnitt beschrieben wurden, sichergestellt werden. Ich habe in diesem konkreten Fall Möglichkeit 1 verwendet.
$ sudo podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
$ mkdir output
$ time sudo podman run \
> --rm \
> -it \
> --privileged \
> --pull=newer \
> --security-opt label=type:unconfined_t \
> -v /var/lib/containers/storage:/var/lib/containers/storage \
> -v $(pwd)/config.toml:/config.toml \
> -v $(pwd)/output:/output \
> registry.redhat.io/rhel9/bootc-image-builder:latest \
> --type iso \
> --config /config.toml \
> --local \
> localhost/rhel9.5-bootc:test
…
real 22m31.407s
user 0m1.997s
sys 0m2.049s
$ ls -lh output/bootiso/
total 2.4G
-rw-r--r--. 1 root root 2.4G Jan 11 14:26 install.iso
Nun zur Erklärung des Ganzen:
Der Login erfolgt, um das bootc-image-builder-Image herunterladen zu können
Im Projektverzeichnis wird das Verzeichnis output erstellt, welches die ISO-Datei enthalten wird
Nun folgt ein ziemlich langer Aufruf von podman run
Falls in registry.redhat.io eine neuere Version des bootc-image-builder gefunden wird, wird diese heruntergeladen und genutzt
bootc-image-builder muss mit erhöhten Rechten ausgeführt werden, weshalb die Ausführung mittels sudo und die Option --privileged erforderlich sind
Ort der config.toml und Verzeichnis für das ISO werden dem Container als Volume zugänglich gemacht
Mit --type iso wird festgelegt, dass eine ISO-Datei erstellt werden soll
Die Option --local gibt an, dass das lokal existierende Image localhost/rhel9.5-bootc.test verwendet und dies nicht aus einer Registry geholt werden soll
Dass der Vorgang ganze 22 Minuten dauerte, ist den 2 vCPU-Kernen und den 8 GB RAM meiner VM geschuldet. Während der Arbeitsspeicher gerade ausreichend war, dürften weitere CPU-Kerne den Vorgang deutlich beschleunigen.
Das nun erstellte ISO kann zur Installation in VM 2 verwendet werden.
Offline-Installation mit dem RHEL image mode
Das im vorherigen Abschnitt erstellte Disk-Image install.iso wird nun verwendet, um VM 2 zu installieren. Die Installation läuft wie eine normale unbeaufsichtigte Anaconda-Installation ab.
In der Datei toml.config wurde ein Benutzer mit einem SSH-Schlüssel spezifiziert, der nun zum Login in das neue System verwendet werden kann.
$ ssh -o StrictHostKeyChecking=no alice@vm2.example.com
Warning: Permanently added 'vm2.example.com' (ED25519) to the list of known hosts.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 7.1M 1 loop
sr0 11:0 1 2.4G 0 rom
zram0 251:0 0 7.8G 0 disk [SWAP]
vda 252:0 0 30G 0 disk
├─vda1 252:1 0 1G 0 part /boot
├─vda2 252:2 0 1G 0 part [SWAP]
└─vda3 252:3 0 28G 0 part /var
/sysroot/ostree/deploy/default/var
/etc
/sysroot
$ $ mount | grep -E '"/"|var|sysroot|etc'
/dev/vda3 on /sysroot type ext4 (ro,relatime,seclabel)
composefs on / type overlay (ro,relatime,seclabel,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)
/dev/vda3 on /etc type ext4 (rw,relatime,seclabel)
/dev/vda3 on /sysroot/ostree/deploy/default/var type ext4 (rw,relatime,seclabel)
/dev/vda3 on /var type ext4 (rw,relatime,seclabel)
$ less /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[jkastnin@localhost ~]$ systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-01-14 15:29:07 UTC; 28min ago
Docs: man:httpd.service(8)
Main PID: 829 (httpd)
…
Da ich im Vorfeld keine genaueren Angaben gemacht habe, wurde der Datenträger automatisch partitioniert. Die Installation lässt sich durch Kickstart-Dateien steuern. Dazu wird der Inhalt der Kickstart-Datei in die Datei config.toml eingefügt. Siehe hierzu Kapitel 4.9. Using bootc-image-builder to build ISO images with a Kickstart file in der RHEL-Dokumentation.
Fazit nach der Installation von RHEL image mode
Mit rootless podman wurde ein rhel9.5-bootc:test Image erstellt
Mit dem bootc-image-builder wurde ein ISO-Image erstellt, welchem ein Benutzer mit Passwort und öffentlichem SSH-Schlüssel hinzugefügt wurde und welches sich für die Installation von Offline-Systemen eignet
Das ISO-Image wurde genutzt, um RHEL image mode in einer VM zu installieren
Test von Login und einiger weniger Kommandos
Der konfigurierte Webserver wird ausgeführt und liefert die kleine Beispielwebseite aus
Auf dem Weg hier her wurde erklärt, wie Container-Images mittels podman-image-scp(1) ohne Container-Registry zwischen Benutzerkontexten und Hosts kopiert werden können. Es wurde gezeigt, wie eine einfache Container-Registry betrieben und genutzt werden kann.
Zu den Aufgaben des IT-Betriebs gehört es, Betriebssysteme zu aktualisieren, ihre Konfiguration neuen Anforderungen anzupassen und im Fehlerfall die letzten Änderungen schnell rückgängig machen zu können. Diesen Aufgaben widmen sich die beiden folgenden Abschnitte.
Bootc Image Installation aktualisieren bzw. Konfiguration ändern
Während RHEL package mode Systeme zur Laufzeit mit DNF bzw. YUM aktualisiert werden und mit diesen Werkzeugen Software (de-)installiert wird, ist der Ablauf bei RHEL image mode Systemen anders:
Das RHEL Bootc Image wird aktualisiert
Das aktualisierte Container-Image wird in einer Registry verfügbar gemacht
Das aktualisierte Image wird in den Staging-Bereich des laufenden RHEL image mode Systems geladen
Durch einen Neustart wird das aktualisierte Image geladen
Bei Bedarf, z.B. bei auftretenden Problemen, kann das vorherige Image geladen werden
Aktualisierung des RHEL Bootc Image
Ich möchte die Pakete lsof, strace und tcpdump doch nicht in meiner Standardinstallation haben und sie aus der existierenden Installation entfernen. Deshalb kommentiere die entsprechenden Zeilen aus:
Als Nächstes wird ein neues Image erstellt und in die Registry gepusht. Diesmal verwende ich den Tag 0.0.1, um für den Verlauf dieses Tutorials leichter den Überblick zu behalten:
Das zu verwendende Image aus dem System heraus wechseln
Der nun folgende Schritt wird in dem laufenden RHEL image mode System in VM 2 ausgeführt. In der RHEL-Dokumentation ist dieser Schritt in Abschnitt 8.1. Switching the container image reference beschrieben.
Für diesen Schritt ist eine funktionierende Namensauflösung zwischen VM 1 und VM 2 erforderlich. In der Laborumgebung kann dies mithilfe der Datei /etc/hosts erfolgen. Da in der Registry ein selbstsigniertes Zertifikat verwendet wird und das Kommando bootc keine Option --tls-verify besitzt, muss eine insecure registry in VM 2 konfiguriert werden. Der folgende Codeblock zeigt den Inhalt der Datei, mit der die insecure registry konfiguriert wird:
Da bootc auch nicht über ein Login-Kommando verfügt und keinen Zugriff auf die Login-Informationen von Podman hat, wird in VM 2 ein Pull-Secret für bootc konfiguriert. Dazu wird eine Zeichenkette bestehend aus Benutzername:Passwort in Base-64 kodiert und zusammen mit der Registry-URL in die Datei /etc/ostree/auth.json geschrieben. Der folgende Code-Block zeigt dies mit den Beispielwerten aus diesem Tutorial:
Nach dem Wechsel befindet sich das ab nun zu verwendende Image zunächst im Staging-Bereich des lokalen Systems und wird beim nächsten Neustart aktiviert. Der Befehl bootc status gibt dazu übersichtlich Informationen aus, welches Image gestaged ist und welches aktuell verwendet wird:
~]# bootc status
Current staged image: vm1.example.com:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current booted image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
No rollback image present
Nach einem Neustart wird der Status mit bootc status erneut kontrolliert und wir sehen, dass nun das Image aus der Registry verwendet wird und das vorherige Image für ein Rollback vorgehalten wird:
~]$ sudo bootc status
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
Automatische Aktualisierungen und wie man sie deaktivieren kann
Auf RHEL image mode Systemen existiert ein systemd.timer(5), welcher automatische Updates anstößt. Folgender Code-Block zeigt die Timer- und Service-Unit in VM 2:
$ systemctl status --no-pager bootc-fetch-apply-updates.{timer,service}
● bootc-fetch-apply-updates.timer - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.timer; disabled; preset: disabled)
Active: active (waiting) since Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Until: Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Trigger: Wed 2025-01-15 10:28:13 UTC; 57min left
Triggers: ● bootc-fetch-apply-updates.service
Docs: man:bootc(8)
Jan 15 08:29:37 localhost systemd[1]: Started Apply bootc updates.
○ bootc-fetch-apply-updates.service - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.service; static)
Active: inactive (dead)
TriggeredBy: ● bootc-fetch-apply-updates.timer
Docs: man:bootc(8)
Ein Blick in die Service-Unit verrät, was passiert, wenn diese getriggert wird:
Prüft, ob ein neues Image in der Container-Registry verfügbar ist (Prüfung efolgt auf Digest nicht auf Tag)
Falls ein neues Image verfügbar ist, wird dieses gestaged
Der Host wird automatisch neugestartet, um das neue Image zu laden
Möchte man Aktualisierungen durch andere Verfahren steuern, kann die automatische Aktualisierung wie folgt gestoppt werden:
$ systemctl mask bootc-fetch-apply-updates.timer
Rollback
Angenommen, das System soll auf das zuvor verwendete Conatiner-Image zurückgerollt werden. So kann man sich zuvor mit bootc status einen Überblick verschaffen, welches Image als Rollback-Image eingetragen ist:
Euch fällt evtl. auf, dass zwei Images den gleichen Tag, aber unterschiedliche SHA-256-Prüfsummen haben, und zwei Tags die gleiche Prüfsumme und unterschiedliche Tags. Lasst euch davon bitte nicht irritieren; dies ist nur meiner Spielerei geschuldet.
Bei einem Rollback wird das Image hinter dem Eintrag Current rollback image als Boot-Image verwendet. Ein Rollback wird mit folgendem Kommando ausgeführt:
$ sudo bootc rollback
Next boot: rollback deployment
Nur den Neustart muss man noch selbst durchführen. Nach dem Neustart sieht der Status wie folgt aus:
$ sudo bootc status
[sudo] password for jkastnin:
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Anhand der SHA-256-Prüfsumme ist zu erkennen, dass das vorherige rollback image nun den Platz mit dem vorherigen booted image gewechselt hat. Ein weiterer Aufruf von bootc rollback führt zu einem weiteren Image-Wechsel.
Hinweis: Wenn nach einem Update ein Rollback durchgeführt wird und der Systemd-Timer für automatische Updates nicht deaktiviert wurde, führt dieser Timer bei Ablauf zu einem erneuten Update des Systems.
Ende
Hier endet die Einführung in RHEL image mode. Wer dem Tutorial aufmerksam gefolgt ist, sollte an dieser Stelle in der Lage sein:
RHEL Bootc Images zu erstellen
Eine einfache Container-Registry mit Podman zu betreiben
Mit bootc-image-builder Disk-Images zu erstellen
Ein System im RHEL image mode zu installieren
Das installierte System zu aktualisieren
Zu einem anderen Image zu wechseln
Ein Rollback auf das vorherige Image durchzuführen
Wenn euch diese Einführung gefallen hat, freue ich mich, wenn ihr sie mit euren Netzwerken teilt. Nutzt gern die Kommentarfunktion, um mich wissen zu lassen, wie euch diese Einführung gefallen hat.
Falls ihr euch weitere Artikel rund um den RHEL image mode wünscht, teilt mir dies gern ebenfalls über die Kommentarfunktion mit.
Thematisch haben sich fast alle Artikel mit Freier Software und Open Source beschäftigt oder waren daran angelehnt. Wie auch in den vorangegangenen Jahren habe ich keine bewussten Themenschwerpunkte gesetzt, sonder über die Themen geschrieben, dich mich in der jeweiligen Zeit interessierten und mich beschäftigt haben.
Zu Beginn des Jahres hatte es mir das Thema IPv6 angetan, wozu vier Beiträge erschienen sind:
Das Thema begleitet mich auch weiterhin, jedoch gibt es bisher keine spannenden Neuigkeiten, die ich für berichtenswert halte. Ich fürchte, IPv6 wird sobald nicht die Weltherrschaft an sich reißen.
Ein Thema, welches mir sehr wichtig war und ist, ist die Dokumentation für den Notfall bzw. das digitale Erbe. Wie die Kommentare zu diesem Artikel bezeugen, bin ich nicht der Einzige, der sich darum Gedanken macht. Leider bin ich 2024 kaum damit vorangekommen und schiebe es weiter vor mir her. Dies ärgert mich etwas, da ich mir wünsche, mich für ein so wichtiges Thema besser aufraffen zu können.
In 2024 wurden wir auf allen Kanälen mit Künstlicher Intelligenz, Maschinellem Lernen und großen Sprachmodellen überflutet. Es fällt schon fast schwer noch irgendeine Anwendung oder ein Produkt ohne AI kaufen zu können. Abseits des Hypes habe ich mich ebenfalls mit dem Thema beschäftigt und zwei Beiträge ( [1] und [2]) dazu geschrieben. Ich bin überzeugt, dass die verschiedenen Spielarten der künstlichen Intelligenz unser Leben und unsere Art zu Arbeiten stark beeinflussen und verändern werden. Daher werde auch ich hier am Ball zu bleiben, um nicht von der laufenden Entwicklung abgehängt zu werden.
Fazit
Damit sind 2024 insgesamt 26 Artikel erschinen. Das sind 19 weniger als in 2023. Mein selbst gestecktes Ziel, jeden Monat mindestens zwei Artikel zu veröffentlichen habe ich ebenfalls nicht erreicht. Da dies mein Hobby ist und mir primär Freude bereiten soll, setze ich mich durch diese Zielverfehlung nicht unter Druck.
Das Jahr 2025 lasse ich ohne große Ziele und Bestrebungen auf diesen Blog zukommen. Nur eines ist sicher, ich werde meine Texte weiterhin selbst und ohne KI-Unterstützung schreiben. Denn damit würde ich mir nur selbst die Freude am Bloggen nehmen.
Ich freue mich, wenn ich auch 2025 wieder interessantes Wissen in meinen Texten mit euch teilen kann. Ich wünsche euch einen guten Rutsch ins Jahr 2025!
Als privates Mobiltelefon benutze ich seit 2022 ein Samsung Galaxy S22 mit einem Congstar-Tarif, welcher mich im Monat 10,- EUR kostet. Ich bin mit dem Gerät weiterhin zufrieden und plane, es in 2025 ebenfalls zu nutzen.
Im Folgenden führe ich einige von mir genutzte Apps auf, mit einer kurzen Erklärung, wofür ich diese verwende. Wo möglich verlinke ich in den F-Droid Store. Wo dies nicht möglich ist, führen diese in den Google Play Store.
Hier die am häufigsten verwendeten Apps zählen in alphabetischer Reihenfolge:
Mittels der integrierten Backup- und Import-Funktion nutze ich die gleichen Daten auch auf meinem Diensthandy; so bleibt der Zugriff auf meine Online-Accounts auch bei Verlust eines Telefons erhalten
Amazon – Ja, ich kaufe bevorzugt online, da es bequem ist und es bei Rücksendungen und Umtausch keine Diskussionen gibt
ChatGPT (Google Play Store) nutze ich auf dem Handy nur sehr sporadisch; ob es bessere Ergebnisse als eine klassische Suchanfrage liefert, kann ich aktuell noch nicht beurteilen
Evtl. ist euch aufgefallen, dass eine prominente App in obiger Aufzählung fehlt. Tatsächlich widerstehe ich weiterhin dem sozialen Druck und verweigere mich der Nutzung von WhatsApp. Der Verzicht auf WhatsApp schnitt mich leider ausgerechner bei der Freiwilligen Feuerwehr von einem Teil der Kommunikation ab. Daher freue ich mich nun umso mehr, dass unsere Feuerwehr zur Planung von Dienstabenden, Veranstaltungen und sonstigen Terminen auf Spond (Google Play Store) umgestiegen ist.
Ich nutze auch Online-Banking-Apps auf dem Smartphone. ich nutze diese z.B., um am Laptop getätigte Überweisungen oder Online-Einkäufe zu autorisieren. Darüber hinaus schätze ich die Benachrichtigung über getätigte Umsätze.
Insgesamt sind aktuell 168 Apps installiert. Ehrlicherweise werde ich vermutlich erst ausmisten, wenn der Speicher knapp wird.
Ach ja, telefonieren tue ich damit natürlich auch. ;-)
Tablet
Seit Mitte 2019 [verwende ich] auch ein Samsung T830 Galaxy Tab S4 Wi-Fi Tablet. Durch seine 10,5 Zoll (ca. 27 cm) Bildschirmdiagonale, das geringe Gewicht und mit der App ReadEra eignet es sich hervorragend zum Lesen von PDF-Dateien und E-Books.
Lesen im Internet (Blogs, Dokus, etc.) mit Firefox Klar
Dabei verwende ich mehr oder weniger die gleichen Apps wie auf dem Smartphone. Für den Zugriff auf Mastodon verwende ich hier statt Fedilab die App Tusky (F-Droid).
Seit 2024 neu auf dem Tablet sind FeedMe (Google Play Store) und Wallabag (Google Play Store). FeedMe teste ich als Alternative zu Feedly (Google Play Store), da dieser die Synchronisierung mit meiner FreshRSS-Instanz unterstützt. Er ist etwas langsam, ansonsten zufriedenstellend. In Wallabag speichere ich Artikel, die ich später lesen oder für Workshops, Talks und Blog-Artikel nutzen möchte.
Das Betriebssystem wurde im Laufe der Zeit von Fedora 37 auf Fedora 40 aktualisiert; Das Upgrade auf Fedora 41 folgt bald
Nach Rambox ist auch hamsket entsorgt worden, da mich diese Apps im Laufe der Zeit doch mehr genervt als unterstützt haben
Dienste wie Element, Mastodon, GMail, Slack, etc. nutze ich jetzt direkt im Webbrowser
Ich nutze die Funktion Tabs zu pinnen, um häufig verwendete Dienste im Browser im schnellen Zugriff zu haben
Der Laptop ist mein Hauptarbeitsmittel, den ich für so gut wie alle anfallenden Aufgaben verwende. Lediglich zum Lesen von E-Books bevorzuge ich das Tablet und zum Instant Messaging das Smartphone.
Mein Lieblingsbrowser ist Firefox
Mein Lieblingseditor ist Vim
Thunderbird ist die Anwendung meiner Wahl für Aufgaben, E-Mail und Kalender
Ich habe immer mal wieder Evolution ausprobiert, da dies eine bessere Integration in GNOME bietet. Doch bin ich nie damit warm geworden. Da ich mehrere E-Mail-Konten bei verschiedenen Anbietern sowie Kalender für verschiedene Zwecke habe, finde ich die Zusammenführung und Nutzung in Thunderbird ideal.
Desktop-/Server-PC
Mein ehemaliger Desktop-PC ist in ein 19-Zoll-Gehäuse und mit diesem in einen Serverschrank im Keller umgezogen. Die ganze Geschichte dazu kann in „Ein Serverschrank mit Kompromissen“ nachgelesen werden.
Ein Selbstbau mit RHEL dient mir als Libvirt/KVM-Hypervisor für virtuelle Maschinen
Als dauerhaft laufender Rechner führt dieser Host meine Cronjobs und Ansible-Playbooks aus, erzeugt Backups und kopiert/synchronisiert Daten von hier nach dort.
Die Untersützung von Podman bzw. der weiteren Container-Tools Buildah und Skopeo in RHEL ist super. Die kostenlose Developer Subscription for Individuals ermöglicht mir die produktive Nutzung von bis zu 16 RHEL-Servern. Das sind mehr als genug für meine privaten Zwecke.
Sonstige Geräte im Netzwerk
Mein Brother DCP-540CN wurde dieses Jahr nach 18 Jahren ausgemustert; ich nutze jetzt einen Brother MFC-J890DW im Haus mit, falls ich mal etwas drucken muss
Hier hat es im laufenden Jahr keine Änderungen gegeben. Ich gehe davon aus, dass es hier in 2025 ebenfalls keine Änderungen geben wird. Drei neue Dienste sind hinzugekommen, die ich bei adminforge.de nutze. Dies sind:
DNSforge
Bandbreite messen
ToDo App
FreshRSS Reader
Linkwarden
Wallabag
Die letzten vier befinden sich noch in der Testphase. Ob die Nutzung in 2025 anhält, werdet ihr im nächsten Rückblick erfahren können.
Ich freue mich, wenn euch dieser kleine Überblick gefällt und ihr vielleicht die ein oder andere Inspiration darin findet. Ich freue mich auch, wenn ich in euren Blogs lesen kann, womit ihr 2024 so gearbeitet habt.
Neben der Online-Version im Single- und Multi-Page-Format kann man die einzelnen Texte auch als PDF herunterladen. Dies manuell zu tun, ist allerdings mühselig. Deutlich leichter geht es mit dem PDF Document Downloader von Kazuo Moriwaka. Es handelt sich dabei um ein Bash-Skript, bestehend aus awk, curl, grep, und parallel, welches als Argument die Basis-URL für eine Produktkategorie übernimmt und anschließend alle PDF-Dateien ermittelt und herunterlädt.
Klingt gut? So bekommt ihr das Skript:
Ladet euch die aktuelle Version als Zip-Datei aus dem Gist herunter
Entpackt das Zip-Archiv in ein Verzeichnis eurer Wahl, z.B. nach ~/bin/
Macht das Skript ausführbar: chmod u+x ~/bin/fetchdoc.sh
Folgender Code-Block zeigt einige Beispiele, mit denen ich mir einen Teil der Dokumentation auf mein Laptop gezogen habe:
Meine Gedanken zu dem Artikel und dem Thema möchte ich an dieser Stelle mit Fryboyter und euch teilen.
Fryboyter favorisiert nach eigener Darstellung Calendar Versioning (CalVer), da dies seiner Meinung nach aussagekräftiger ist, als z.B. 0.78.1, was sehr stark nach Semantic Versioning (SemVer) aussieht. Meiner Meinung nach kann man dies nicht pauschal sagen, da beide Versionsschemata ihre eigenen Vor- und Nachteile haben. Doch wann sollte man zu welchem Schema greifen?
Calendar Versioning
Die folgende Liste ist eine Übersetzung des englischen Textes, welcher hier zu finden ist. Wenn einer der in dieser Liste genannten Punkte auf ein Projekt zutrifft, scheint CalVer ein geeignetes Schema für die Versionierung zu sein.
Hat Ihr Projekt einen großen oder ständig wechselnden Umfang?
Große Systeme und Frameworks, wie Ubuntu und Twisted.
Amorphe Gruppen von Dienstprogrammen, wie Boltons.
Ist Ihr Projekt in irgendeiner Weise zeitkritisch? Beeinflussen externe Änderungen neue Projektveröffentlichungen?
Geschäftliche Anforderungen, wie Ubuntus Fokus auf Unterstützungstermine.
Sicherheitsupdates, wie certifi’s Notwendigkeit, Zertifikate zu aktualisieren.
Politische Veränderungen, wie die Handhabung von Zeitzonenänderungen durch die IANA-Datenbank.
Einige Betriebssysteme wie z.B. Ubuntu haben einen festen Veröffentlichungsrythmus und Unterstützungszeitraum. So werden Ubuntu LTS Versionen ohne Zusatzverträge für 5 Jahre unterstützt und mit Aktualisierungen versorgt. Bei Ubuntu 24.04 LTS kann man bereits am Namen erkennen, wie alt dieses Release ist und wie lange es mit Aktualisierungen versorgt wird. Ubuntu veröffentlicht Aktualisierungen für die enthaltenen Pakete in unregelmäßigen Abständen, meist sobald diese verfügbar sind. Aufgrund der vielen enthaltenen Pakete und der Aktualisierungsrichtlinie scheint SemVer (siehe nächster Abschnitt) hier nicht vorteilhaft zu sein.
Bei Debian 12, RHEL 9 oder SLES 15 erkennt man das Datum der Veröffentlichung hingegen nicht. Hier hilft nur ein Blick in die jeweilige Versionshistorie der Projekte, um Informationen über den Zeitpunkt der Veröffentlichung und der jeweiligen Unterstützungszeiträume zu finden.
Semantic Versioning
Auf Grundlage einer Versionsnummer von MAJOR.MINOR.PATCH werden die einzelnen Elemente folgendermaßen erhöht: 1. MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden, 2. MINOR wird erhöht, wenn neue Funktionalitäten, die kompatibel zur bisherigen API sind, veröffentlicht werden, und 3. PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.
SemVer ist stringent, einfach nachzuvollziehen und bietet für mich als Systemadministrator die folgenden Vorteile.
Wird PATCH erhöht, weiß ich, dass lediglich Fehler behoben wurden, sich am Funktionsumfang einer Anwendung jedoch nichts ändert. Das Einzige, was mir hierbei den Tag vermiesen kann, sind Regressionen. Das Risiko, dass irgendetwas kaputtgeht oder schlimmer wird, ist jedoch gering.
Wird MINOR erhöht, weiß ich, dass die Anwendung neue Funktionalität enthält und ich weiß, dass nun ein genauerer Blick erforderlich ist, um zu entscheiden, ob diese Funktionalität in meiner Umgebung bereitgestellt werden soll bzw. darf. Gegebenenfalls sind vor einer Aktualisierung Anwenderschulungen durchzuführen und interne Prozessbeschreibungen zu aktualisieren, bevor die neue Version zur Nutzung freigegeben werden kann.
Einem an Featureritis erkrankter Nerd mag jede neue Funktion gefallen. Unzureichend geplante Veröffentlichungen neuer Funktionen in Unternehmen können hingegen interessante Folgen haben.
Wird MAJOR erhöht, ist ein Blick in die Release Notes angeraten. Denn man weiß schon mit einem Blick auf die Versionsnummer, dass diese Version Breaking Changes enthält. Dies können sein:
API-inkompatible Änderungen
Entfallene bzw. entfernte Funktionalität
Geänderte Architektur
Geändertes Format der Konfigurationsdatei(en)
etc.
Eine solche Aktualisierung kann man in aller Regel nicht ohne sorgfältige Planung installieren. Das Risiko, dass dabei etwas kaputtgeht und Stress und Produktionsausfall folgen ist einfach zu groß.
Aussagekraft
Fryboyter schreibt: „Zumal meiner Meinung nach 2024.10.11 aussagekräftiger als 0.78.1 ist.“
Aber ist es wirklich aussagekräftiger? Wenn ich nur das Datum sehe, weiß ich lediglich, wann die Version veröffentlicht wurde. Welchen Funktionsumfang die Version hat, welche Änderungen es zur vorhergehenden Version es gibt, ob diese Version stabil ist oder ob es die aktuellste Version ist, erkennt man nicht. Bei zwei Daten erkennt man zumindest, welches die aktuellere Version ist.
Sehe ich nur 0.78.1, weiß ich nicht, wann diese Version veröffentlicht wurde. Ich sehe jedoch auf den ersten Blick, dass sich diese Version in einer initialen Entwicklungsphase befindet, der Funktionsumfang nicht abschließend definiert ist und sich jederzeit ändern kann. Kurz gesagt, mit jeder weiteren Erhöhung von MINOR und PATCH ist damit zu rechnen, dass sich das Verhalten und der Funktionsumfang signifikant ändern. Da die einzelnen Elemente bei SemVer ausschließlich erhöht jedoch nie gesenkt werden, kann man bei Vorliegen von zwei Versionsnummern der gleichen Anwendung erkennen, welches die aktuellere ist. Details zu Änderungen gegenüber der Vorgängerversion verrät SemVer zwar auch nicht, doch kann ich den Umfang der Änderungen erkennen. Für mich besitzt SemVer damit in den meisten Fällen die größere Aussagekraft.
Die Frage wann es Zeit für Version 1.0.0 ist, beantwortet SemVer wie folgt:
Wenn die Software schon in der Produktion verwendet wird, sollte sie bereits in Version 1.0.0 vorliegen. Falls eine stable API existiert, auf die sich Nutzer bereits verlassen, sollte es ebenfalls die Version 1.0.0 sein. Auch wenn Kompatibilität zu vorherigen Versionen bereits eine wichtige Rolle spielt, ist Version 1.0.0 angebracht.
Ich gehöre tendenziell eher zu Team SemVer und denke, dass dies eine höre Aussagekraft als CalVer besitzt.
Grundsätzlich halte ich es für sinnvoll und wichtig, wenn sich Entwickler bzw. Organisationen Gedanken machen, welches Versionsschema am besten zu ihrem Projekt passt.
Wie denkt ihr darüber? Hinterlasst doch gern einen Kommentar mit eurer Meinung oder veröffentlicht einen eigenen Text dazu in eurem Blog.
Dieser Artikel gibt meine Motivation für den Bau von Container-Images und die Vorgehensweise wieder und zeigt, wie ich mit Buildah meine OCI-kompatiblen Container-Images erstelle.
Es handelt sich dabei mehr um einen Erfahrungsbericht als ein Tutorial und ich erhebe keinen Anspruch auf Vollständigkeit. Das behandelte Beispiel ist jedoch zum Einstieg und zur Nachahmung für all jene geeignet, die Container ausführen können und diese gerne ohne Verwendung von Containerfiles bauen möchten.
Motivation
Ich möchte die Ansible-Rollen aus meiner Collection tronde.nextcloud mit Molecule und Podman-Containern testen. Als Zielplattform für das Deployment der Nextcloud unterstütze ich zunächst Debian und RHEL.
Die Tests sollen verifizieren, dass Nextcloud im Container in einer rootless-Podman-Umgebung bereitgestellt werden kann. Da der Test unter Verwendung von Podman-Containern durchgeführt werden soll, müssen diese Container eine solche rootless-Podman-Umgebung bereitstellen.
Für RHEL 8 und RHEL 9 habe ich entsprechende Container-Images gefunden. Für Debian bin ich nicht fündig geworden und habe daher beschlossen, diese Container-Images selbst zu erstellen.
Buildah ist das Werkzeug meiner Wahl, da:
Container-Images damit interaktiv erstellt werden können,
die verwendeten Befehle am Ende in einem Bash-Skript gesammelt werden können,
sich damit sogar interaktive Abfragen mit Heredocs beantworten lassen,
man kein containerfile(5) benötigt und
ich das Werkzeug noch nicht kenne und es gerne kennenlernen möchte.
Für mich sind dies ausreichend Gründe, um mich kopfüber in ein neues Container-Projekt zu stürzen. Wer mehr über die Beziehung von Buildah zu Podman erfahren möchte, dem empfehle ich den englischsprachigen Artikel: Buildah and Podman Relationship von Tom Sweeney.
Die folgenden Code-Blöcke zeigen Auszüge aus dem Skript buildah_create_debian_bookworm_with_rootless_podman.sh (Commit 7634ed8). Die enthaltenen Befehle werden unter dem jeweiligen Code-Block erläutert. Alle Befehle werden als normaler Benutzer ohne Root-Rechte ausgeführt.
# Name of target container image
tctri=debian_rootless_podman
# Get a base image
ctr=$(buildah from --pull=newer docker://docker.io/library/debian:bookworm)
Die Variable tctri nimmt den Namen des Container-Images auf, welches ich erzeugen werde
Die Variable ctr nimmt den Namen des Containers auf, welcher durch den buildah-from(1)-Befehl erzeugt wird; mit diesem Container wird im Folgenden gearbeitet
Die Option --pull=newer sorgt dafür, dass das Image nur dann aus der angegebenen Registry heruntergeladen wird, wenn es aktueller als das evtl. lokal gespeicherte Image ist
buildah run -- $ctr apt -y update
buildah run -- $ctr apt -y upgrade
buildah run -- $ctr apt -y install podman fuse-overlayfs libvshadow-utils libcap2-bin ca-certificates
Mit buildah-run(1) werden Befehle innerhalb des Arbeits-Containers ausgeführt
Ich aktualisiere die im Basis-Image enthaltenen Pakte und
installiere die für rootless Podman benötigten Pakete
Das Paket ca-certificates wird benötigt, um später Container-Images aus einer Registry herunterladen zu können
buildah run -- $ctr useradd podman
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subgid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subgid"
buildah run -- $ctr setcap cap_setuid+epi /usr/bin/newuidmap
buildah run -- $ctr setcap cap_setgid+epi /usr/bin/newgidmap
Mit den hier dargestellten Befehlen wird der nicht-privilegierte Benutzer podman erstellt
Die IDs für /etc/sub[g,u]id habe ich mir aus dem ubi9/podman-Image abgeschaut
Die setcap-Befehle sind notwendig, um rootless Podman ausführen zu können; ich habe sie durch Internetrecherche und Trial-and-Error zusammengestellt
Ich erstelle die Verzeichnisse, die ich im Artikel [7] gefunden habe
Ich erstelle die Environment-Variable, die ich ebenfalls in genanntem Artikel [7] gefunden habe
buildah run -- $ctr apt -y reinstall uidmap
buildah run -- $ctr apt -y clean
buildah run -- $ctr rm -rf /var/lib/apt/lists/*
Aus mir nicht bekannter Ursache muss das Paket uidmap neu installiert werden, um ein UID/GID-Mapping sicherzustellen; dies scheint analog zur Neuinstallation der shadow-utils in Artikel [7] notwendig zu sein
Die beiden folgenden Befehle sollen den Paket-Cache aufräumen, um die Größe des resultierenden Images zu verkleinern, zeigen jedoch keinen sichtbaren Effekt
# Commit to an image
buildah commit --rm $ctr $tctri
# Alternative: Use this and add GPG fingerprint for image signing
# buildah commit --sign-by <fingerprint> --rm $ctr $tctri
# Tag the image just created
buildah tag $tctri $tctri:bookworm-$(date --iso)
Mit buildah-commit(1) wird der Inhalt des Arbeits-Containers $ctr in ein Container-Image namens $tctri geschrieben
Durch Angabe der Option --rm wird der Arbeits-Container entfernt
Die Kommentarzeile lässt erkennen, dass ich zukünftig beabsichtige, meine Images digital zu signieren
Der Befehl buildah-commit(1) fügt dem neuen Image übrigens nur einen weiteren Layer hinzu, egal wie viele Befehle zuvor im Arbeits-Container ausgeführt wurden. Das erzeugte Image umfasst also die Layer des Basis-Image plus einen weiteren.
Zwischenfazit
An diesem Punkt habe ich ein Basis-Image ausgewählt, mithilfe von buildah zusätzliche Software installiert, einen Benutzer hinzugefügt und ein neues Image erzeugt.
Die fertigen Images halte ich in der Registry https://quay.io/repository/rhn-support-jkastnin/debian_rootless_podman vor. Fühlt euch frei, diese für eigene Experimente zu benutzen, doch verwendet sie nur mit Vorsicht in Produktion. Ich erzeuge diese Images nur nach Bedarf neu, so dass die veröffentlichen Versionen veraltet und voller Sicherheitslücken sein können.
Validierung
Jetzt, wo die Images fertig sind, kann ich prüfen, ob sich rootless Podman darin auch wie gewünscht ausführen lässt.
Die Prozesse innerhalb des von meinem Container-Image instanziierten Containers laufen als Benutzer root. Um die Prozesse als Benutzer podman auszuführen, ist dies beim Aufruf von podman run explizit mit anzugeben. Der folgende Code-Block verdeutlicht dies und zeigt zugleich den ersten Fehler beim Versuch rootless Podman auszuführen.
]$ podman run --rm localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=0(root) gid=0(root) groups=0(root)
]$ podman run --rm --user podman localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=1000(podman) gid=1000(podman) groups=1000(podman)
]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
time="2024-09-21T18:43:35Z" level=error msg="running `/usr/bin/newuidmap 15 0 1000 1 1 1 999 1000 1001 64535`: newuidmap: write to uid_map failed: Operation not permitted\n"
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1
Der Fehler deutet auf fehlende capabilities(7) hin. Um diese Hypothese zu testen, wiederhole ich den letzten Befehl mit der Option --privileged (siehe dazu podman-run(1)):
]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse --privileged localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…
Damit funktioniert es. Leider geben sich viele Menschen an dieser Stelle mit dem Ergebnis zufrieden. Doch ich möchte diese Container nicht einfach mit --privileged ausführen. Also studiere ich die Manpage capabilities(7) und teste mich Stück für Stück heran, bis ich mit dem folgenden Kommando ebenfalls erfolgreich bin:
]$ podman run --rm --user podman --security-opt label=disable --device /dev/fuse --cap-add=setuid,setgid,sys_admin,chown localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…
Dies ist schon deutlich besser, da dem Container hiermit deutlich weniger Privilegien eingeräumt werden müssen. Das Thema Container-Privilegien und capabilities(7) werde ich noch genauer untersuchen. Eventuell folgt dazu dann auch ein weiterer Artikel. Für den Moment ist das Ergebnis gut genug.
In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen Erfahrungen.
Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.
Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.
Informationen zum Bericht
Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.
Nutzung und Verbreitung von Open Source in Unternehmen
Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage.
Auf Seite 8 findet sich die Aussage, dass 40 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg.
Interessant finde ich die genannten Gründe für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.
Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.
Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.
Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einführen, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.
Herausforderungen beim Einsatz von Open Source
Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem benötigten Wissen einzustellen.
Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterstützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.
Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.
Updates und Patches
Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.
Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.
Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.
Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.
Ich erinnere mich an die schöne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam für den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchführen zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.
Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.
Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:
Anwendung bzw. Dienste stoppen
Updates/Patches installieren
System neu starten
Anwendung bzw. Dienste starten
Anwendung/Dienst auf korrekte Ausführung testen
Bei Fehlschlag –> Rollback bzw. bei Erfolg –> Update erfolgreich
Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.
Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erwägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.
Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.
Wartung von End-of-Life Versionen
Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.
Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,
Von der im Unternehmen niemand mehr weiß, wie sie funktioniert, um sie auf ein neues Betriebssystem zu migrieren
Für deren Migration keine Ressourcen verfügbar sind
Mit der komplizierte und langwierige Abstimmungsprozesse zur Migration verbunden sind; niemand will das Ding anfassen
Die für keine aktuellere Betriebssystem-Version zertifiziert ist
Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am häufigsten eingesetzten Distributionen.
Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit für Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.
Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelmäßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.
In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es häufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.
Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.
Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.
Open Source Distributionen
In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%.
Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8.
Der Bericht von 2024 spekuliert, dass Red Hat’s Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.
Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.
Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.
Cloud-Native Open Source Technologies
Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.
Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.
Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht.
Ich freue mich darauf, diese Kategorie über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.
Automations- und Konfigurations-Management
Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.
Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.
Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.
Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.
Fazit
Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.
Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.
In diesem Beitrag erkläre ich kurz, was Ansible Lint ist und demonstriere dessen Anwendung am Beispiel meiner Ansible Collection tronde/nextcloud.
Er richtet sich primär an Personen, die mit Ansible Lint noch nicht vertraut sind. Linting-Profis werden vermutlich keine neuen Erkenntnisse gewinnen.
Was ist Ansible Lint und wofür ist es gut?
Lint (englisch für „Fussel“) ist eine Software zur statischen Code-Analyse. Davon abgeleitet hat sich das Verb linten (englisch to lint) für das Durchführen der statischen Code-Analyse etabliert.
Dem obigen Zitat und der Projektdokumentation folgend, ist Ansible Lint dementsprechend ein Werkzeug zur statischen Code-Analyse von Ansible Playbooks, Roles und Collections. Mit der Anwendung dieses Werkzeugs auf die eigenen Ansible-Inhalte kann sichergestellt werden, dass diese gängigen Konventionen und Standards entsprechen.
Ansible Lint liefert eine ganze Reihe von Profilen mit, welche Autoren unterstützen, die Code-Qualität schrittweise zu verbessern. Der Befehl ansible-lint --list-profiles gibt die verfügbaren Profile mit einer Beschreibung aus.
Ich werde im Folgenden mit dem Profil shared arbeiten, welches für Autoren gedacht ist, die ihre Collection auf https://galaxy.ansible.com veröffentlichen möchten.
Eine Collection linten
Bevor es zur Sache geht, wechsel ich in das Projektverzeichnis meiner Ansible Collection und erstelle einen neuen Branch, mit dem Befehl git checkout -b lint. Die in meinem Repo vorhandene Datei .ansible-lint-ignore lösche ich, da ich im folgenden alle Fehler und Regelverstöße sehen möchte. Zu Beginn stellt sich mein Arbeitsverzeichnis wie folgt dar:
(adt) nextcloud]$ git status
On branch lint
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: .ansible-lint-ignore
no changes added to commit (use "git add" and/or "git commit -a")
Das Programm ansible-lint besitzt mit der Option --fix die Fähigkeit, Fehler automatisch zu korrigieren und auch YAML-Dateien neu zu formatieren. Der folgende Code-Block umfasst die gekürzte Ausgabe, wenn das Kommando ansible-lint --profile=shared --fix im Arbeitsverzeichnis ausgeführt wird.
(adt) nextcloud]$ ansible-lint --profile=shared --fix
WARNING Listing 37 violation(s) that are fatal
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
galaxy.yml:1
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
…
risky-file-permissions: File permissions unset or incorrect.
roles/backup_restore_nextcloud/tasks/main.yml:18 Task/Handler: Copy backup files to container host
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:40 Task/Handler: Import tarball contents into an existing podman volume
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:54 Task/Handler: Export podman volumes to tarballs
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (MYSQL_DATABASE) (vars: MYSQL_DATABASE)
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml:13
…
Read documentation for instructions on how to ignore specific rule violations.
Modified 6 files.
Rule Violation Summary
count tag profile rule associated tags
33 var-naming[pattern] basic idiom
1 risky-file-permissions safety unpredictability
1 galaxy[no-changelog] shared metadata
2 no-changed-when shared command-shell, idempotency
Failed: 37 failure(s), 0 warning(s) on 25 files. Profile 'shared' was required, but 'min' profile passed.
Obige Ausgabe:
Benennt Funde mit Pfadangabe und Zeilennummer
Führt 37 Fehler auf, inkl. der Regeln, die nicht eingehalten werden; Beispiele
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
risky-file-permissions: File permissions unset or incorrect.
no-changed-when: Commands should not change things if nothing needs doing.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.
Informiert, dass ansible-lint Änderungen an 6 Dateien vorgenommen hat
Mit git diff verschaffe ich mir einen Überblick, welche Änderungen ansible-lint vorgenommen hat. Dies sind in meinem Fall:
galaxy[no-changelog]: No changelog found. Please add a changelog file.
Unter Galaxy: Changelog Details finden sich Hinweise, wie dieser Fehler zu beheben ist. Ich erstelle die leere Datei CHANGELOG.md im Wurzelverzeichnis meiner Collection und der Fehler ist abgestellt.
Natürlich werde ich diese Datei zukünftig nutzen, um die wichtigsten Änderungen zu dokumentieren. ;-)
risky-file-permissions: File permissions unset or incorrect.
Auch hier habe ich kurz in der Dokumentation unter risky-file-permissions nachgesehen. Den Fehler habe ich abgestellt, indem ich den Parameter mode: 0600 zum Task hinzugefügt habe.
Dies war ein Flüchtigkeitsfehler, wie er häufig passieren kann, wenn man seinen Code nicht konsequent überprüft. Ohne den Dateimode explizit zu setzen, kann dies zu unvorhersehbaren bzw. überraschenden Verhalten führen.
no-changed-when: Commands should not change things if nothing needs doing.
An zwei Stellen bin ich leider nicht herumgekommen, das ansible.builtin.command Modul zu verwenden, da kein natives Modul für diese Aufgabe existiert. Betrachtet man sich die beiden Tasks fällt auf, dass diese jedes Mal Daten verarbeiten werden. Sie sind nicht idempotent. Im Ergebnis können sie erfolgreich sein oder fehlschlagen, aber sie werden immer Daten verarbeiten und dadurch ändern.
Um herauszufinden, wie ich ansible-lint zufriedenstellen kann, schaue ich wieder in der Doku unter no-changed-when nach. Nach der dortigen Beschreibung ist mein Fehler, dass ich den Rückgabewert des Kommandos nicht behandel. Daher registriere ich nun eine Variable je Task, die die Task-Ausgabe aufnimmt und prüfe den Rückgabewert. Ist der Rückgabewert gleich 0 wird der Task-Status auf changed gesetzt, ist der Rückgabewert ungleich 0 wird der Status entsprechend auf failed gesetzt. Das ganze sieht nun wie folgt aus:
Collection-intern verwendete Variablen leite ich mit zwei Unterstrichen (‚_‘) ein, um mir zu verdeutlichen, dass diese nicht durch den Nutzer gesetzt werden und daher auch nicht im README.md oder defaults/main.yml dokumentiert sind.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.
Hier brauche ich nicht weiter nachzuschlagen. Ich verstoße gegen diese Regel, da ich meine Variablen-Namen großgeschrieben habe. Die Ausgabe von ansible-lint zeigt dies deutlich:
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
Diese Meldungen lassen sich mit folgendem Bash-Einzeiler abstellen:
$ for text in $(cut -d':' -f 1 roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml | grep -v '^$\|^#\|---'); do find roles -type f -iname "*.yml" | xargs sed -i -e "s/$text/\L&/g"; done
Aus verschiedenen Gründen hebe ich mir die Überarbeitung für später auf und nutze die Meldung, um zu demonstrieren, wie man ansible-lint dazu bringt, bestimmte Fehler zu ignorieren.
Um Regeln für ausgewählte Dateien zu ignorieren, spezifiziert man den jeweiligen Dateinamen und den Namen der Regel in der Datei .ansible-lint-ignore, welche im Wurzelverzeichnis der Collection erstellt wird:
Damit habe ich alle Probleme, die im ersten Durchlauf von ansible-lint gefunden wurden, adressiert. Ein zweiter Durchlauf zeigt das Ergebnis meiner Arbeit:
(adt) nextcloud]$ ansible-lint --profile=shared
WARNING Listing 33 violation(s) marked as ignored, likely already known
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML) (warning) # ignored
roles/backup_restore_nextcloud/defaults/main.yml:4
…Ausgabe gekürzt
WARNING Listing 1 violation(s) that are fatal
yaml[octal-values]: Forbidden implicit octal value "0600"
roles/backup_restore_nextcloud/tasks/main.yml:22
Read documentation for instructions on how to ignore specific rule violations.
Rule Violation Summary
count tag profile rule associated tags
1 yaml[octal-values] basic formatting, yaml
Failed: 1 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'min' profile passed.
Die ignorierten Regelverstöße werden als Warnung weiterhin ausgegeben, nehmen jedoch keinen Einfluss auf die abschließende Bewertung. Dafür habe ich einen neuen Fehler (yaml[octal-values]) eingebaut. Nach dem aktuellen Regelwerk erfordern oktale Werte ein explizites Quoting, um als Strings verarbeitet zu werden.
Nachdem ich das Problem mit mode: '0600' behoben habe, endet ein weiterer Lauf von ansible-lint schlussendlich mit:
Passed: 0 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'production' profile passed.
Damit erfüllt meine Collection aktuell sogar die Anforderungen des nächst höheren Profils production; allerdings nur, weil ich einige Regeln bewusst ignoriere. Daher ist aktuell noch nicht sichergestellt, dass meine Collection tatsächlich bei einem Import auf Ansible Galaxy akzeptiert wird.
Zusammenfassung
Ansible Lint ist ein Werkzeug zur statischen Analyse von Ansible Playbooks, Roles und Collections
Das Werkzeug unterstützt Autoren dabei, gängige Konventionen und Standards einzuhalten und die Qualität des eigenen Codes auf einem Mindest-Niveau zu halten
Ansible Lint bietet mehrere Profile für verschiedene Anwendungsfälle
Regeln können bei Bedarf ignoriert werden, was zwar das Ergebnis des Linting beeinflusst, die Qualität jedoch nicht steigert
Linting sollte fester Bestandteil des eigenen Entwicklungsworkflows sein und stets nach Änderungen durchgeführt werden
Ich persönlich führe ansible-lint gern in einem eigenständigen Schritt aus. Es besteht jedoch auch die Möglichkeit, dies in den verwendeten Editor, die genutzte IDE oder Molecule zu integrieren und bei Änderungen automatisch laufen zu lassen.
Ich freue mich, wenn euch dieser Artikel gefallen hat.
Dies ist ein Erfahrungsbericht zur Migration meiner Ansible-Rolle „Nextcloud im Container“ in eine Ansible Collection. Er umfasst die Migration der bestehenden Rolle und die Ergänzung der neuen Collection um eine weitere Rolle, welche sich um die Aufgaben Backup und Restore kümmert.
Wer es ganz eilig hat, kann direkt zur Zusammenfassung springen. Allen anderen wünsche ich viel Spaß bei der Lektüre.
Für grundlegende Informationen zu Ansible Collections siehe:
Randnotiz: Dass ihr zu meiner ersten Ansible Collection hier im Blog nicht fündig werdet, liegt darin begründet, dass meine Arbeit daran eingeschlafen ist.
Wie ihr in Teil 5 der Artikel-Serie nachlesen könnt, war ich mit der Lösung für Backup und Restore nicht ganz zufrieden. Ich möchte dieses Thema erneut angehen und mithilfe einer Ansible-Rolle lösen.
Backup und Restore beschreiben jedoch andere Anwendungsfälle als die Bereitstellung, weswegen ich den dafür notwendigen Quelltext nicht mit in die bestehende Rolle pressen möchte. Da Backup und Restore für mich jedoch zum Betrieb dazugehören, möchte ich alle Ansible-Rollen, die ich zum Betrieb meines Nextcloud-Setups benötige, in einer Collection zusammenfassen.
Migration der bestehenden Rolle in eine Collection
Ich orientiere mich hierzu an der englischsprachigen Dokumentation „Migrating a role to a collection“. Da ich bereits einen Galaxy Namespace besitze, nutze ich diesen auch für die Erstellung der Collection. Der folgende Codeblock zeigt die verwendeten Befehle.
]$ ansible-galaxy collection init tronde.nextcloud
- Collection tronde.nextcloud was created successfully
]$ mkdir tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod && rsync -a ../roles/ansible_role_deploy_nextcloud_with_mariadb_pod/ tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/
]$ tree -L 3 tronde/nextcloud/
tronde/nextcloud/
├── docs
├── galaxy.yml
├── meta
│ └── runtime.yml
├── plugins
│ └── README.md
├── README.md
└── roles
└── deploy_nextcloud_with_mariadb_pod
├── defaults
├── meta
├── README.md
├── tasks
├── tests
└── vars
]$ rm -rf tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/.git
Im letzten Schritt entferne ich das .git-Verzeichnis, da ich die Collection als Ganzes in einem Repository verwalten möchte, statt alle Rollen einzeln zu versionieren und dann in die Collection einzufügen.
Anschließend aktualisiere ich die Dateien galaxy.yml und README.md. In der Rolle habe ich ein Playbook zum Testen verwendet, welches im Pfad deploy_nextcloud_with_mariadb_pod/tests/test.yml liegt. Um konform mit der Struktur einer Ansible Collection zu sein, erstelle ich im Wurzelverzeichnis meiner Collection das Verzeichnis playbooks und kopiere das Test-Playbook hier hinein:
]$ tree playbooks/
playbooks/
└── deploy_nextcloud_with_mariadb_pod.yml
An dieser Stelle halte ich zunächst inne und überlege mir, welche Tools ich noch benötige, um meine Collection entwickeln und testen zu können.
Ansible Development Tools
Ansible Development Tools (ADT) ist ein Projekt mit dem Ziel, einen Werkzeugkasten mit allen wichtigen Werkzeugen zur Entwicklung von Ansible Content zu bieten. Genau so etwas habe ich gesucht. Das probiere ich gleich aus.
Um mir mein System nicht zu verhunzen, installiere ich die ADT in ein Python Virtual Environment und lasse mir anzeigen, welche Werkzeuge ADT mitbringt:
Bei molecule-podman handelt es sich um einen Molecule-Treiber, welcher benötigt wird um Molecule-Tests in Podman-Containern ausführen zu können. Ich habe dieses Paket mitinstalliert, da ich mir vorstellen kann, dies in naher Zukunft zu nutzen.
ansible-lint
Ansible Lint ist das erste Werkzeug aus der ADT-Sammlung, welches ich verwende, um den Quelltext meiner Collection zu prüfen. Dazu wird das Kommando einfach im Wurzelverzeichnis der Collection ausgeführt. Anschließend können die gefundenen Fehler behoben werden.
Da es den Rahmen dieses Artikels sprengen würde, werde ich dem Thema einen eigenen Text widmen.
molecule
Ansible Molecule eignet sich zum Testen von Ansible-Rollen und Collections. Ich nutze meine Ansible Collection, um mich mit diesem Werkzeug vertraut zu machen.
Zwar gibt es auch hier erst eine Lernkurve, doch wird mir eine durchdachte Test-Konfiguration bei der weiteren Entwicklung sicher zugutekommen. Ich orientiere mich zu Beginn am Ansible Molecule Getting Started Guide.
Zu Beginn möchte ich meine in die Collection migrierte Rolle testen. Dazu bearbeite ich die Datei tronde/nextcloud/extensions/molecule/default/converge.yml. Sie enthält schließlich folgenden Inhalt:
Und mit folgendem Befehl teste ich, ob meine Nextcloud-Instanz erfolgreich deployt wird:
extensions]$ molecule converge
…
PLAY RECAP *********************************************************************
localhost : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
extensions]$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
48438d1bd884 quay.io/centos/centos:stream8 bash -c while tru... 7 minutes ago Up 7 minutes instance
104c525a6b50 localhost/podman-pause:5.1.1-1717459200 About a minute ago Up About a minute 127.0.0.1:40671->80/tcp e34ddf4d4203-infra
f27842b12d56 docker.io/library/mariadb:10.11.2 mariadbd About a minute ago Up About a minute 127.0.0.1:40671->80/tcp nc_mariadb
9ee391a57fbd docker.io/library/nextcloud:25-apache apache2-foregroun... 13 seconds ago Up 13 seconds 127.0.0.1:40671->80/tcp nextcloud
Das Ergebnis ist positiv und kann durch Aufruf von http://127.0.0.1:40671 im Webbrowser überprüft werden. Ein Login mit den Default-Werten aus tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml bestätigt das erfolgreiche Deployment.
Es handelt sich hierbei noch nicht um ein adäquates Test-Setup; doch für den Moment ist es ausreichend. Ich werde mich noch weiter einarbeiten müssen, um das Test-Setup verbessern zu können. Vermutlich wird auch dazu dann ein weiterer Artikel folgen.
Falls sich jemand wundert, es ist durchaus Absicht, dass die Nextcloud nur via 127.0.0.1 und per HTTP erreichbar ist. Ich betreibe diese hinter einem Reverse-Proxy. Details können in Nextcloud im Container — Teil 3: Mit Reverse-Proxy nachgelesen werden.
Backup und Restore für die Nextcloud
Um die Konfiguration und die in der Nextcloud gespeicherten Daten sichern und wiederherstellen zu können, werde ich eine Offline-Sicherung der verwendeten Podman Volumes durchführen. Der Ablauf für die Sicherung sieht wie folgt aus:
Den Pod ˋnc_podˋ inkl. aller darin enthaltenen Container stoppen
Alle zum Setup gehörenden Podman Volumes in Tarballs exportieren
Diese Tarballs vom managed Node auf den Control Node sichern
Den ˋnc_podˋ wieder starten
Die Wiederherstellung läuft sinngemäß andersherum ab:
Die Tarballs werden vom Control Node auf den Managed Node kopiert
Der Pod ˋnc_podˋ inkl. aller darin enthaltenen Container wird gestoppt
Die Podman Volumes aus Schritt 1 werden importiert
Der nc_pod wird wieder gestartet
Die zur Wiederherstellung auf den Managed Node kopierten Tarballs werden wieder entfernt
Um diese neue Rolle der Collection hinzuzufügen, navigiere ich in das Rollenverzeichnis tronde/nextcloud/roles/ und erstelle dort das Grundgerüst für die Rolle: ansible-galaxy role init backup_nextcloud
Die Struktur sieht bei mir wie folgt aus, wobei nicht benötigte Verzeichnisse noch nicht entfernt wurden:
Das dortige README.md enthält wie bei dedizierten Rollen die Dokumentation zu dieser Rolle. Um doppelte Texte zu vermeiden, verweise ich im Collection-README auf die jeweiligen README-Dateien in den einzelnen Rollen.
Getestet wird diese Rolle ebenfalls mit Molecule. Zu den Tests mit Molecule werde ich noch mehr schreiben, sobald ich dies etwas verfeinert habe.
Fallen mir noch weitere Anwendungsfälle ein, können diese nun einfach als weitere Rollen der Collection hinzugefügt werden.
Ansible-Variablen definieren
Jede Rolle in dieser Collection ist für sich alleine nutzbar. Somit definiert jede Rolle die Eingangs-Variablen in der defaults/main.yml der jeweiligen Rolle.
Bei der Entwicklung achte ich darauf, dass Variablen, die z.B. den Namen eines Podman Volumes enthalten, in allen Rollen gleich geschrieben werden. Damit ist es möglich, diese Variablen an anderer Stelle zu definieren und in den verschiedenen Rollen nutzbar zu machen. So können an individuelle Deployments angepasste Variablen in Playbooks, group_vars, host_vars, etc. definiert werden.
Weitere Rollen können der Collection hinzugefügt werden, indem man sie im Verzeichnis roles der Collection-Verzeichnisstruktur wie gewohnt mit ansible-galaxy role init <Rollenname> erstellt und mit Leben füllt. Sorgfalt ist und bleibt bei der Benennung von Variablen und deren Präzedenz geboten, um nicht wahnsinnig zu werden. Dies ist nicht wirklich schwierig, doch muss ich fast jedes Mal in der Dokumentation nachschlagen, um sicher zu sein.
Die Ansible Development Tools (ADT) sind eine praktische Sammlung von Werkzeugen zur Entwicklung von Rollen und Collections für Ansible. Für mich sind aktuell Ansible Lint und Ansible Molecule die wichtigsten Werkzeuge aus dieser Sammlung. Wobei gerade die Dokumentation von Molecule auf dem Weg zu meinem Ziel, nämlich meine Collections in verschiedenen rootless Podman Containern mit nested Podman und Ansible zu testen, leider viele Fragen offen lässt. Grundsätzlich lassen sich Testpläne damit realisieren und vereinfachen mein bisheriges Testsetup bestehend aus diversen Skripts und virtuellen Maschinen. Und sie bieten Stoff für weitere Einträge in diesem Blog.
Die weitere Entwicklung meiner Nextcloud Collection findet auf Codeberg statt. Ihr findet sie dort unter der URL: https://codeberg.org/Tronde/nextcloud
Heute möchte ich euch wissen lassen, welche Kombination es geworden ist.
Die Hardware
Ich habe mich für ein wiederaufbereitetes Lenovo T570 entschieden, welches für günstige 240 Euro im Onlinehandel verfügbar war. Da war dann auch noch für 30 Euro ein Schutzbrief drin, der Flüssigkeiten und Stürze abdeckt.
Mit dem Intel Core-i5 der 6. Generation, 8 GB RAM und einer 256 GB SSD bietet dieses Gerät mehr als ausreichend Leistung.
Das Gerät weist einige Gebrauchsspuren auf. Den Preis empfinde ich dennoch günstig, da Geräte dieser Klasse nicht unter 1.000 Euro Neupreis zu bekommen sind. Viel wichtiger jedoch ist, dass der Nutzer sich ebenfalls über das Gerät freut.
Linux-Distribution und Desktopumgebung
Wer die Wahl hat, hat die Qual. Um mir einen ersten Eindruck zu verschaffen, habe ich mir einen USB-Stick mit Ventoy und einer Auswahl an verschiedenen Linux-Distributionen erstellt. So konnte ich die verschiedenen Live-Systeme booten und prüfen, ob alles funktioniert und wie es sich in der Oberfläche navigieren lässt.
Schlussendlich habe ich mich für Debian Cinnamon entschieden. Dies machte nach dem ersten kurzen Test insgesamt den besten Eindruck. Firefox, Thunderbird, Bookmarks, Desktop-Verknüpfungen und Zoom-Client waren schnell eingerichtet und das Gerät bereit zur Übergabe.
Die Übergabe ist erfolgt
Mit der Übergabe gab es eine kurze Einweisung in das Gerät:
Wo schließt man das Netzteil an
Wo schaltet man das Gerät ein
Wie meldet man sich an
Wo findet man die Programme inkl. Tests aller wichtigen Dienste
Druck eines Anhangs aus Thunderbird
Wie fährt man das Gerät herunter
So reibungslos hat das bisher noch nie geklappt. Die Nutzungserfahrung ist positiv. Wir freuen uns.
Liebe Leser*innen, heute seid ihr gefragt. Denn ich möchte von euch wissen, welchen Laptop und welche Linux-Distribution, ihr für ältere, nicht EDV-affine Menschen und Windows-Umsteiger empfehlen könnt.
Hardware
Der Laptop soll über folgende Merkmale verfügen:
Größe: 15-17 Zoll
Webcam
Mikrofon und Lautsprecher
für Videokonferenzen
zum Schauen von Videos in sozialen Netzwerken
Linux- und Windows-Unterstützung
Die Unterstützung von Linux und Windows ist sehr wichtig. Sollte der Feldversuch mit Linux scheitern, möchte auf der gleichen Hardware ein aktuelles Windows-Betriebssystem installieren können.
Mir schwebt etwas in der Richtung der Lenovo IdeaPad oder ein ThinkPad der L-Serie vor, ich bin jedoch auf eure Empfehlungen gespannt.
Desktop-Umgebung
Ich suche nach einer Desktop-Umgebung, die folgende Merkmale bietet:
Ein Startmenü, welches sich in der unteren linken Ecke befindet
Erstellungen von Anwendungsstartern und Verknüpfungen auf der Desktopoberfläche
Dies sind Muss-Kriterien, die unbedingt erfüllt sein müssen. Ich möchte, dass die Desktopoberfläche diese Eigenschaften in der Standardkonfiguration erfüllt und ich diese nicht erst konfigurieren oder drölfzig Plug-ins installieren muss, um diesen Zustand zu erreichen.
Software
Die wichtigsten Anwendungen sind:
Thunderbird für E-Mail
Aktuelle Webbrowser (Chrome/Firefox) für den Rest
Facebook
YouTube
Zoom, MS Teams, Webex und wie sie alle heißen
Ein PDF-Anzeigeprogramm
Libre/Open Office zum Lesen von MS Office-Dokumenten
Linux-Distribution
Die Linux-Distribution muss die oben genannten Anforderungen an die Desktop-Umgebung und die Software erfüllen und dabei stabil allerdings nicht steinalt sein.
Ich möchte nicht vor jeder Videokonferenz mit den Audio-Einstellungen kämpfen müssen, um deutlich zu machen, wo meine Priorität liegt.
Dies ist mein Erfahrungsbericht der Chemnitzer Linux-Tage 2024. Es war mal wieder eine sehr schöne Veranstaltung.
Die Anreise
Im vergangenen Jahr hatte mich die Deutsche Bahn in Chemnitz sitzengelassen und ich musste mit einem kurzfristig angemieteten Leihwagen heimfahren.
Da die Deutsche Bahn und die Gewerkschaft Deutscher Lokomotivführer sich noch immer nicht auf einen neuen Tarifvertrag einigen können und ich mich nicht erneut über eine schlechte Verbindung ärgern wollte, bin ich dieses Jahr mit dem eigenen Pkw gefahren.
Am Freitag um 13:30 Uhr ging die Reise los. Mit viel Verkehr, Baustellen und Stau waren ich etwa 4,5 Stunden später im Hotel, wo ich direkt über Stoeps gestolpert bin.
Wir spazierten vom Residenz Hotel Chemnitz zum Veranstaltungsgebäude, um uns anzumelden und unsere Badges zu empfangen. Damit ersparten wir uns das Warten in der Schlange am Samstagmorgen.
Am Hörsaalgebäude traf ich schon erste vertraute Gesichter, wie z.B. Andreas, welcher fleißig beim Aufbau geholfen hat. Hier haben wir uns auch mit Michael von der Aspicon GmbH getroffen, mit dem ich für Sonntag einen Vortrag geplant hatte. Wir sind gemeinsam in die Stadt gegangen, um uns bei Speis und Trank kennenzulernen und den Abend zu verplaudern.
Der Samstag
Um 07:00 Uhr begann ich den Tag mit dem Frühstück. So war der erste Hunger bereits gestillt, als der Frühstücksraum sich zu füllen begann. Bekannte Gesichter und nerdige T-Shirts verrieten, dass es sich bei sehr vielen der Gäste um Besucher der Chemnitzer Linux-Tage handelte.
Die 20 Minuten zum Veranstaltungsort wurden auch diesmal wieder zu Fuß zurückgelegt. Und der erste Konferenztag konnte beginnen.
Um 10:00 Uhr war ich an der Reihe und durfte in einem rappelvollen Raum V6 meinen „::1“-Vortrag halten. An dieser Stelle euch allen nochmal vielen Dank für eure Teilnahme. Ich hoffe, ihr hattet so viel Spaß wie ich und konntet ein paar neue Eindrücke gewinnen.
Es hat mich gefreut, auch nach dem Vortrag noch einige Fragen beantworten zu können und über IPv6 zu fachsimpeln. Ganz nebenbei konnte ich auch noch die Frage eines Red Hat-Kunden beantworten. Darüber freute sich dieser sehr, bleibt ihm der Support eine zufriedenstellende Antwort doch seit langer Zeit schuldig. Es ist halt stets eine gute Erfahrung, einen TAM zu treffen.
Die Chemnitzer Linux-Tage gibt es übrigens schon seit 25 Jahren. Da eine Veranstaltung aufgrund der Pandemie ausfallen musste, findet die 25. Veranstaltung allerdings erst im nächsten Jahr am 22. und 23. März statt.
20-jähriges Jubiläum feiert in diesem Jahr Ubuntu, weshalb der Community-Stand dieses Jahr besonders schön geschmückt war und toddy mehrfach mit Luftschlangen gefesselt wurde.
Ich genieße die Zeit unter gleichgesinnten Nerds oder wie Stoeps es ausdrückte: „Endlich wieder unter normalen Menschen“. Mich hat es dieses Jahr sehr gefreut, auch viele jüngere Gesichter zu sehen. So sehr ich mich freue, auch die gleichen alten Nasen immer wiederzutreffen ist es doch schön, dass die Gemeinschaft nicht einfach alt wird, sondern auch junge Menschen mit Interesse, Motivation und Freude an Open Source nachwachsen.
Da die Hörsäle hier bei den Vorträgen meist aus allen Nähten platzen, hatte ich mich im Vorfeld als Sessionleitung für die drei Vorträge
gemeldet. So war mir ein guter Platz im Raum sicher. Ich danke den drei Referenten für ihre interessanten Vorträge.
Am Abend waren alle Aussteller, Helfer und Referenten zum gemütlichen Beisammensein in die Mensa eingeladen, welche schräg gegenüber dem Veranstaltungsgebäude liegt. Hier gab es ein reichhaltiges Angebot an warmem und kaltem Essen sowie eine Auswahl verschiedenster Getränke. Vielleicht ist es in der Zukunft möglich, die Getränke zu kühlen. Dann wird das Bier nicht so schnell warm und schmeckt länger gut.
Ich schätze es sehr, mich auf Konferenzen mit alten und neuen Bekannten auszutauschen, zu fachsimpeln und ganz allgemein angeregte Gespräche zu führen. Das musikalische Rahmenprogramm traf auch in diesem Jahr nicht meinen Geschmack. Ich würde mir etwas Hintergrundberieselung wünschen, um sich gut unterhalten zu können. Doch sind Geschmäcker verschieden und ich erkenne durchaus an, was das Organisations-Team der Chemnitzer Linux-Tage hier Jahr für Jahr auf die Beine stellt. Euch allen vielen Dank für euren unermüdlichen Einsatz.
Der Sonntag
Nach einem frühen Frühstück und Check-out ging es heute mit dem Auto zum Veranstaltungsgelände. Noch vor dem zweiten Kaffee wurden hier die Folien für den nächsten Vortrag nochmal geprüft. Um 10:00 Uhr war es wieder soweit. Diesmal durfte ich zusammen mit Michael den Vortrag „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ halten.
@Michael: „Es hat mir gut gefallen, mit dir einen Vortrag zu halten. Das können wir gerne wiederholen.“
Beim Mittagessen habe ich dann auch noch Christian getroffen. Für ihn waren es die ersten Chemnitzer Linux-Tage und auch ihm haben sie sehr gut gefallen.
Und wie immer war die Zeit auch viel zu schnell wieder vorbei. So habe ich Henning zwar kurz gesehen, doch für mehr als ein kurzes „Hi und Tschüss, bis zum nächsten Mal“ reichte es diesmal leider nicht.
Die Heimreise
Auch die schönsten Chemnitzer Linux-Tage gehen vorbei. Doch im Auto sitzend freute ich mich auch schon darauf, meine Familie wiederzusehen. Die Straße war frei und nach nur 3 Stunden 20 Minuten war ich wieder daheim. Zum Vergleich, mit der Bahn wäre ich je nach Verbindung erst nach 5,5-6,5 Stunden daheim gewesen, wenn alles nach Plan fährt.
So konnte ich mehr Zeit vor Ort verbringen und war rechtzeitig daheim, um noch etwas Zeit mit meinem Sohn zu verbringen, bevor dieser ins Bett ging.
Fazit
Es war schön. Ich hoffe, ihr seid alle wieder gut heimgekommen und behaltet auch diese Chemnitzer Linux-Tage in guter Erinnerung.
Mit einem Dualstack-Proxy Internet-Protokolle verbinden beschrieb eine Möglichkeit, um von Hosts, welche ausschließlich über IPv6-Adressen verfügen, auf Ziele zugreifen zu können, die ausschließlich über IPv4-Adressen verfügen. In diesem Beitrag betrachte ich die andere Richtung.
Zu diesem Beitrag motiviert hat mich der Kommentar von Matthias. Er schreibt, dass er für den bei einem Cloud-Provider gehosteten Jenkins Build Server IPv4 deaktivieren wollte, um Kosten zu sparen. Dies war jedoch nicht möglich, da Kollegen aus einem Co-Workingspace nur mit IPv4 angebunden sind und den Zugriff verloren hätten.
Doch wie kann man nun ein IPv6-Netzwerk für ausschließlich IPv4-fähige Clients erreichbar machen, ohne für jeden Host eine IPv4-Adresse zu buchen? Dazu möchte ich euch anhand eines einfachen Beispiels eine mögliche Lösung präsentieren.
Vorkenntnisse
Um diesem Text folgen zu können, ist ein grundsätzliches Verständnis von DNS, dessen Resource Records (RR) und des HTTP-Host-Header-Felds erforderlich. Die Kenntnis der verlinkten Wikipedia-Artikel sollte hierfür ausreichend sein.
Umgebung
Zu diesem Proof of Concept gehören:
Ein Dualstack-Reverse-Proxy-Server (HAProxy) mit den DNS-RR:
haproxy.example.com. IN A 203.0.113.1
haproxy.example.com IN AAAA 2001:DB8::1
Zwei HTTP-Backend-Server mit den DNS-RR:
www1.example.com IN AAAA 2001:DB8::2
www2.example.com IN AAAA 2001:DB8::3
Zwei DNS-RR:
www1.example.com IN A 203.0.113.1
www2.example.com IN A 203.0.113.1
Ein Client mit einer IPv4-Adresse
Ich habe mich für HAProxy als Reverse-Proxy-Server entschieden, da dieser in allen Linux- und BSD-Distributionen verfügbar sein sollte und mir die HAProxy Maps gefallen, welche ich hier ebenfalls vorstellen möchte.
Der Versuchsaufbau kann wie folgt skizziert werden:
Ein Dualstack-Reverse-Proxy-Server (B) verbindet IPv4-Clients mit IPv6-Backend-Servern
HAProxy-Konfiguration
Für dieses Minimal-Beispiel besteht die HAProxy-Konfiguration aus zwei Dateien, der HAProxy Map hosts.map und der Konfigurationsdatei poc.cfg.
Eine HAProxy Map besteht aus zwei Spalten. In der ersten Spalte stehen die FQDNs, welche vom HTTP-Client aufgerufen werden können. In der zweiten Spalte steht der Name des Backends aus der HAProxy-Konfiguration, welcher bestimmt, an welche Backend-Server eine eingehende Anfrage weitergeleitet wird. In obigem Beispiel werden Anfragen nach www1.example.com an das Backend serversa und Anfragen nach www2.example.com an das Backend serversb weitergeleitet.
Die HAProxy Maps lassen sich unabhängig von der HAProxy-Konfigurations-Datei pflegen und bereitstellen. Map-Dateien werden in ein Elastic Binary Tree-Format geladen, so dass ein Wert aus einer Map-Datei mit Millionen von Elementen ohne spürbare Leistungseinbußen nachgeschlagen werden kann.
Die HAProxy-Konfigurations-Datei poc.cfg für dieses Minimal-Beispiel ist ähnlich simpel:
~]$ cat /etc/haproxy/conf.d/poc.cfg
frontend fe_main
bind :80
use_backend %[req.hdr(host),lower,map(/etc/haproxy/conf.d/hosts.map)]
backend serversa
server server1 2001:DB8::1:80
backend serversb
server server1 2001:DB8::2:80
In der ersten Zeile wird ein Frontend mit Namen fe_main definiert. Zeile 2 bindet Port 80 für den entsprechenden Prozess und Zeile 3 bestimmt, welches Backend für eingehende HTTP-Anfragen zu nutzen ist. Dazu wird der HTTP-Host-Header ausgewertet, falls notwendig, in Kleinbuchstaben umgewandelt. Mithilfe der Datei hosts.map wird nun ermittelt, welches Backend zu verwenden ist.
Die weiteren Zeilen definieren zwei Backends bestehend aus jeweils einem Server, welcher auf Port 80 Anfragen entgegennimmt. In diesem Beispiel sind nur Server mit IPv6-Adressen eingetragen. IPv4-Adressen sind selbstverständlich auch zulässig und beide Versionen können in einem Backend auch gemischt auftreten.
Kann eine HTTP-Anfrage nicht über die hosts.map aufgelöst werden, läuft die Anfrage in diesem Beispiel in einen Fehler. Für diesen Fall kann ein Standard-Backend definiert werden. Siehe hierzu den englischsprachigen Artikel Introduction to HAProxy Maps von Chad Lavoie.
Der Kommunikationsablauf im Überblick und im Detail
Der Kommunikationsablauf im Überblick
Von einem IPv4-Client aus benutze ich curl, um die Seite www1.example.com abzurufen:
~]$ curl -4 -v http://www1.example.com
* processing: http://www1.example.com
* Trying 203.0.113.1:80...
* Connected to www1.example.com (203.0.113.1) port 80
> GET / HTTP/1.1
> Host: www1.example.com
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 200 OK
< server: nginx/1.20.1
< date: Sat, 06 Jan 2024 18:44:22 GMT
< content-type: text/html
< content-length: 5909
< last-modified: Mon, 09 Aug 2021 11:43:42 GMT
< etag: "611114ee-1715"
< accept-ranges: bytes
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>
Der FQDN www1.example.com wird mit der IPv4-Adresse 203.0.113.1 aufgelöst, welche dem Host haproxy.example.com gehört. Bei der Zeile Host: www1.example.com handelt es sich um den HTTP-Host-Header, welchen der HAProxy benötigt, um das richtige Backend auszuwählen.
Es ist zu sehen, dass wir eine Antwort von einem NGINX-HTTP-Server erhalten. Der HTML-Quelltext wurde gekürzt.
Damit ist es gelungen, von einem IPv4-Client eine Ressource abzurufen, die von einem IPv6-Server bereitgestellt wird.
Im Access-Log des Backend-Servers mit der IPv6-Adresse 2001:DB8::2 sieht man:
Die Anfrage erreicht den Backend-Server von der IPv6-Adresse des haproxy.example.com (2001:DB8::1). Die am Ende der Zeile zu sehende IPv4-Adresse (192.0.2.1) gehört dem IPv4-Client, von dem ich die Anfrage gesendet habe.
Gedanken zur Skalierung
In diesem Beispiel sind die Server www1.example.com und www2.example.com über ihre IPv6-Adressen direkt erreichbar. Nur die Client-Anfragen von IPv4-Clients laufen über den Reverse-Proxy. Wenn man es wünscht, kann man selbstverständlich sämtliche Anfragen (von IPv4- und IPv6-Clients) über den Reverse-Proxy laufen lassen.
In kleinen Umgebungen kann man einen Reverse-Proxy wie HAProxy zusammen mit Squid (vgl. Artikel Mit einem Dualstack-Proxy Internet-Protokolle verbinden) auf einem Host laufen lassen. Selbstverständlich kann man sie auch auf separate Hosts verteilen.
Hochverfügbarkeit lässt sich auch hier mit keepalived nachrüsten:
Die Internet-Protokolle IPv4 und IPv6 werden wohl noch eine ganze Zeit gemeinsam das Internet bestimmen und parallel existieren. Ich bin mir sogar sicher, dass ich das Ende von IPv4 nicht mehr miterleben werde. Dualstack-(Reverse)-Proxy-Server stellen eine solide und robuste Lösung dar, um beide Welten miteinander zu verbinden.
Sicher bleiben noch ausreichend Herausforderungen übrig. Ich denke da nur an Firewalls, Loadbalancer, NAT und Routing. Und es werden sich auch Fälle finden lassen, in denen Proxyserver nicht infrage kommen. Doch mit diesen Herausforderungen beschäftige ich mich dann in anderen Artikeln.
In drei Wochen beginnen die Chemnitzer Linux-Tage 2024 mit dem diesjährigen Motto „Zeichen setzen“. Am 16. und 17. März erwartet euch im Hörsaalgebäude an der Richenhainer Straße 90 ein vielfältiges Programm an Vorträgen und Workshops. Hier finden sich Vorträge für interessierte Neueinsteiger wie für alte Hasen.
So geht es am Samstag im Einsteigerforum beispielsweise um die Digitalisierung analoger Fotos, das Erstellen von Urlaubsvideos mit der Software OpenShot oder die Verschlüsselung von E-Mails. In der Rubrik „Schule“ gibt Arto Teräs einen Einblick in den Einsatz der Open-Source-Lösung Puavo an finnischen und deutschen Schulen. Zusätzlich stehen Vorträge aus den Bereichen Finanzen, Medien, Datensicherheit, KI oder Netzwerk auf dem Programm. Am Sonntag gibt das Organisationsteam der Chemnitzer Linux-Tage mit „make CLT“ Einblicke in die Planung und Strukturen der Veranstaltung selbst. In der Rubrik „Soft Skills” wird es um die Schätzung von Aufwänden oder notwendige Fähigkeiten von Software-Entwicklern gehen.
Eintrittskarten können online im Vorverkauf und an der Tageskasse erworben werden. Kinder bis 12 Jahren haben freien Eintritt.
Während viele Besucher bereits Stammgäste sind, werden auch neue Gesichter herzlich willkommen. Lasst euch gern von der hier herrschenden Atmosphäre voller Begeisterung für freie Software und Technik anstecken und begeistern.
Ich selbst freue mich, am Samstag um 10:00 Uhr in V6 den Vortrag mit dem obskuren Namen ::1 beisteuern zu dürfen. Update: Unverhofft kommt oft. Uns so freue ich mich am Sonntag um 10:00 Uhr in Raum V7 noch in einem zweiten Vortrag vertreten zu sein. Zusammen mit Michael Decker von der ASPICON GmbH erfahrt ihr, wie man „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ angehen kann.
Darüber hinaus beteilige ich mich als Sessionleiter für die folgenden drei Vorträge an der Veranstaltung:
So habe ich auf jeden Fall einen Platz im Raum sicher. ;-)
Wer ebenfalls helfen möchte, kann sich unter Mitmachen! informieren und melden.
Für mich ist dieses Jahr einiges im Programm dabei. Doch freue ich mich ebenso sehr auf ein Wiedersehen mit alten Bekannten aus der Gemeinschaft und darauf, neue Gesichter (Namen kann ich mir meist erst Jahre später merken) kennenzulernen.
Am 16. und 17. März 2024 werde ich euch auf den Chemnitzer Linux-Tagen um 10:00 Uhr in Raum V6 mit einem Vortrag über IPv6 unterhalten.
Dazu bin ich noch auf der Suche nach ein paar Beispielen aus dem echten Leben. Falls ihr mögt, teilt mir doch eure schönsten und schlimmsten Momente im Zusammenhang mit IPv6 mit und ich prüfe, ob ich sie in meinen Vortrag mit einbauen kann.
Wann und wie hat IPv6 euren Tag gerettet?
Wieso hat euch das Protokoll Alpträume beschehrt?
Was funktioniert wider Erwarten immer noch nicht mit IPv6?
Habt ihr lustige Geschichten, die ihr (anonym) mit der Welt teilen möchtet?
Ich freue mich über Einsendungen, Beiträge und Rückmeldungen:
Bitte schreibt dazu, ob ihr eine Namensnennung wünscht oder euer Beispiel anonym einfließen soll.
Um einen runden Vortrag zu erstellen, wird evtl. nicht jeder Beitrag einfließen können. Bitte habt Verständnis dafür und verzeiht, wenn ihr euch nicht im Vortrag wiederfindet. Ich werde eure Geschichten ggf. im Nachgang hier im Blog veröffentlichen.
Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.
Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?
Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:
Ablauf der Netzwerkkommunikation eines IPv6-Hosts mit einem IPv4-Host über einen Dualstack-Proxy-Server
Im Bild ist zu sehen:
Wie IPv6-Host A eine Verbindung über IPv6 zum Proxy-Server B aufbaut und diesem bspw. die gewünschte URL mitteilt
Der Proxy-Server B baut nun seinerseits eine IPv4-Verbindung zu IPv4-Host C auf, welcher die gewünschten Inhalte bereitstellt
IPv4-Host C sendet seine Antwort über IPv4 an den Proxy-Server
Der Proxy-Server sendet die gewünschten Inhalte anschließend via IPv6 an den IPv6-Host A zurück
Screencast zur Demonstration der Proxy-Nutzung
Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:
Mit dem host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbar
Mit dem ip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügt
Ohne Proxy ist die Demo-Seite nicht abrufbar
Erst durch Nutzung des Proxys kann die Seite abgerufen werden
Funktioniert das auch von IPv4 nach IPv6?
Ja. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.
Welcher Proxy ist empfehlenswert?
Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.
Sind damit alle Herausforderungen bewältigt?
Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.
Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.
Wie mache ich meine IPv6-Dienste für IPv4-User erreichbar, die keinen Proxy haben?
Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)
Das Jahr 2024 ist nun schon zwei Wochen alt. Dennoch möchte ich noch einen Blick zurückwerfen und mich erinnern, wie das Jahr 2023 für meinen Blog verlaufen ist.
In 2023 wurden auf My-IT-Brain insgesamt 45 Artikel veröffentlicht. Dies sind 16 mehr als in 2022 und 14 mehr als in 2021. Jeden Monat sind mindestens zwei Artikel veröffentlicht worden.
Die Themen waren dabei wieder bunt gemischt. Allein Artikel über die Red Hat Enterprise Linux (RHEL) System Roles zogen sich wie ein roter Faden durch den Blog. Welche Artikel haben denn euch am besten gefallen? Lasst es mich gerne in den Kommentaren wissen.
Ich hoffe, es war für jeden von euch etwas Interessantes mit dabei und ihr folgt diesem Blog auch in 2024. Ihr könnt mir auch gerne Anregungen in die Kommentare schreiben, welche Themen ihr hier gerne behandelt sehen wollt. Vielleicht greife ich ja einige davon auf.
Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.
In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.
Red Hat Satellite 6.14
Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:
You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.
Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.
Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:
You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.
Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:
Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.
subscription-manager cli command does not support IPv6 proxy
Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.
Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.
ansible-galaxy does not work on IPv6 only hosts
Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:
So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…
IPv6 support for cloning Git repositories #10539
Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:
$ host -t AAAA github.com
github.com has no AAAA record
Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“
Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.
Welche Erfahrungen habt ihr mit IPv6 gemacht?
Habt ihr es schon an den Nagel gehängt; oder bleibt ihr hartnäckig und gebt nicht auf?
Ich freue mich auf eure schönsten Fehlschläge und Erfolgsmomente.
In diesem Artikel stelle ich euch die RHEL System Rolenbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese:
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
Einem Ansible-Controller (RHEL 9) mit den Paketen
ansible-core
rhel-system-roles
Jeweils einem RHEL 8 und RHEL 9 Server mit Minimalinstallation und einem LUKS-Gerät (/dev/sdc in den Beispielen in diesem Text)
Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Anwendungsfall
In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.
Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.
Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.
Das Playbook
Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.
Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.
Der erste Task stellt sicher, dass das Netzwerkinterface aktiviert und mit einer IP-Adresse konfiguriert wird; dies ist notwendig, um den Tang-Server kontaktieren zu können, da in dem genutzten Netzwerk-Segment kein DHCP verfügbar ist; Solltet ihr ein Netzwerk-Segment nutzen, in dem DHCP zur Verfügung steht, kann der erste Task entfallen
Um das LUKS-Device für NBDE zu konfigurieren wird die LUKS-Passphrase benötigt, welche in der Variablen luks_password steckt
Ich empfehle die Variable luks_password mit ansible-vault vor neugierigen Blicken zu schützen
Durch password_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurde
Achtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.
Fazit
Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.
In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.
In diesem Artikel stelle ich euch die RHEL System Rolenbde_server vor, mit welcher sich Tang-Server für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese zuerst:
Im folgenden Text verwende ich die Begriffe NBDE-Server und Tang-Server synonym. Bitte lasst euch dadurch nicht verwirren.
Umgebung
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
Einem Ansible-Controller mit den Paketen (RHEL 9)
ansible-core
rhel-system-roles
Jeweils einem RHEL 8 und RHEL 9 Server mit Minimalinstallation
Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_server/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_server/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Ich möchte mit dieser Rolle Folgendes erreichen:
Installation von Tang auf den beiden Zielsystemen
Konfiguration von SELinux im Modus enforcing
Konfiguration der Host-Firewall
Das Playbook
Das Playbook ist recht übersichtlich. tang bezeichnet eine Gruppe aus meinem Ansible-Inventory, welche die Systeme enthält, die ich als NBDE-Server konfigurieren möchte.
---
- name: Manage nbde server with selinux and firewall
hosts: tang
vars:
nbde_server_manage_firewall: true
nbde_server_manage_selinux: true
roles:
- rhel-system-roles.nbde_server
Nach der Anwendung der Rolle lauscht der Tang-Service auf Port 80/tcp der Zielsysteme und ist aus dem Netzwerk erreichbar.
Probleme
Leider läuft es dieses Mal nicht ganz so rund wie üblich. Der Task [redhat.rhel_system_roles.selinux : Set an SELinux label on a port] schlägt auf dem RHEL 8 Host mit folgender Fehlermeldung fehl: „Failed to import the required Python library (libselinux-python)“
Diese Einführung gibt Antworten auf die folgenden Fragen:
Was ist ein Intrusion Detection System?
Was ist AIDE?
Wie installiert und konfiguriert man es?
Wie nutzt man AIDE?
In dieser Einführung verwendete Betriebssysteme:
Debian 12 (Bookworm)
Red Hat Enterprise Linux (RHEL) 9
Um dieser Einleitung folgen zu können, solltet ihr mit den Grundlagen der Linux-Systemadministration vertraut sein und zumindest mit den folgenden Begriffen etwas anfangen können:
Ein Intrusion Detection System (englischintrusion „Eindringen“, IDS) bzw. Angriffserkennungssystem ist ein System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind. Das IDS kann eine Firewall ergänzen oder auch direkt auf dem zu überwachenden Computersystem laufen und so die Sicherheit von Netzwerken und Computersystemen erhöhen. Erkannte Angriffe werden meistens in Log-Dateien gesammelt und Benutzern oder Administratoren mitgeteilt; hier grenzt sich der Begriff von Intrusion Prevention System (englischprevention „Verhindern“, IPS) ab, welches ein System beschreibt, das Angriffe automatisiert und aktiv verhindert.
Die Gruppe der Intrusion Detection Systems (IDS) untergliedert sich in:
Host-basierte IDS, welche auf einem Host installiert und betrieben werden
Netz-basierte IDS, welche auf Netzwerkkomponenten installiert werden und die Kommunikation auf Netz-Ebene überwachen
Hybride IDS, welche die Komponenten aus den vorstehend genannten Gruppen kombinieren
Beim AIDE handelt es sich um ein Host-basiertes IDS. Es ist unter der GPL-2.0 lizenziert.
Zweck und Nutzen des AIDE
Aus dem vorhergehenden Abschnitt ist bekannt, dass es sich bei AIDE um ein Host-basiertes System zur Angriffs- bzw. Einbruchserkennung für Linux-Systeme handelt. Es stellt ein kostengünstiges Werkzeug dar, mit dem die Integrität eines Systems überprüft werden kann.
Es soll dem Administrator helfen, zu erkennen, ob Dateien oder Verzeichnisse eines Systems hinsichtlich ihres Inhalts und bzw. oder ihrer Eigenschaften wie z.B. Berechtigungen, SELinx-Kontext, erweiterte Attribute, etc. verändert wurden.
Grundlegende Funktionsweise des AIDE
Die zu überwachenden Dateien und Verzeichnisse werden durch reguläre Ausdrücke in der Konfigurationsdatei bestimmt
Basierend auf diesen Regeln wird eine Datenbank erstellt
Nach dem Initialisieren der Datenbank kann AIDE dazuverwendet werden, die Integrität der Dateien und Verzeichnisse zu überprüfen
Die initial erstellte Datenbank dient dabei als Referenz
Bei folgenen Überprüfungen wird eine neue Datenbank erstellt und mit der Referenzdatenbank verglichen
Änderungen an überwachten Dateien und Verzeichnissen werden in der Logdatei /var/log/aide/aide.log protokolliert
Schwäche von AIDE und Host-basierter IDS im Allgemeinen
Programm, Konfigurationsdatei(en), Datenbank und Logdatei liegen lokal auf dem jeweiligen Host
Angreifer, welche lokale Dateien verändern können, können potenziell auch die zu AIDE gehörenden Dateien verändern
Dadurch muss die Integrität der zur Integritätsprüfung eingesetzten IDS bezweifelt werden
Um diese Schwäche zu minimieren, sind folgende Maßnahmen durch Administratoren in Erwägung zu ziehen:
Logdateien an einen zentralen Loghost senden
Die AIDE-Referenzdatenbank außerhalb des zu überwachenden Hosts speichern
Den Abgleich gegen die AIDE-Referenzdatenbank außerhalb des zu überwachenden Hosts durchführen
Wie diese Maßnahmen umgesetzt werden können, beschreibe ich in einem folgenden Beitrag.
Auswirkungen auf die eigene Arbeitsweise
Werden beispielsweise Konfigurationsdateien unterhalb von /etc auf Änderungen hin überwacht, wird auch jede beabsichtige Änderung protokolliert. Das Programm kann zwischen legitimen und unautorisierten Änderungen nicht unterscheiden.
Daher ist nach jeder legitimen Änderungen die Referenzdatenbank zu aktualisieren. Ich empfehle, dies als einen Schritt in den Konfiguration-Management-Workflow zu integrieren und diese Aufgabe einen Automaten wie Ansible, Chef, Puppet o.ä. erledigen zu lassen. Dies erscheint mir weniger fehleranfällig zu sein als bei einer manuellen Durchführung, wo dieser Schritt sicher gern einmal vergessen wird.
Die Installation von AIDE
AIDE ist in den Paketquellen der meisten Distributionen vorhanden und kann wie folgt installiert werden.
RHEL 9
$ sudo dnf in aide
[sudo] password for tronde:
Updating Subscription Management repositories.
Last metadata expiration check: 2:26:44 ago on Fri 08 Sep 2023 08:16:28 PM CEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
aide x86_64 0.16-100.el9 rhel-9-for-x86_64-appstream-rpms 154 k
Transaction Summary
================================================================================
Install 1 Package
Total download size: 154 k
Installed size: 354 k
Is this ok [y/N]:
Obiger Code-Block zeigt die Installationsanweisung für RHEL 9
Die Konfigurationdatei /etc/aide.conf besitzt im Auslieferungszustand bereits 303 Zeilen; ohne Kommentare und Leerzeilen sind es immerhin noch 161
Den Aufbau der Datei erklärt die Manpage aide.conf(5)
Um AIDE sinnvoll nutzen zu können, sollte sich jeder Administrator mit dem Inhalt von /etc/aide.conf vertraut machen; oder würdet ihr einem Firewall-Regelwerk vertrauen, das ihr nicht kennt?
$ sudo apt install aide
[sudo] password for jkastning:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
aide-common liblockfile-bin liblockfile1 libmhash2
Suggested packages:
figlet
The following NEW packages will be installed:
aide aide-common liblockfile-bin liblockfile1 libmhash2
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 372 kB of archives.
After this operation, 1064 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Obiger Code-Block zeigt die Installationsanweisung für Debian 12
Neben aide werden noch die Pakete aide-common, liblockfile-bin, liblockfile1 und `libmhash2` installiert
Neben der Konfigurationdatei /etc/aide/aide.conf installiert Debian auch das Verzeichnis /etc/aide/aide.conf.d, in welchem sich direkt nach der Installation schon etliche Konfigurationsdateien befinden:
$ ls -l /etc/aide/aide.conf.d/ | wc -l
212
Auch hier empfehle ich Administratoren, sich mit der Konfiguration zu beschäftigen und sich damit vertraut zu machen (siehe dazu auch aide.conf(5))
Während AIDE in RHEL über eine einzige Datei (/etc/aide.conf) konfiguriert wird, gibt es in Debian eine Konfigurationsdatei (/etc/aide/aide.conf) und die Verzeichnisse /etc/aide/aide.conf.d sowie /etc/aide/aide.settings.d, welche weitere Dateien zur Konfiguration und Einstellungen beinhalten.
Eine AIDE-Konfigurationsdatei aide.conf besteht aus drei verschiedenen Arten von Zeilen:
Optionen, welche die Konfigurationsparameter und Gruppen definieren; aufgebaut sind diese nach dem Muster Parameter = Wert bzw. Gruppenname = Wert
Regeln, welche bestimmen, welche Dateien und Verzeichnisse in die Datenbank aufzunehmen sind und welche Attribute überwacht werden sollen
Macros, mit denen sich Variablen definieren lassen; z.B. definierte @@define foo bar die Variable foo mit dem Wert bar
AIDE kann die folgenden Attribute bzw. Elemente von Dateien auf Änderungen hin überwachen:
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#acl: Access Control Lists
#selinux SELinux security context
#xattrs: Extended file attributes
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
Der folgende Code-Block zeigt die Definition der beiden Gruppen NORMAL und DIR (aus der /etc/aide.conf in RHEL 9), welche spezifizieren, welche Attribute überwacht werden sollen, wenn die jeweilige Gruppe in einer Regel verwendet wird.
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs
Welche Dateien und Verzeichnisse in die AIDE-Datenbank aufzunehmen bzw. auszuschließen sind durch reguläre Ausdrücke bestimmt. Der nächste Code-Block zeigt drei Beispiele, die anschließend erläutert werden:
/etc NORMAL
=/var/log/ DIR
=/home DIR
!/dev
Das Verzeichnis /etc und alle darunterliegenden Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit den Regeln aus der Gruppe NORMAL verknüpft
Nur das Verzeichnis /var/log/ und die direkt darunter befindlichen Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit der Gruppe DIR verknüpft; der Inhalt der Unterverzeichnisse wird nicht in die Datenbank aufgenommen
Ausschließlich /home wird aufgenommen; nicht jedoch der Inhalt davon
Das Verzeichnis /dev und alle darunterliegenden Dateien und Verzeichnisse werden nicht in die AIDE-Datenbank aufgenommen
Initialisierung der AIDE-Datenbank
Mit Sicherheit und Vertrauen ist das immer so eine Sache. Am besten ist es stets, wenn Vertrauen für Sicherheit nicht erforderlich ist. Daher rate ich an dieser Stelle nochmals ausdrücklich, die AIDE-Konfiguration zu überprüfen und ggf. den eigenen Bedürfnissen anzupassen… Nur um direkt gegen meinen eigenen Rat zu verstoßen.
Der Umfang an Regeln ist in beiden Systemen so groß, dass ich in dieser Einführung nicht alle einzeln erläutern kann. Ich vertraue für diese Einführung daher darauf, dass die Distributionen eine sinnvolle Konfiguration ausliefern.
Initialisiert wird die Datenbank je nach Distribution mit einem leicht abgewandelten Befehl.
Beispiel mit RHEL 9
$ sudo time aide --init
Start timestamp: 2023-09-18 20:50:06 +0200 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz
Number of entries: 54290
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-18 20:50:19 +0200 (run time: 0m 13s)
Die erzeugte Datenbank wird umbenannt, indem das new aus dem Dateinamen entfernt wird.
Die umbenannte Datei stellt die Referenzdatenbank dar, gegen die mit dem Befehl aide --check geprüft werden kann, ob es Änderungen im Dateisystem gab.
In diesem Artikel gebe ich mich damit zufrieden, dass die Datenbank auf dem zu überwachenden Host liegt und damit dem Risiko unterliegt, von einem Angreifer manipuliert zu werden (siehe zu den Schwächen oben). Ich gehe in einem Folgeartikel darauf ein.
Beispiel mit Debian 12
Unter Debian wird die AIDE-Datenbank mit dem Wrapper-Script aideinit (siehe aideinit(8)) initialisiert. Das README unter /usr/share/doc/aide-common/README.Debian.gz warnt bereits davor, dass Debian mit zu restriktiven Einstellungen daherkommt:
Configuring AIDE the Debian way ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AIDE’s Debian default configuration takes a very paranoid stance and is likely to report more changes than you will need to focus your attention on.
Das hat deutlich länger gedauert und endete mit einer deutlich kürzeren Ausgabe. Die erzeugte Datenbank ist jedoch wie bei RHEL im Verzeichnis /var/lib/aide/ zu finden.
:~# ls -l /var/lib/aide/
total 43536
-rw------- 1 root root 22286930 Sep 19 15:13 aide.db
-rw------- 1 _aide _aide 22286930 Sep 19 15:13 aide.db.new
:~# qm start 102
:~# file /var/lib/aide/aide.db.new
/var/lib/aide/aide.db.new: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
:~# file /var/lib/aide/aide.db
/var/lib/aide/aide.db: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
Warum die Erstellung so viel länger gedauert hat, weiß ich nicht. Ich habe keine Idee dazu. Auch Debian erzeugt eine gzip-komprimierte Datenbank, auch wenn hier keine Dateiendung darauf hinweist. Ich finde das etwas seltsam, behalte die Standardeinstellung für diese Einführung jedoch bei. Dafür muss die Datei nicht manuell umbenannt werden, da direkt eine Kopie erstellt wird, die als Referenzdatenbank genutzt werden kann.
Im Gegensatz zu RHEL wird unter Debian auch ein Timer namens dailyaidecheck.timer installiert, welcher täglich einen automatischen Check auf Veränderungen durchführt. Allerdings ist es für einen Angreifer ein Leichtes, diese Timer-Unit zu deaktivieren.
Auf Änderungen prüfen
Unter Debian und RHEL werden die in der Referenzdatenbank enthaltenen Elemente mit folgendem Befehl auf Änderungen überprüft:
:~# aide --check # unter RHEL
:~# aide --check --config /etc/aide/aide.conf # unter Debian
Ich habe meine Testsysteme ein paar Tage laufen lassen und einen AIDE-Integritätscheck durchgeführt. Hier das Ergebnis für ein RHEL 9 System:
$ sudo aide --check
Start timestamp: 2023-09-26 19:54:59 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-26 19:55:12 +0200 (run time: 0m 13s)
Die Integritätsprüfung in obigen Code-Block führt Änderungen an drei Dateien auf:
Das SELinux-Label einer Log-Datei hat sich geändert
Die Größe von zwei weiteren Log-Dateien hat sich geändert
Die Änderungen werden in einer Zusammenfassung und im Detail ausgegeben
Eine Erläuterung zur Ausgabe unter „Changed entries“ findet sich im Absatz summarize_changes in aide.conf(5).
Man erhält Informationen darüber, was sich geändert hat, nicht warum sich diese Änderungen ergeben haben
Abbruch meiner Tests unter Debian 12 (Bookworm)
Unter Debian hat die Integritätsprüfung über Stunden einen CPU-Kern blockiert. Der Prozess ist in einem futex Syscall hängen geblieben.
Ob es an meinem System liegt oder AIDE unter Debian generell ein Problem hat, kann ich nicht sagen. Ich bin der Sache nicht weiter nachgegangen.
Falls jemand von euch AIDE unter Debian einsetzt und dies liest, freue ich mich, wenn ihr eure Erfahrungen mit mir teilt.
Die Referenzdatenbank aktualisieren
Mit dem Befehl aide --update wird die Datenbank-Integrität geprüft und eine neue Datenbank /var/lib/aide/aide.db.new.gz erzeugt. Die bestehende Referenzdatenbank /var/lib/aide/aide.db.gz wird dabei nicht überschrieben und bleibt zunächst erhalten. Möchte man diese länger aufbewahren, kann man sie umbenennen und bspw. einen Zeitstempel anhängen. Anschließend erzeugt man mit mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz eine neue Referenzdatenbank.
Der folgende Code-Block zeigt die Ausgabe von aide --update unter RHEL 9.
~]# aide --update
Start timestamp: 2023-09-26 20:13:52 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
New AIDE database written to /var/lib/aide/aide.db.new.gz
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3 [0/100]
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
/var/lib/aide/aide.db.new.gz
MD5 : Dgoc1/L5F1UfXPAQRvMdTg==
SHA1 : 23RFwEBIh0kw/3TiiVAh39Fzx0Q=
RMD160 : 1szie2CW1dyLmaKFg01j48Fr+Us=
TIGER : TgdG3zNAOSZH2D9jkyvBves8PtjC0lCR
SHA256 : hjn9vxFxg4KoVwT3YvgU347EhvTCg5ey
lfktpr/OrcA=
SHA512 : x6E3YPa0eILD3nZqDt6N755KSmPRFOz8
lhKD9CimYScSpxyoVxJAVWiozR8KUwkt
Ao7mgy3BgtUA0MZuNMv43w==
End timestamp: 2023-09-26 20:14:03 +0200 (run time: 0m 11s)
~]# ls -l /var/lib/aide
total 6184
-rw-------. 1 root root 3163359 Sep 18 20:50 aide.db.gz
-rw-------. 1 root root 3163384 Sep 26 20:14 aide.db.new.gz
Ende
An dieser Stelle endet die Einführung in das Advanced Intrusion Detection Environment (AIDE). Kommt das Ende für euch abrupt? Ist es ein Ende mit Schrecken? Lasst es mich gern wissen.
In dieser Einführung habe ich beschrieben, was Intrusion-Detection-Systeme im Allgemeinen und AIDE im Speziellen sind. Ich bin auf deren Nutzen eingegangen und habe die Schwächen von AIDE als Host-basiertem IDS benannt. Installation, Konfiguration, Integritäts-Check und Aktualisierung der Datenbank wurden erklärt und mit Beispielen belegt.
Was ist nun von AIDE zu halten?
Nun, es ist besser als nichts. Man besitzt damit ein Werkzeug, mit dem sich Änderungen im Dateisystem erkennen lassen. Man muss sich jedoch der Schwächen Host-basierter IDS bewusst sein. Ein Angreifer mit lokalen root-Rechten kann dieses Werkzeug mit wenig Aufwand unschädlich machen bzw. die eigenen Änderungen verschleiern.
Sicher kann man einen Integritätscheck automatisiert alle 5 Minuten durchführen und für Änderungen eine E-Mail-Benachrichtigung einrichten. Doch wirkt dies etwas hemdsärmelig. Daher werde ich dieses Thema in einem späteren Artikel aufgreifen und zeigen, wie man AIDE in einen Automations- bzw. Konfigurations-Management-Prozess einbinden kann.
Im siebten Teil meiner losen Reihe über die RHEL System Roles stelle ich die Rolle rhc vor, mit welcher sich RHEL-Systeme (Version >= 8.6) in der Hybrid Cloud Console, Insights und dem RHSM registrieren lassen.
Möchte man ein oder mehrere RHEL-Systeme in der Hybrid Cloud Console registrieren, kann man dazu die RHEL System Role rhc verwenden.
Die Rolle
Durch die Installation des Pakets rhel-system-roles existiert die Rolle rhc bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.rhc/ und die Dokumentation in /usr/share/doc/rhel-system-roles/rhc/README.md.
Das Playbook
- name: Register systems
hosts: all
vars:
rhc_auth:
activation_keys:
keys: ["key-1", ...]
rhc_organization: "your-organization"
roles:
- rhel-system-roles.rhc
key-1 ist durch den eigenen Activation Key zu ersetzen
your-organization ist durch die eigene Org-ID zu ersetzen
Mit diesem Playbook werden die Hosts im RHSM und der Hybrid Cloud Console registriert
Die Systeme werden bei Insights registriert und laden regelmäßig aktuelle Daten hoch
Die Systeme werden für die Ausführung von Remediation Playbooks konfiguriert
Fazit
Mit dieser System Role ist es einfach möglich, eine große Anzahl Systeme in die Hybrid Cloud Console aufzunehmen. Dabei lässt sich konfigurieren, ob Funktionen wie Insights und Remediation Playbooks genutzt werden können.
Eine weitere tolle Rolle aus dem Paket rhel-system-roles, die sich einfach zur Anwendung bringen lässt.
Auf Mobiltelefonen, Tablets, Laptops, Netzwerkspeichern und in diversen Anwendungen in unserem Heimnetzwerk befinden sich Daten, welche wir schmerzlich vermissen würden, wenn sie dauerhaft verloren gingen.
Im Folgenden beschreibe ich, wie ich z.B. Fotos, Videos, Zeugnisse, Verträge, Urkunden, Versicherungspolicen, etc. vor Verlust schütze.
Sie sind unsere ständigen Begleiter, verfügen über große Speicher und beinhalten häufig jede Menge an Fotos und Videos. Diese werden mit DS-Apps auf eine Synology Diskstation im heimischen Netzwerk gesichert.
Für Threema benutze ich Threema Safe. Ein Datenbackup führe ich nicht durch. Der Inhalt der Nachrichten ist mir nicht so wichtig, als dass mich ein Verlust schmerzen würde.
E-Mails, Kalender und Kontakte werden zwischen Mailbox.org und diversen Geräten synchronisiert, jedoch nicht gesichert. Wenn jemand z.B. das Adressbuch löscht, müsste ich das Netzwerk vom PC trennen, um das Adressbuch ohne Netzwerkverbindung zu starten, um den letzten Stand von dort wiederherstellen zu können. Für mich ist das ausreichend, da ich bei einem GAU meine wichtigsten Kontakte auch ohne Adressbuch zu erreichen weiß und sich Kontaktinformationen von Handwerkern und sonstigen Unternehmen wieder recherchieren lassen.
Sollte ich Zugriff auf die App Aegis Authenticater verlieren, muss ich auf die Backup-Codes zurückgreifen, welche in einer KeePass-Datenbank lagern.
Falls ihr einfache Lösungen kennt, um sämtliche Apps samt deren Inhalte sichern und auf abweichenden Telefonen wiederherstellen zu können, freue ich mich, wenn ihr mir davon berichtet.
Network Attached Storage (NAS)
Meine Synology Diskstation ist:
Das Ziel für automatisierte Datensicherungen von Mobiltelefonen und Tablets
Datensicherungsziel für die Backups meiner virtuellen Server im LAN und in der Cloud
Primärer Speicherort für Fotos, Videos, eine Musiksammlung, Git-Repos
Primärspeicher für archivierte Daten, die ich vermutlich nie wieder benötige
Ausgewählte Daten werden wöchentlich mit Hyper Backup (Backup-Anwendung der Diskstation) auf eine angeschlossene USB-Festplatte gesichert. Darüber hinaus habe ich mir ein Offsite-Backup gebastelt, welches ich in diesem Artikel beschrieben habe.
Über Erfolg und Misserfolg der Sicherungen werde ich per E-Mail benachrichtigt.
Die größte Herausforderung für mich ist es, die Wiederherstellbarkeit der gesicherten Daten zu kontrollieren. Dies mache ich bisher sporadisch und manuell. Und vermutlich viel zu selten.
Darüber hinaus nutze ich Déjà Dup Backups für eine wöchentliche Datensicherung meines HOME-Verzeichnisses in die Nextcloud mit 180 Tagen Vorhaltezeit. Auch hier teste dich die Wiederherstellbarkeit sporadisch.
Das HOME-Verzeichnis meines Dienstlaptops wird täglich mit Déjà Dup in das Google Drive meines Arbeitgebers gesichert.
Urkunden, Verträge, Zeugnisse und weiterer Papierkram
Auch wir haben jede Menge totes Holz im Schrank stehen, dessen Wiederbeschaffung bei Verlust mit viel Zeit und Mühe verbunden ist.
Hier möchte ich die Wiederherstellung noch verbessern, indem ich auf meinem Laptop ein Ansible-Playbook ablege, welches die Paperless-NGX-Instanz auf meinem Laptop wiederherstellt. So teste ich die Wiederherstellbarkeit und habe immer eine relativ aktuelle Kopie auf der verschlüsselten Festplatte meines Laptops bei mir.
Auf einem virtuellen Server in der Cloud möchte ich diese Daten aktuell nicht so gerne hosten. Dazu muss ich mir zuvor in Ruhe Gedanken über mögliche Risiken für die Integrität und Vertraulichkeit der Daten machen.
Meine produktive Paperless-NGX-Instanz steht mit dem Papier im gleichen Haus. Das Backup beinhaltet alle PDF-Dateien und liegt verschlüsselt in der Cloud. Da die Dateinamen halbwegs sinnvoll benannt sind, scheint im Falle eines GAU die Suche im Heuhaufen nicht hoffnungslos.
Blog und Nextcloud
Für beide Dienste, welche auf einem virtuellen Server bei Contabo laufen, wird zur Datensicherung wöchentlich ein Datenbank-Dump und ein Archiv der Verzeichnisstruktur mit Ordnern und Dateien erstellt. Dieses Backup wird lokal auf dem Server abgelegt und für 30 Tage vorgehalten. Ich nutze dafür selbstgeschriebene Bash-Skripte, welche durch Cron ausgeführt werden.
Auf meinem NAS läuft ein Skript, welches die Backups vom Server auf das NAS synchronisiert.
Über Erfolg und Misserfolg der einzelnen Jobs werde ich per E-Mail benachrichtigt.
Die Wiederherstellbarkeit teste ich sporadisch und sollte dies mutmaßlich häufiger tun. Ein Automat dafür befindet sich aktuell in Arbeit. Den aktuellen Stand kann man in folgenden Artikeln nachlesen:
Ruhende Daten werden verschlüsselt, bevor sie in die Cloud hochgeladen werden. Das Restrisiko, dass der fremde Betreiber prinzipiell die Kontrolle über meinen virtuellen Server übernehmen kann, bleibt.
Betreibe ich Server oder Dienst nicht im eigenen Heimnetzwerk, nutze ich für den Betrieb deutsche Anbieter mit Standorten in Deutschland. Zu diesen habe ich einfach das größte Vertrauen, dass sie sich an geltende Gesetze halten, die Hoffnung, dass sie den Datenschutz ernst nehmen und meine Daten dort gut aufbewahrt sind.
Wie sichert ihr eure Daten außer Haus? Welche Dienste verwendet ihr dazu? Ich freue mich, wenn ihr eure Erfahrungen in den Kommentaren teilt.
Zusammenfassung
Ich habe mir zumindest mal Gedanken gemacht, welche Daten so wichtig sind, dass ich sie vor Verlust schützen möchte. Zum Schutz vor Verlust kommen verschiedene Verfahren zum Einsatz, die auf der Schaffung von Redundanz durch Synchronisierung oder der Datensicherung mit Versionierung beruhen.
Die Wiederherstellbarkeit wird zumindest sporadisch getestet. Dieser Punkt ist sicherlich ausbaufähig.
Wer die einzelnen Abschnitte gelesen hat, stellt jedoch auch fest, dass es schnell ein wenig unübersichtlich wird. Zumindest hilft dieser Artikel etwas, den Überblick zu behalten.
Für die Zukunft wünsche ich mir eine dedizierte Backup-Senke im Keller, in der sich ausschließlich Backups befinden und eine Offsite-Senke, auf welche die Daten der Backup-Senke gesichert werden. Bis ich da hinkomme, wird sicherlich noch etwas Zeit vergehen.
In diesem Tutorial zeige ich euch, wie ihr eine automatische Aktualisierung für Container in rootless-Podman-Umgebungen konfigurieren und diese Container als systemd-Services verwalten könnt.
Das Tutorial gliedert sich in folgende Abschnitte:
Wer sich nicht für die möglichen Anwendungsfälle interessiert und lieber gleich starten möchte, kann den ersten Abschnitt überspringen. Die übrigen Abschnitte sollten in der angegebenen Reihenfolge gelesen werden.
Anwendungsfälle
Container werden auf einem Single-Container-Host ausgeführt und nicht in K8s-Umgebungen
Man vertraut dem Anbieter, dass dieser stabile und nutzbare Container-Images bereitstellt
Es soll regelmäßig geprüft werden, ob aktualisierte Container-Images vorhanden sind
Sind aktuellere Images vorhanden, sollen laufende Container entfernt und unter Verwendung der aktuellen Images neu erstellt werden
Voraussetzungen
Um diesem Tutorial folgen zu können, benötigt ihr einen Host mit einer rootless-Podman-Umgebung. Podman muss dabei in der Version >= 3.3 verfügbar sein. In der folgenden Liste findet ihr einige Links, die euch helfen, eine solche Umgebung aufzusetzen.
Das Betriebssystem spielt eine untergeordnete Rolle, da wir durch die Verwendung von Containern die Anwendung vom Betriebssystem entkoppeln. Alle zur Ausführung der Anwendung notwendigen Abhängigkeiten sind im Container-Image enthalten.
Uptime Kuma ist eine schlanke und schnelle Monitoring-Anwendung, welche unter anderem als Container-Image bereitgestellt wird. Ich habe die Anwendung als Beispiel für dieses Tutorial ausgewählt, da ich die Anwendung selbst nutzen möchte und so Synergieeffekte nutzen kann.
Wer ein anderes Container-Image nutzen möchte, muss in den folgenden Beispielen louislam/uptime-kuma:latest durch den fully qualified container name des zu nutzenden Images ersetzen.
Für die Konfiguration werden die auf dem System verfügbaren Podman-Manpages benutzt.
Konfiguration des Systemd-Service mit Auto-Update-Funktion
Bei den folgenden Schritten habe ich mich am Beispiel aus podman-auto-update(1) orientiert. Ich zeige zuerst den jeweils auszuführenden Befehl in einem Code-Block, gefolgt von einer Erläuterung der genutzten Optionen.
Podman-Volume erzeugen
$ podman volume create uptime-kuma
uptime-kuma
Um Daten persistent speichern zu können, müssen diese außerhalb des Containers abgelegt werden. Der dargestellte Befehl erzeugt ein Podman-Volume mit dem Namen „uptime-kuma“.
Mit dem folgenden Befehl lassen sich detaillierte Informationen zum gerade erstellten Volume anzeigen:
podman run ist das Kommando, mit dem ein neuer Container gestartet wird
Die Option --label "io.containers.autoupdate=registry" gibt an, dass Podman die Remote-Registry prüft, ob dort ein aktualisiertes Image vorhanden ist; dieses Label ist Voraussetzung, um die Auto-Update-Funktion nutzen zu können
Mit der Option -d wird der Container im Hintergrund gestartet und die Container-ID auf STDOUT ausgegeben
Durch -p 3001:3001 wird der Host-Port 3001 mit dem Port der Anwendung (ebenfalls 3001) im Container verbunden
Die Option -v uptime-kuma:/app/data:Z hängt das im vorhergehenden Schritt erstellte Podman-Volume in das Verzeichnis /app/data innerhalb des Containers ein; :Z sorgt dafür, dass der SELinux-Kontext korrekt gesetzt wird
--name=uptime-kuma spezifiziert den Namen des Containers; dieser ist etwas leichter zu merken als die Container-ID
Der Befehl endet mit dem fully qualified container namedocker.io/louslam/uptime-kuma:latest
Die letzte Zeile des Code-Blocks enthält die Container-ID
Manpages zum Nachschlagen:
podman-run(1)
podman-auto-update(1)
Systemd-Service-Unit mit podman-generate-systemd erstellen
Der Befehl gibt den Inhalt der generierten Service-Unit auf STDOUT aus
Die Option --name verwendet den Namen des Containers anstelle der Container-ID im Dateinamen der Service-Unit (hier: container-uptime-kuma.service)
Wichtig ist die Option --new, um Container von aktualisierten Images erstellen zu können; ohne diese Option können Systemd-Units Container nur unter Verwendung des ursprünglichen Images starten und stoppen und ein Auto-Update ist nicht möglich
Der folgende Code-Block fügt dem Befehl die Option --files hinzu, um eine Service-Unit-Datei zu erstellen
Der erste Befehl verschiebt die Service-Unit in einen Pfad, wo systemd sie findet und einlesen kann
Die Option -Z stellt sicher, dass die Datei den SELinux-Kontext des Zielverzeichnisses zugewiesen bekommt, andernfalls kann systemd die Datei ggf. nicht verarbeiten
Durch den zweiten Befehl wird die Unit-Datei systemd bekannt gemacht
An dieser Stelle ist der neue Systemd-Service geladen, jedoch inaktiv
Durch die Option --dry-run wird sichergestellt, dass nur auf die Verfügbarkeit neuer Images geprüft wird, es werden jedoch keine Pull-Operationen ausgeführt und keine Container neu erstellt
Es wird eine Liste von Container-Images ausgegeben, die mit dem Label io.containers.autoupdate=registry gestartet wurden
Die erste Spalte enthält den Image-Namen
Die zweite Splate zeigt an, ob ein Update verfügbar ist; in diesem Fall ist kein Update verfügbar (false)
Container (automatisch) aktualisieren
Wurde die Konfiguration erfolgreich abgeschlossen, können die entsprechenden Container durch folgenden Befehl manuell aktualisiert werden:
Leider ist aktuell kein Update verfügbar, weshalb es hier nichts zu tun gibt und der Status von Updated gleich false ist.
Podman bringt bei der Installation die beiden systemd unitspodman-auto-update.timer und podman-auto-update.service mit, welche zumindest unter RHEL 9 manuell aktiviert werden müssen:
$ systemctl --user enable podman-auto-update.{service,timer}
Created symlink /home/tronde/.config/systemd/user/default.target.wants/podman-auto-update.service → /usr/lib/systemd/user/podman-auto-update.service.
Created symlink /home/tronde/.config/systemd/user/timers.target.wants/podman-auto-update.timer → /usr/lib/systemd/user/podman-auto-update.timer.
$ systemctl --user start podman-auto-update.timer
$ systemctl --user status podman-auto-update.{service,timer}
○ podman-auto-update.service - Podman auto-update service
Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
Active: inactive (dead)
TriggeredBy: ● podman-auto-update.timer
Docs: man:podman-auto-update(1)
● podman-auto-update.timer - Podman auto-update timer
Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.timer; enabled; preset: disabled)
Active: active (waiting) since Sat 2023-09-02 20:56:09 CEST; 1s ago
Until: Sat 2023-09-02 20:56:09 CEST; 1s ago
Trigger: Sun 2023-09-03 00:12:22 CEST; 3h 16min left
Triggers: ● podman-auto-update.service
Der Timer startet jeden Tag um Mitternacht den Auto-Update-Service
Der Service prüft, ob aktualisierte Container-Images verfügbar sind und führt ggf. ein Update der Container durch
Schlägt ein Start nach Aktualisierung des Container-Images fehl, wird der Dienst automatisch von der vorherigen Image-Version gestartet; siehe --rollback in podman-auto-update(1)
Der folgende Code-Block zeigt den Status, nachdem ein Update durchgeführt wurde
Anmelden
