In diesem Text dokumentiere ich, wie ein Tang-Server auf Debian installiert werden kann und wie man den Zugriff auf diesen auf eine bestimmte IP-Adresse einschränkt.
Installiert wird der Tang-Server mit folgendem Befehl:
sudo apt install tang
Standardmäßig lauscht der Tang-Server auf Port 80. Da dieser Port auf meinem Server bereits belegt ist, erstelle ich mit dem Befehl sudo systemctl edit tangd.socket eine Override-Datei mit folgendem Inhalt:
Ich möchte den Zugriff auf den Tang-Server auf eine IP-Adresse beschränken, nämlich auf die IP-Adresse des einen Clevis-Clients, der diesen Server verwenden wird. Dazu führe ich die folgenden Schritte durch.
:~# iptables -A INPUT -p tcp -s 203.0.113.1 --dport 7500 -j ACCEPT
:~# iptables -A INPUT -p tcp --dport 7500 -j DROP
:~# mkdir /etc/iptables
:~# iptables-save >/etc/iptables/rules.v4
Damit die in der Datei /etc/iptables/rules.v4 gespeicherten Regeln nach einem Neustart wieder geladen werden, erstelle ich ein Systemd-Service:
Um zu überprüfen, ob der Tang-Server wie gewünscht arbeitet, setze ich auf meinem Clevis-Client den folgenden Befehl ab. Dabei muss nach der Ver- und Entschlüsselung der gleiche Text ‚test‘ ausgegeben werden.
~]$ echo test | clevis encrypt tang '{"url":"tang1.example.com:7500"}' -y | clevis decrypt
test
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.
Mit NGINX Rewrite-Regeln alte WordPress-Permalinks wie /YYYY/MM/dd/postname auf die neue Struktur umleiten – ohne Plugins und SEO-freundlich. Archive bleiben intakt!
Mit einer cleveren Kombination aus Syncthing und WebDAV auf einem Raspberry Pi synchronisieren wir unsere KeePass-Datenbanken plattformübergreifend und zuverlässig – ohne Abhängigkeit von klassischen Cloud-Diensten.
Mit NGINX Rewrite-Regeln alte WordPress-Permalinks wie /YYYY/MM/dd/postname auf die neue Struktur umleiten – ohne Plugins und SEO-freundlich. Archive bleiben intakt!
Mit einer cleveren Kombination aus Syncthing und WebDAV auf einem Raspberry Pi synchronisieren wir unsere KeePass-Datenbanken plattformübergreifend und zuverlässig – ohne Abhängigkeit von klassischen Cloud-Diensten.
Wer des Öfteren Proxmox aufsetzen muss, dem kommt dieses kleine Script vermutlich gerade recht. Es installiert Proxmox und hilft bei Bedarf bei der Integration in einen Cluster.
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.
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
Der Hypervisor Unraid ist über ein Web-Interface leicht zu bedienen und bietet insgesamt viele Möglichkeiten. Der Linux-Anwender wird bei der Installation aber alleingelassen.
This is the translated version of an article written in German originally. I translated it as a non-German speaking person has shown interest in the topic.
Disclaimer: This tutorial comes without warranty and support. Use at your own risk.
In this tutorial, I would like to show a minimal example on how selected VMDK files of specific VMs can be resized with using the PowerCLI.
This is useful, for example, when so many VMs are affected that the time and effort required to manually enlarge them via the vSphere (web) client seems too great.
Only the resizing of the VMDK file is considered here. The subsequent resizing of the partition and file system within the guest operating system, which is also necessary, is not part of this tutorial.
Goal
For a minimal example, from a group of VMs the second and third hard disk of VM-Test-5 and VM-Test-6 are to be enlarged. The respective second hard disk is to be enlarged from 250 GB to 500 GB and the respective third hard disk is to be enlarged from 400 GB to 800 GB.
Requirements
A working installation of the VMware PowerCLI and the ability to access the vCenter Server is a prerequisite to follow this tutorial.
Here we go
The following code block shows how the necessary information about the VMs is read out to be processed.
PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"}
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-5 PoweredOn 4 24.000
VM-Test-7 PoweredOn 4 16.000
VM-Test-6 PoweredOn 4 24.000
PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-5 PoweredOn 4 24.000
VM-Test-6 PoweredOn 4 24.000
PowerCLI C:\Scripts> $VM = Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize
Parent Name CapacityGB
------ ---- ----------
VM-Test-5 Hard disk 1 40
VM-Test-5 Hard disk 2 250
VM-Test-5 Hard disk 3 400
VM-Test-5 Hard disk 4 80
VM-Test-6 Hard disk 1 40
VM-Test-6 Hard disk 2 250
VM-Test-6 Hard disk 3 400
VM-Test-6 Hard disk 4 80
From the above output you can see that we want to enlarge the VMDK files which are called „Hard disk 2“ and „Hard disk 3“ respectively.
In the code block that follows, I first define a few variables, then double check that I am selecting the correct VMDK files for the operation, and then I resize them.
PowerCLI C:\Scripts> $HardDisk = 2
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 500
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}
CapacityGB Persistence Filename
---------- ----------- --------
250.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
250.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false
CapacityGB Persistence Filename
---------- ----------- --------
500.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
500.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize
Parent Name CapacityGB
------ ---- ----------
VM-Test-5 Hard disk 1 40
VM-Test-5 Hard disk 2 500
VM-Test-5 Hard disk 3 400
VM-Test-5 Hard disk 4 80
VM-Test-6 Hard disk 1 40
VM-Test-6 Hard disk 2 500
VM-Test-6 Hard disk 3 400
VM-Test-6 Hard disk 4 80
PowerCLI C:\Scripts> $HardDisk = 3
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 800
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}
CapacityGB Persistence Filename
---------- ----------- --------
400.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
400.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false
CapacityGB Persistence Filename
---------- ----------- --------
800.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
800.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk
PowerCLI C:\Scripts>
If the above code block is not self-explanatory, feel free to post your questions about it in the comments. I’ll try to complete the tutorial in a timely manner.
In diesem Tutorial beschreibe ich, wie mithilfe der PowerCLI die RAM-Größe einer virtuellen Maschine (VM) bearbeitet werden kann. Diese Methode lässt sich auch anwenden, um mehrere VMs in einem Arbeitsablauf zu bearbeiten. Dies bietet sich z.B. immer dann an, wenn so viele VMs betroffen sind, dass der Aufwand der manuellen Bearbeitung im vSphere-Client zu groß erscheint.
Es soll die Größe des Arbeitsspeichers von zunächst einer und anschließend mehrerer VMs bearbeitet werden. Dabei wird gezeigt, wie RAM im laufenden Betrieb erhöht und bei ausgeschalteten VMs reduziert werden kann.
Voraussetzungen
Eine funktionsfähige Installation der VMware PowerCLI und die Möglichkeit den vCenter Server über diese ansprechen zu können, ist Voraussetzung, um diesem Tutorial zu folgen.
Um den RAM einer VM im laufenden Zustand erhöhen zu können, muss die Option Memory Hot Plug der betreffenden VM aktiviert sein.
Anmeldung am vCenter
Zu Beginn verbindet man sich zu der vCenter-Instanz, deren VMs man bearbeiten möchte. Das Kommando hat folgenden Aufbau:
Seit vielen Jahren bin ich zufriedener Linux Mint Nutzer. Immer wieder stoße ich auf Software die als Snap-Paket angeboten wird und die dich gerne nutzen möchte. Das ist unter Mint allerdings standardmäßig nicht möglich, denn die Installation dieser Pakete wird von Mint aktiv verhindert. Das Mint entschieden hat, dass sie Snaps doof finden, nicht unterstützen [...]
Andreas hat einen Nextcloud-Server auf Debian-Basis installiert und dabei seine Vorgehensweise dokumentiert. Diese basiert zum großen Teil, aber nicht ausschließlich auf meinem Homeserver-Tutorial zu Ubuntu 18.04 [Homeserver/NAS mit Ubuntu 18.04: Teil 1, Einleitung, Hardware und Kosten]. Jedoch mit einigen Abweichungen, da sich Debian und Ubuntu doch in einigen Details unterscheiden. Die Dokumentation seiner Vorgehensweise hat [...]
Mittlerweile ist Ubuntu 20.04 erschienen. Hierbei handelt es sich wieder um eine LTS-Version (long term support), die 5 Jahre mit Updates versorgt wird. Also bis April 2025. Damit wird Ubuntu 18.04 abgelöst, auf welchem die bisherige Homeserver-Anleitung basiert. Ubuntu 18.04 war ebenfalls eine LTS-Version und wird noch bis April 2023 mit Sicherheitsupdates versorgt. Wer also [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Zuerst wird das Betriebssystem Ubuntu Server 20.04 (Focal Fossa) installiert. Mit dieser Version wurde ein neues Installationsprogramm eingeführt, sodass sich die Installation von den Vorgängerversionen unterscheidet. Das Kapitel zur Partitionierung der Festplatten unterteilt sich in zwei Teile. Je nachdem ob man ein System mit internen [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS In den beiden vorherigen Teilen wurde die Hardware eingerichtet und das Betriebssystem installiert. Bevor es nun an das Installieren und Einrichten der eigentlichen Dienste geht, sollten noch ein paar Grundeinstellungen vorgenommen werden. Außerdem gilt es ein paar grundlegende Dinge bei der Administration zu beachten. Gleichbleibende [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Das Betriebssystem wurde in den letzten Teilen installiert und die wichtigsten Grundkonfigurationen vorgenommen. Nun können die ersten Dienste auf dem Homeserver installiert werden. In diesem Teil werden die Ordnerfreigaben für das lokale Heimnetz erstellt. Die Software, die hierfür verwendet wird, ist SAMBA-Server. Damit können über [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Nextcloud hat sich mittlerweile zum Quasi-Standard für selbstgehostete Cloudanwendungen entwickelt. Nextcloud kann uneingeschränkt kostenlos genutzt werden. In Nextcloud können Kalender und Kontakte gespeichert und mit dem Smartphone synchronisiert werden. So kann man Dienste wie Google Calender komplett ersetzen. Außerdem gibt es einen Deskop-Client, mit welchem [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Zur Organisation und Wiedergabe von Musik und Videos wird Plex verwendet. Plex besteht aus zwei Komponenten, dem Server und den Clients. Die Serverkomponente wird auf dem Homeserver installiert. Hier werden alle Audio- und Videodateien zentral verwaltet und der Mediaserver organisiert. Die Clients sind die Wiedergabegeräte. [...]
Dieser Artikel ist Teil der Reihe selbstgebauter Ubuntu 20.04 Homeserver/NAS Im letzten Kapitel geht es um die Datensicherung. Der Homeserver dient als zentrale Ablage für eine Vielzahl wichtiger Dateien. Eventuell sogar von mehreren Personen. Ein Verlust der Daten wäre daher verheerend. Das RAID-System schützt zwar vor dem Verlust der Daten durch einen Hardwaredefekt an einer [...]
Auf dieser und anderen Webseite von mir setze ich manchmal sogenannte Partnerlinks ein. Dabei wird ein im Beitrag erwähntes Produkt direkt mit einem Onlineshop verlinkt. Kauft jemand über diesen Link ein Produkt, erhält der Webseitenbetreiber eine Provision.
Es handelt sich dabei um eine Möglichkeit mit der Webseite Einnahmen zu erzielen, ohne die Seite mit Werbung zu überfrachten, oder sich für sogenannte Sonsored Posts zu verkaufen.
Üblicherweise wird beim Aufruf des Shops über den Partnerlink ein Cookie gesetzt. Dadurch können auch Einkäufe vergütet werden, die erst später getätigt werden. Dementsprechend gibt es schwarze Schafe, die versuchen um jeden Preis diesen Cookie zu setzen.
Dies passiert beispielsweise indem die Seite des Shops in einem Pop-Up oder in einem unsichtbaren Iframe geladen wird. Oder es wird versucht Besucherinnen und Besucher mit mehr oder weniger zweifelhaften Methoden dazu zu bringen, selbst auf den Link zu klicken. Beispielsweise indem man verschleiert dass es sich um einen Partnerlink handelt.
Um die eigene Glaubwürdigkeit nicht zu gefährden und auch um rechtlichen Problemen mit ungekennzeichneter Werbung aus dem Weg zu gehen, ist man also gut beraten, Partnerlinks auch als solche ersichtlich zu machen.
Bisher habe ich Partnerlinks immer manuell mit einem Sternchen markiert. Die Bedeutung des Sternchens habe ich in der Seitenleiste oder im Footer erläutert. Mittlerweile bin ich eher dazu übergegangen Partnerlinks mit dem Icon eines Einkaufswagens zu versehen.
Ich bin mir noch nicht sicher was die bessere Version ist. Ich denke der Einkaufswagen ist unmissverständlich. Das Sternchen funktioniert hingegen immer, auch wenn keine Bilder geladen werden.
Mit CSS Amazon und andere Partnerlinks automatisch mit einem Sternchen oder Icon kennzeichnen
Um mir die Arbeit zu erleichtern und um ggf. an einer zentralen Stelle die Art der Kennzeichnung ändern zu können, war ich auf der Suche nach einer Möglichkeit die Kennzeichnung zu automatisieren. Wie sich herausstellt, lässt sich dies mit einer Zeile CSS lösen.
Standardmäßig werden USB-Sticks und andere externe Datenträger unter Linux Mint automatisch eingehängt und in einem neuen Fenster im Dateimanager geöffnet.
Da ich gerade wieder häufig mit dem Raspberry Pi herumspiele, kommt es vor, dass ich häufig dessen SD-Karte am Laptop einstecke. Dabei werden jedes mal zwei neue Dateimanagerfenster geöffnet. Einmal für die Bootpartition und einmal für die Betriebssystempartition auf der SD-Karte. Da ich normalerweise jedoch über das Terminal auf die SD-Karte zugreifen möchte, schließe ich die Fenster immer direkt nachdem sie geöffnet wurden.
In den Systemeinstellungen von Linux Mint habe ich keine Option gefunden um dieses Verhalten zu ändern. Also habe ich in der Vergangenheit das Verhalten des Betriebssystems eben akzeptiert. Immerhin handelt es sich doch nur um ein Luxusproblem.
Heute hat mich dieses Verhalten jedoch so genervt, dass ich mich auf die Suche nach einer Lösung gemacht habe. Und -Taaadaaa- nach Jahren der Nutzung habe ich die Einstellungen des Dateimanagers Nemo entdeckt.
Für den Fall dass ich nicht der einzige bin, der vor lauter Bäumen den Wald nicht sieht, schreibe ich diesen Beitrag.
Automatisches Mounten und Öffnen von externen Datenträgern unter Linux Mint deaktivieren.
Die entsprechende Option findet man nicht in den Systemeinstellungen, sondern in den Einstellungen des Dateimanagers Nemo. In einem geöffneten Fenster klickt man auf Bearbeiten > Einstellungen. Hier wäht man in der linken Menüleiste den Punkt “Verhalten” und scrollt nach unten zu “Handhabung von Datenträgern“.
Hier findet man die beiden gesuchten Optionen “Automatisch entfernbare Medien, beim Einfügen und beim Systemstart, einhängen” sowie “Für automatisch eingehängte Geräte, automatisch einen neuen Ordner öffnen“.
Wenn man bei beiden Optionen den Haken entfernt, werden externe Datenträger zukünftig zwar noch in der Seitenleiste von Nemo angezeigt, jedoch nicht mehr eingehängt und nicht mehr geöffnet.
Anmelden
