Autorenarchiv: Jörg Kastning

Don’t Push To Production On Friday

So stand es an einem Freitag auf Mastodon geschrieben. Nach einem Schmunzeln fragte ich mich: „Ja warum eigentlich nicht?“ Dieser Frage möchte ich heute nachgehen.

Der englischsprachige Satz aus dem Titel ist eine Aufforderung, an einem Freitag keine Änderungen an produktiven Systemen vorzunehmen, um das Wochenende nicht zu gefährden. Viele von euch kennen vermutlich berühmte letzte Worte wie:

  • Was soll schon schiefgehen?
  • Nur noch diese kleine Änderung, dann ist Feierabend.
  • Das wurde getestet, da kann nichts passieren.
  • Das geht ganz schnell, ich mache das noch eben.

Nicht selten hat sich der Feierabend oder das Wochenende nach diesen Sätzen erheblich verzögert oder sind ganz ausgefallen, weil eben doch etwas schiefgegangen ist. In der Folge waren wichtige Dienste nicht mehr verfügbar und Systemadministratoren haben das Abendessen mit ihrer Familie versäumt, weil sie den Klump wieder zum Laufen bringen mussten. Solche Erlebnisse führen zu Aussagen wie:

  • Never change a running system. Oder eben
  • Don’t push to production on Friday

Die Logik dahinter ist bestechend einfach. Wenn etwas funktioniert und man nichts daran ändert, wird wohl auch nichts kaputt gehen. Allerdings stehen diese Aussagen dem DevOps-Mantra von Continuous Integration and Continuous Delivery (CI/CD) entgegen, welches fordert, dass Änderungen zu jeder Zeit möglich sein müssen.

Und wer hat nun recht? Ich denke, die Wahrheit liegt wie so oft irgendwo in der Mitte.

Ob Änderungen durchgeführt werden können, hängt in meinen Augen nicht vom Wochentag ab, sondern vielmehr von den Antworten auf die folgenden Fragen:

  • Sind alle für die Abnahmetests erforderlichen Key-User nach der Änderungen verfügbar und können direkt im Anschluss testen?
  • Sind alle Verantwortlichen anwesend bzw. verfügbar, welche entscheiden, ob die Änderung bzw. das Deployment erfolgreich war oder nicht?
  • Liegt das Wartungsfenster in einem Zeitraum, in dem ggf. externe Supportdienstleister erreichbar und diese Zeiträume durch Service-Level-Agreements (SLA) abgedeckt sind?
  • Findet die Änderung in einem Zeitfenster statt, in dem Störungen toleriert werden können?

Sind zum Beispiel alle 37 Key-User, 8 Abteilungsleiterinnen und das 20-köpfige Betriebs-Team für die Personal- und Buchhaltungsanwendung Freitag nach 18:00 bis voraussichtlich 21:00 Uhr alle verfügbar und können im Fehlerfall mit offenem Ende verfügbar bleiben, steht einer Änderung bzw. einem Deployment nichts im Wege. Ist dies jedoch nicht der Fall und man stellt Fehler möglicherweise erst im Laufe des kommenden Montags fest, wo ein Rollback evtl. schon nicht mehr möglich ist, sollte man den Change vielleicht lieber Montagmorgen starten?

In einem anderen Fall ist das Team nicht sicher, ob sie das System im Fehlerfall ohne Hilfe des Herstellers wiederherstellen können. Der Support-Vertrag deckt jedoch nur die Zeiten Mo-Fr von jeweils 08:00-17:00 Uhr mit 4 Stunden Reaktionszeit ab. Hier ist es vielleicht ebenfalls besser, das Wartungsfenster in den frühen Morgen als in den Freitagabend zu legen.

Habe ich hingegen einen 24/7-Supportvertrag und meine IT-Betriebsabteilung darf auch am Wochenende arbeiten, bietet sich ein Change mit langer Dauer am Wochenende an, um die Betriebsabläufe möglichst wenig zu beeinträchtigen.

Sind Änderungen nur von kurzer Dauer und man möchte möglichst viele User verfügbar haben, die sofort testen und mögliche Fehler finden, ist vermutlich auch Dienstag Vormittag 10:00 Uhr eine gute Zeit.

Es hängt also nicht primär vom Wochentag, sondern vielmehr von einigen anderen Faktoren ab, wann Änderungen in Produktion ausgerollt werden sollten.

Wie seht ihr das? Nach welchen Kriterien werden bei euch Deployments geplant und durchgeführt?

PS: Ich finde jedoch absolut nichts Verwerfliches daran, wenn man sich den Freitag für die Pflege und Aktualisierung der Dokumentation reservieren kann und nicht mit aller Gewalt noch etwas kaputtfuckeln muss. ;-)

RHEL System Roles: rhc

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.

Das Tool rhc selbst habe ich bereits im Artikel Red Hat Remote Host Configuration ausführlich vorgestellt.

Anwendungsfall

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.

Weiterführende Quellen und Links

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: sshd
  8. RHEL System Roles: firewall
  9. RHEL System Roles: storage

Wie ich mich 2023 vor Datenverlust schütze

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.

Der Artikel behandelt nicht:

Daten von Mobiltelefonen und Tablets

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.

Daten von Laptops

Daten meiner Laptops synchronisiere ich teilweise mit Nextcloud, welche ich auf einem virtuellen Server betreibe. Gehostet wird dieser bei Contabo in Deutschland.

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.

Meine Lösung für diese Herausforderung habe ich in Mein Paperless-NGX-Mini-Konzept niedergeschrieben.

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:

Virtuelle Server und Dienste in der Cloud

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.

Wie installiere ich den Netzwerk-Drucker Brother MFC-J890DW in Fedora 38 und RHEL 9?

  1. Schalte den Drucker ein, verbinde ihn mit dem LAN und notiere seine IP-Adresse
  2. Lade das RPM-Paket mit dem Linux-Treiber auf den RHEL 9 Computer herunter
  3. Führe in RHEL 9 folgende Schritte aus
  4. sudo dnf in <linux-treiber-name.rpm>
  5. Öffne in einem Webbrowser die URL http://localhost:631/printers
  6. Klicke unter Administration auf „Modify Printer“ und setze die folgenden Parameter
    • AppSocket/HP JetDirect für Device
    • ipp://<IP-Adresse-des-Druckers>/ipp/port1 für Device URI
    • Brother als Hersteller
    • IPP Everywhere als Treiber

Da es mich mal wieder tierisch genervt hat, bis das Höllengerät endlich druckte, habe ich die Installationsschritte kurz aufgeschrieben.

Quellen:

Container mit podman-auto-update automatisch aktualisieren

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:

  1. Anwendungsfälle
  2. Voraussetzungen
  3. Umgebung und verwendetes Container-Image
  4. Konfiguration des systemd-Service mit Auto-Update-Funktion
  5. Container (automatisch) aktualisieren

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.

Darüber hinaus solltet ihr Manpages lesen können.

Umgebung und verwendetes Container-Image

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 volume inspect uptime-kuma
[
     {
          "Name": "uptime-kuma",
          "Driver": "local",
          "Mountpoint": "/home/tronde/.local/share/containers/storage/volumes/uptime-kuma/_data",
          "CreatedAt": "2023-08-22T20:52:06.477341481+02:00",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "MountCount": 0,
          "NeedsCopyUp": true,
          "NeedsChown": true
     }
]

Der Schlüssel Mountpoint enthält den Pfad im lokalen Dateisystem, in dem das Volume erstellt wurde.

Manpages zum Nachschlagen:

  • podman-volume(1)
  • podman-volume-create(1)
  • podman-volume-inspect(1)

Container starten

$ podman run --label "io.containers.autoupdate=registry" -d -p 3001:3001 -v uptime-kuma:/app/data:Z --name=uptime-kuma docker.io/louislam/uptime-kuma:latest
Trying to pull docker.io/louislam/uptime-kuma:latest...
Getting image source signatures
Copying blob d7ca72974892 done  
Copying blob 475646a04a73 done  
Copying blob 1d496c24aec8 done  
Copying blob 6a3727d8681d done  
Copying blob b00c91ba9805 done  
Copying blob ddade83992f9 done  
Copying blob b8454ed537a7 done  
Copying blob 849e609eff67 done  
Copying blob f861188db6a1 done  
Copying blob 5f3c3e6d7f1c done  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 68b7bcf7c878 done  
Copying config fb3a3565b2 done  
Writing manifest to image destination
Storing signatures
ad7b049d9b84962311f5bafb5329f59961d8a031e54a571f079b8243ea8059ee
  • 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 name docker.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

$ podman generate systemd --name --new uptime-kuma
# container-uptime-kuma.service
# autogenerated by Podman 4.4.1
# Tue Aug 22 21:29:46 CEST 2023

[Unit]
Description=Podman container-uptime-kuma.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--sdnotify=conmon \
	--replace \
	--label io.containers.autoupdate=registry \
	-d \
	-p 3001:3001 \
	-v uptime-kuma:/app/data:Z \
	--name=uptime-kuma docker.io/louislam/uptime-kuma:latest
ExecStop=/usr/bin/podman stop \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target
  • 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
$ podman generate systemd --name --new --files uptime-kuma
/home/tronde/container-uptime-kuma.service

Manpages zum Nachschlagen:

  • podman-auto-update(1)
  • podman-generate-systemd(1)

Die erstellte Systemd-Unit aktivieren und starten

$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reload
  • 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
$ systemctl --user status container-uptime-kuma.service
○ container-uptime-kuma.service - Podman container-uptime-kuma.service
     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>
     Active: inactive (dead)
       Docs: man:podman-generate-systemd(1)
$ podman stop uptime-kuma
$ podman rm uptime-kuma
$ systemctl --user start container-uptime-kuma.service
$ systemctl --user status container-uptime-kuma.service
● container-uptime-kuma.service - Podman container-uptime-kuma.service     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>     Active: active (running) since Tue 2023-08-22 21:59:56 CEST; 14s ago
…
  • Der erste Befehl in obigen Code-Block prüft den aktuellen Status des Service
  • Der zweite und dritte Befehl stoppen und entfernen den laufenden Container, den wir weiter oben gestartet haben
  • Befehl Nummer 4 startet den Uptime-Kuma-Service
  • Befehl Nummer 5 prüft den neuen Status des Service; dieser ist nun up-and-running

Manpages zum Nachschlagen:

  • mv(1)
  • systemd.unit(5)
  • systemctl(1)

Auf neue Container-Images prüfen

$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
docker.io/louislam/uptime-kuma:latest false
  • 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:

$ podman auto-update
            UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
            container-uptime-kuma.service  df21116f2573 (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    false

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 units podman-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
$ systemctl --user --no-pager -l status podman-auto-update
○ podman-auto-update.service - Podman auto-update service
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
     Active: inactive (dead) since Sun 2023-09-03 00:12:56 CEST; 7h ago
TriggeredBy: ● podman-auto-update.timer
       Docs: man:podman-auto-update(1)
    Process: 309875 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS)
    Process: 310009 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS)
   Main PID: 309875 (code=exited, status=0/SUCCESS)
        CPU: 5.128s

Sep 03 00:12:50 example.com podman[309875]: Copying config sha256:d56b643e048f2d351ed536ec9a588555dfd4c70de3c8d510ed61078a499ba464
Sep 03 00:12:50 example.com podman[309875]: Writing manifest to image destination
Sep 03 00:12:50 example.com podman[309875]: Storing signatures
Sep 03 00:12:51 example.com podman[309875]: 2023-09-03 00:12:41.98296115 +0200 CEST m=+1.880671312 image pull  docker.io/louislam/uptime-kuma:latest
Sep 03 00:12:55 example.com podman[309875]:             UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
Sep 03 00:12:55 example.com podman[309875]:             container-uptime-kuma.service  814407c7312c (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    true
Sep 03 00:12:56 example.com podman[310009]: fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65
Sep 03 00:12:56 example.com podman[310009]: 2023-09-03 00:12:55.421998943 +0200 CEST m=+0.020260134 image remove fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65 
Sep 03 00:12:56 example.com systemd[686]: Finished Podman auto-update service.
Sep 03 00:12:56 example.com systemd[686]: podman-auto-update.service: Consumed 5.128s CPU time.

Ich hoffe, das Tutorial hat euch gefallen und konnte euch einen Eindruck vermitteln, wie man automatische Updates für Container konfigurieren kann.

Red Hat Remote Host Configuration

Im folgenden Text gebe ich eine Einführung in Red Hat Remote Host Configuration (rhc). Dabei handelt es sich um ein Werkzeug, um Red Hat Enterprise Linux (RHEL) System mit der Hybrid Cloud Console zu verbinden und aus dieser heraus verwalten zu können.

Der Artikel soll interessierten RHEL-Nutzern zur Information und Wissensvermittlung dienen. Dazu wird rhc auch im Kontext subscription-manager und insights-client eingeordnet.

Aus Gründen der Transparenz weise ich hiermit darauf hin, dass ich Angestellter der Firma Red Hat bin.

Hintergrund

Als ich persönlich angefangen habe, mich für RHEL zu interessieren, war die Version 7 aktuell und von Simple Content Access (SCA) noch keine Rede. Um RHEL-Systeme betreiben zu können, waren diese beim Red Hat Subscription Management (RHSM), einem Satellite-Server oder offline zu registrieren, um Subscription Entitlements zuweisen zu können. Hierfür gab und gibt es das Kommando subscription-manager.

Im Laufe der Zeit kam der Dienst Red Hat Insights hinzu, zu welchem es hier im Blog bereits eine Einführung gab. Um Systeme hierfür zu registrieren, gibt es das Kommando insights-client. Die Console, die einst nur Red Hat Insights beheimatete, hat sich zur Hybrid Cloud Console entwickelt, welche heute Heimat für viele weitere Dienste rund um RHEL, OpenShift und die Ansible Automation Platform (AAP) ist.

Es hat sich viel getan. Dank SCA [1] entfällt die Notwendigkeit, Entitlements zuweisen zu müssen und das Subscription Management befindet sich im Übergang zur Hybrid Cloud Console. Übergang bedeutet hier insbesondere, dass viele Teile in Bewegung sind und sich in Zukunft noch ändern werden. Der Artikel unter [6] gibt einen Überblick dazu.

Hybrid Cloud Console mit Insights und Ansible Remediation Playbooks

Die folgenden vier Absätze wurden der Dokumentation entnommen und mit www.DeepL.com/Translator (kostenlose Version) übersetzt.

Die Red Hat Hybrid Cloud Console ist eine webbasierte, einheitliche Verwaltungsoberfläche für Red Hat-Lösungen. Mit der Hybrid Cloud Console können Sie eine Verbindung zu Ihren verschiedenen Plattformen herstellen und dann Ihre Hybrid Cloud und die darin enthaltenen Systeme zentral verwalten und automatisieren.

Verwenden Sie die Hybrid Cloud Console, um Ihre RHEL-Infrastruktur, Red Hat OpenShift-Cluster, AAP-Infrastruktur und Anwendungsdienste zu verwalten.

Die Red Hat Hybrid Cloud Console bietet einen zentralen Einblick in Betrieb, Sicherheit und Subscriptions für Red Hat Enterprise Linux (RHEL).

Mithilfe von Tools, regelbasierten Analysemodellen und der Unterstützung von Red Hat können Sie die Konsole nutzen, um viele der Aufgaben und Analysen zu optimieren, die für den Aufbau und die Bereitstellung einer stabilen und sicheren Umgebung für Anwendungen auf RHEL erforderlich sind.

Dem Marketing-Text der vorstehenden Absätze möchte ich einen Hinweis hinterherschicken. Mit der Hybrid Cloud Console verhält es sich wie mit allen extern gehosteten Cloud-Diensten. Hat der Anbieter ein Problem oder ist die Cloud bzw. das Internet nicht verfügbar, ist auch der Cloud-Dienst nicht verfügbar. Bei der Fähigkeit, meine Infrastruktur zu administrieren, möchte ich mich persönlich daher nicht allein auf einen externen Dienst verlassen und empfehle dies auch niemanden. In meinen Augen ist die Hybrid Cloud Console ein zusätzliches Werkzeug, welches mit Red Hat Insights einen hohen Mehrwert bietet.

In den nun folgenden Abschnitten beschreibe ich, wie in der Hybrid Cloud Console ein Activation Key erstellt wird und wie man diesen nutzt, um Systeme mittels rhc in der Console zu registrieren. Anschließend zeige ich, wie dank rhc Ansible Remediation Playbooks direkt aus der Console heraus auf verbundenen RHEL-Systemen ausgeführt werden können.

Ob man einem extern durch Dritte gehosteten Dienst das Recht einräumen möchte, Änderungen an den eigenen Server-Systemen durchführen zu können, muss jeder für sich selbst und seine Umgebung bewerten. Ich möchte hier lediglich die Funktionalität in meiner Lab-Umgebung demonstrieren.

Activation Key erstellen

Um einen Activation Key zu erstellen [10], meldet man sich an der Hybrid Cloud Console (https://console.redhat.com) an und tippt in das Suchfeld im oberen Bereich „create activation key“ ein.

Startseite der Hybrid Cloud Console. In das Suchfeld im oberen Bereich der Seite wurde der Text "create activation key" eingegeben. Es werden zwei Suchergebnisse angezeigt.
Ausgefüllte Suchmaske in der Hybrid Cloud Console

Der erste Treffer führt uns zu folgender Maske, in der ein Activation Key erstellt werden kann:

Menü zur Erstellung von Activation Keys
Dialog zum Erstellen von Activation Keys. Hier werden die Parameter Name, Role, SLA und Usage definiert.
Dialog zur Erstellung des Activation Keys

Nach einem Klick auf die Schaltfläche Create activation key erscheint der oben dargestellte Dialog. Die Optionen, die unter Role, Service Level Agreement (SLA) und Usage zur Auswahl stehen, hängen von den im Account vorhandenen Subscriptions ab. Mit ihnen wird der sogenannte System Purpose bestimmt. Der Name kann frei gewählt werden. Er erscheint anschließend in der Übersicht.

Übersicht existierender Activation Keys
Übersicht der existierenden Activation Keys

Hinweis: Die Organization ID und der Name des Activation Key sind vertraulich zu behandeln, da mit diesen Informationen Systeme für die Hybrid Cloud Console registriert werden können.

System mit rhc registrieren

Mit dem Befehl rhc -h erhält man eine Beschreibung, wie Organization ID und Activation Key genutzt werden, um das System bei Red Hat zu registrieren:

DESCRIPTION:
   The rhc command controls the system's connection to Red Hat.
   
   To connect the system using an activation key:
     rhc connect --organization ID --activation-key KEY

Führt man den Befehl wie angegeben aus und ist die Registrierung erfolgreich, erhält man folgende Ausgabe:

Connecting host.example.com to Red Hat.
This might take a few seconds.

● Connected to Red Hat Subscription Management
● Connected to Red Hat Insights
● Activated the Remote Host Configuration daemon
● Enabled console.redhat.com services: remote configuration, insights, remediations, compliance

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

Unter der URL https://red.ht/connector ist der Remote Host Configuration Manager erreichbar. Hier werden die aktuellen Einstellungen angezeigt und können bei Bedarf geändert werden.

Das Bild zeigt die Konfigurationsseite des Remote Host Configuration Manager. Hier werden die Einstellungen für Insights Remediations, rhc Einstellungen und OpenSCAP Policies vorgenommen.
Darstellung der Seite Remote Host Configuration Manager

Der rhc Client konfiguriert auf dem RHEL host den rhcd service, welcher die Verbindung zur Hybrid Cloud Console initiiert und über eine MQTT-Verbindung auf Instruktionen lauscht [14].

Möchte man mehrere Systeme registrieren, empfehle ich die Verwendung der RHEL System Role rhc. Auf diese werde ich in einem folgenden Beitrag noch genauer eingehen.

Die Registrierung und Einbindung in die Hybrid Cloud Console ist damit abgeschlossen.

Ansible Remediation Playbook erstellen und ausführen

Die offizielle Dokumentation für die folgenden Schritte befindet sich unter [12]. Ich habe ein System gewählt, welches noch nicht aktualisiert wurde und daher einige Schwachstellen aufweist.

Das Bild zeigt eine Übersicht von CVEs. Zwei CVEs wurden für die Remediation mit Ansible ausgewählt.
Übersicht der vorhandenen CVE. Zwei Einträge wurden für die Remediation mit Ansible ausgewählt.

In der Übersicht können CVE ausgewählt werden, welche mit Hilfe eines Ansible Remediation Playbook geschlossen werden sollen. Mit einem Klick auf die Schaltfläche Remediate gelangt man in den Assistenten zur Erstellung des Playbooks.

Das Bild zeigt einen Dialog, in dem ein Name für ein neues Playbook vergeben wird.
Der Name des Playbooks kann frei gewählt werden.
Im dargestellten Dialog werden die ausgewählten Systeme angezeigt. Eine Bearbeitung ist hier nochmals möglich.
In Schritt zwei können verwundbare Systeme ausgewählt werden.
Das Bild zeigt den letzten Dialog des Remediate-Assistenten. Es wird auf einen automatischen Neustart hingewiesen.
Review der Einstellungen mit dem Hinweis, dass das Zielsystem durch das Playbook automatisch neugestartet wird.
Das Bild zeigt einen Screenshot von der erfolgreichen Erstellung eines Playbooks.
Bis hierher wurde nur ein Playbook erstellt. Es wurde noch keine Remediation durchgeführt.

Die erstellten Playbooks findet man im Menü unter Red Hat Insights –> Automation Toolkit –> Remediations. Bisher kann das Playbook hier allerdings nur heruntergeladen werden, um es auf einem Ansible Controller in der eigenen Infrastruktur auszuführen. Um diese Playbooks direkt aus der Hybrid Cloud Console heraus ausführen zu können, muss der verwendete User Mitglied einer Gruppe mit der Rolle Remediations administrator sein.

Ein Exkurs in die Rollen- und Rechteverwaltung der Hybrid Cloud Console würde an dieser Stelle zu weit führen. Nachdem die Voraussetzungen für die Ausführung von Remediation Playbooks geschafften wurden, stehen folgende Schritte zur Verfügung.

In der Ansicht des Remediation Jobs kann das Playbook nun direkt ausgeführt werden.
Eine letzte Bestätigung, dann geht es los.

Im Hintergrund passiert nun folgendes:

  1. Das Playbook wird auf den oder die Hosts übertragen
  2. Auf den Hosts wird es durch die dort lokal installierte Ansible Engine (Paket ansible-core) ausgeführt
  3. Der Host wird anschließend automatisch neugestartet
  4. In der Console wird anschließend sichbar, dass die Remediation abgeschlossen wurde

Ob man einem SaaS-Dienst, der von einem US-Unternehmen in den USA gehostet wird, Zugriff auf die eigenen Server gewähren möchte bzw. darf, muss individuell bewertet werden.

Ich gestehe dem Service allerdings zu, dass er die Verwaltung und Remediation von Sicherheitslücken, fehlenden Advisories und Konfigurationsanpassungen durch den Advisor denkbar einfach gestaltet.

Ein Werkzeug für alles?

Für die in diesem Text aufgeführten Anwendungsfälle

  • Registrieren eines RHEL-Hosts an der Hybrid Cloud Console
  • Ausführen von Ansible Remediation Playbooks

ist die Verwendung des rhc-Clients ausreichend; ein Ersatz für den insights-client ist er allerdings nicht. Letzterer wird im Hintergrund weiterhin verwendet, um Insights-Reports an die Hybrid Cloud Console zu senden.

Auch die vielfältigen Optionen des subscription-manager werden nicht abgebildet. Der rhc-Client ist daher mehr eine Ergänzung als ein Ersatz für die bekannten Kommandos.

Fazit

Der rhc-Client ist in meinen Augen das Mittel der Wahl, möchte man RHEL-Systeme für die Verwaltung durch Insights und die Ausführung von Ansible Remediation Playbooks an die Hybrid Cloud Console anbinden.

Ich hoffe euch interessierten Lesern, die bishierhin ausgehalten haben, hat diese Einführung gefallen. In der folgenden Liste findet ihr einige Links, hinter denen ihr euer Wissen noch vertiefen könnt.

  1. Remote Host Configuration and Management – Using the remote host configuration and management features for Red Hat Insights
  2. Simple Content Access
  3. Red Hat Subscription Management
  4. Red Hat Insights
  5. Einführung in Red Hat Insights
  6. Transition of Red Hat’s subscription services to console.redhat.com
  7. Red Hat Hybrid Cloud Console
  8. Product Documentation for Red Hat Hybrid Cloud Console 2023
  9. Subscription-Manager for the former RHN user, part 13: System Purpose
  10. Remote Host Configuration and Management: Chapter 6. Creating and managing activation keys in the Red Hat Hybrid Cloud Console
  11. Automating system administration by using RHEL System Roles: Chapter 7. Using the rhc System Role to register the system
  12. Creating and managing remediation playbooks in Insights
  13. Executing remediation playbooks
  14. Remote Host Configuration (rhc)

Warum entwickelt/testet ihr (nicht) auf CentOS Stream, Fedora oder RHEL?

Hi, mein Name ist Jörg. Ich arbeite seit März 2023 als Senior Technical Account Manager für Red Hat und mir schwirren derzeit folgende Fragen im Kopf herum:

  • Wer sind die Menschen, die Open Source Software auf bzw. für CentOS Stream, Fedora und/oder RHEL entwickeln?
    • Sind es Menschen, die dies ausschließlich in ihrer Freizeit tun?
    • Arbeiten sie in Unternehmen, welche nach dem Open Source Entwicklungsmodell arbeiten?
  • Warum habt ihr euch für oder gegen die eine oder andere Distribution entschieden?
  • Was hindert euch daran, eine der genannten Distributionen zu verwenden?
  • Aus welchem Grund bevorzugt ihr andere Distributionen und welche sind dies?

Hinsichtlich dieser Fragen habe ich selbst offensichtlich einen Interessenskonflikt und bin darüber hinaus zu einem hohen Grad betriebsblind. Deshalb bin ich umso mehr daran interessiert, eure Antworten auf diese Fragen zu lesen.

Ich freue mich, wenn ihr euch die Zeit nehmt, um mir zu antworten und mir zu erläutern, wie ihr dazu steht. Eure Nachrichten nehme ich gern auf folgenden Kanälen entgegen:

  • Als Kommentar unter diesem Artikel
  • Als E-Mail an jkastning+distribution (at) my-it-brain (dot) de
  • Als Chat-Nachricht in #my-it-brain:matrix.org

Es freut mich, wenn daraus eine freundliche und konstruktive Diskussion entsteht. Sollte es dabei allerdings zu Trolling oder unangemessenen Äußerungen kommen, werde ich die Kommentare schließen und die Kommunikation einstellen. Bitte geht daher höflich miteinander um und behandelt einander so, wie ihr selbst auch behandelt werden möchtet.

Mein Paperless-NGX-Mini-Konzept

Paperless-NGX ist ein bekanntes und beliebtes Open Source Dokumenten-Management-System (DMS). Auch ich möchte zukünftig meinen „Papierkram“ darin verwalten.

In diesem Artikel halte ich meine Gedanken fest, wie ich plane, paperless-ngx in meiner Umgebung aufzusetzen und zu betreiben.

Dies hilft mir, zu prüfen, ob ich auch an alles Wichtige gedacht habe. Falls euch das Konzept gefällt, dürft ihr es selbstverständlich gerne nachahmen. Und wenn ihr schwerwiegende Fehler darin entdeckt, freue ich mich über einen Hinweis.

Es ist kein Tutorial und keine Schritt-für-Schritt-Anleitung. Zwar mag dieser Text dazu dienen, sich eine eigene Umgebung aufzubauen, Mitdenken ist dabei jedoch zwingend erforderlich.

Ziele

  • Betrieb von Paperless-NGX als rootless-Podman-Container
  • Consumption-Ordner als Samba-Share freigegeben, um via Netzwerk Dateien hineinkopieren zu können
  • Getrennte Benutzerkonten für meine Frau und mich
  • Freigabe gewisser Dokumente für weitere Benutzer(gruppen)
  • Erfolgreicher Restore-Test

Infrastruktur

In meinem Heimnetzwerk betreibe ich einen Desktop-/Server-PC. Auf diesem läuft aktuell RHEL 9 als KVM/QEMU-Hypervisor. Er dient mir ebenfalls als Ansible Control Node. Hierauf betreibe ich eine RHEL-9-VM mit einer rootless-Podman-Installation. Diese VM wird auch meine Paperless-NGX-Instanz hosten.

In der VM wird das EPEL-Repository aktiviert, um daraus die Pakete podman-compose und python3-pexpect installieren zu können.

Falls ich mal nicht mehr weiß, wie dieses Setup aufgebaut wird, finden sich dazu Hinweise in folgenden Links:

Installation mit Ansible

Für die Installation der Anwendung wird die Container Route verwendet. Die Installation wird dabei unter Nutzung der Ansible-Rolle tronde.paperless_ngx_with_rootless_podman automatisiert.

Das Playbook deploy_paperless_ngx.yml, welches auf meiner Synology Diskstation abgelegt ist, führt die Installation und Konfiguration der Anwendung durch. Es installiert und konfiguriert zudem Samba und die Datei-Freigabe des Consumption-Verzeichnisses.

In dem Playbook werden folgende Rollen verwendet:

Die Rollen sind mit dem Playbook in meinem Ansible-Projekt-Verzeichnis auf meiner Synology Diskstation installiert.

Alle Playbooks und Rollen werden mit Git versioniert. Die Repositories werden auf entfernte Rechner synchronisiert.

Vorbereitung

Die Dateien docker-compose.postgres-tika.yml, docker-compose.env und .env werden aus dem Projekt-Repository in das Rollen-Verzeichnis files meiner Ansible-Rolle heruntergeladen. Die Datei docker-compose.postgres-tika.yml wird dabei zu docker-compose.yml umbenannt und bearbeitet.

Um Datenverlust vorzubeugen, wird die Ansible-Rolle mit den angepassten Dateien in die regelmäßige Datensicherung aufgenommen.

Folgende Variablen werden in meinem Ansible-Vault hinterlegt:

# Paperless-ngx with podman-compose
pnwrp_podman_user: alice
pnwrp_podman_group: alice
pnwrp_compose_dir: /home/{{ pnwrp_podman_user }}/paperless-ngx
pnwrp_paperless_superuser: alice
pnwrp_paperless_superuser_email: alice@example.com
pnwrp_paperless_superuser_password: ImWunderland
## Username and password for document scanner
brother_scanner_user: scanner
brother_scanner_pass: ImWunderland

Die Werte der Variablen werden selbstverständlich angepasst.

Das Playbook

Folgender Code-Block zeigt das fertige Playbook mit Beispielwerten:

---
- hosts: host.example.com
  remote_user: alice
  debugger: never
  vars_files:
    - files/alice.vault
  tasks:
    - name: Setup Paperless-NGX with podman-compose in rootless Podman
      include_role:
        name: ansible_role_paperless-ngx_with_rootless_podman

    - name: Enable Port 8000/tcp in host firewall
      ansible.posix.firewalld:
        port: 8000/tcp
        immediate: true
        permanent: true
        state: enabled
      become: true

    - name: >-
        Create and add {{ brother_scanner_user }} to
        {{ pnwrp_podman_group }}
      ansible.builtin.user:
        name: "{{ brother_scanner_user }}"
        comment: "Brother Dokumenten-Scanner"
        create_home: false
        groups: "{{ pnwrp_podman_group }}"
        append: true
        shell: /usr/sbin/nologin
        state: present
        system: true
      become: true

    - name: Include role vladgh.samba.server
      include_role:
        name: vladgh.samba.server
      vars:
        ansible_become: true
        samba_users:
          - name: "{{ pnwrp_podman_user }}"
            password: "{{ alice_password }}"
          - name: "{{ brother_scanner_user }}"
            password: "{{ brother_scanner_pass }}"
        samba_shares:
          - name: consumption
            comment: 'paperless consumption directory'
            path: "{{ pnwrp_compose_dir }}/consume"
            read_only: false
            guest_ok: false
            browseable: true
            owner: "{{ pnwrp_podman_user }}"
            group: "{{ pnwrp_podman_group }}"
            write_list: +{{ pnwrp_podman_group }}

    - name: Enable samba in host firewall
      ansible.posix.firewalld:
        service: samba
        immediate: true
        permanent: true
        state: enabled
      become: true

Das Playbook gewinnt sicher keinen Schönheitswettbewerb, doch arbeitet es bisher robust und tut, was es soll. In Tests habe ich meine Wunschumgebung damit mehrmals provisioniert.

Backup & Restore

Wie es sich gehört, wird erst ein Backup erstellt, dann die Anwendung inkl. aller Daten gelöscht und wiederhergestellt.

Backup

Für das Backup verwende ich ein Ansible-Playbook, welches sich zum Podman-Host verbindet und dort folgende Aufgaben ausführt:

  1. Stelle sicher, dass das Backup-Verzeichnis auf dem Remote-Host existiert
  2. Stoppe alle Paperless-NGX-Container
  3. Exportiere Podman-Volumes in TAR-Archive; hänge das aktuelle Datum an die Dateinamen an
  4. Archiviere und komprimiere paperless-ngx-Verzeichnis auf Remote-Host; hänge das aktuelle Datum an die Dateinamen an
  5. Starte alle Paperless-NGX-Container
  6. Komprimiere die Exporte der Podman-Volumes
  7. Synchronisiere das Backup-Verzeichnis auf dem Remote-Host mit einem Verzeichnis auf meiner Diskstation
  8. Synchronisiere das Diskstation-Verzeichnis mit einem verschlüsselten S3-Bucket

Es fehlt die Aufgabe, alte Backups aufzuräumen. Darum werde ich mich kümmern, wenn 70% des verfügbaren Speicherplatzes belegt sind.

Der folgende Code-Block zeigt ein Muster des verwendeten Playbooks:

---
- name: Backup podman volumes
  hosts: host.example.com
  gather_facts: true
  vars:
    paperless_ngx_dir: /home/alice/paperless-ngx
    docker_compose_file: docker-compose.yml
    remote_backup_dir: /home/alice/backups
    diskstation_backup_dir: /home/alice/diskstation/home/backups/host.example.com

  tasks:
    - name: Ensure backup directory exists
      ansible.builtin.file:
        path: "{{ remote_backup_dir }}"
        state: directory
        owner: alice
        group: alice
        mode: 0777

    - name: Stop paperless-ngx containers
      ansible.builtin.command: >
        podman-compose -f {{ paperless_ngx_dir }}/{{ docker_compose_file }} stop

    - name: List podman volumes
      ansible.builtin.command: podman volume ls --quiet
      register: __podman_volumes
      tags:
        - volumes

    - name: Output __podman_volumes
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ __podman_volumes['stdout_lines'] }}"
      tags:
        - volumes

    - name: Export podman volumes
      ansible.builtin.command: >
        podman volume export {{ item }} --output {{ remote_backup_dir }}/{{ item }}_{{ ansible_facts['date_time']['date'] }}.tar
      loop: "{{ __podman_volumes['stdout_lines'] }}"

    - name: Compact {{ paperless_ngx_dir }}
      community.general.archive:
        path: "{{ paperless_ngx_dir }}"
        dest: "{{ remote_backup_dir }}/paperless-ngx_{{ ansible_facts['date_time']['date'] }}.tar.gz"
        format: gz

    - name: Start paperless-ngx containers
      ansible.builtin.command: >
        podman-compose -f {{ paperless_ngx_dir }}/{{ docker_compose_file }} start

    - name: Compress volume exports
      community.general.archive:
        path: "{{ remote_backup_dir }}/{{ item }}_{{ ansible_facts['date_time']['date'] }}.tar"
        format: gz
        remove: true
      loop: "{{ __podman_volumes['stdout_lines'] }}"
      tags:
        - compress

    - name: Sync backups to diskstation
      ansible.posix.synchronize:
        archive: true
        compress: false
        delete: false
        dest: "{{ diskstation_backup_dir }}"
        mode: pull
        private_key: /home/alice/.ssh/ansible_id_rsa
        src: "{{ remote_backup_dir }}/"
      delegate_to: localhost
      tags:
        - rsync

    - name: Sync backups from diskstation to contabo S3
      ansible.builtin.command: rclone sync -P ../backups/ secure:backups
      delegate_to: localhost
      tags:
        - rsync

Das Playbook wird einmal wöchentlich ausgeführt. Ob ich für die geplante Ausführung cron oder systemd timer units verwende, habe ich noch nicht entschieden. Ich tendiere aus Neugier zu letzterem.

Um ein Offsite-Backup zu haben, werden die Dateien von der Diskstation einmal wöchentlich verschlüsselt und in einen S3-Speicher synchronisiert. Ich nutze dafür das Programm rclone und S3-kompatiblen Speicher von Contabo. Die folgenden Links bieten weiterführende Informationen dazu:

Restore

Um die Dateien aus dem verschlüsselten S3-Objekt-Speicher wiederherstellen zu können, wird die Datei $HOME/.config/rclone/rclone.conf benötigt, welche die geheimen Zugriffsinformationen enthält. Ich halte diese Datei auf meinen verschiedenen Rechnern in einem Backup außerhalb des S3-Speichers vor.

Der Ablaufplan für die Wiederherstellung der Anwendung mit ihren Daten sieht wie folgt aus:

  1. Eine rootless-Podman-Umgebung bereitstellen
  2. podman-compose bereitstellen
  3. TAR-Archive auf Zielsystem übertragen
  4. Paperless-NGX mit Playbook installieren
  5. Alle Container stoppen
  6. Inhalt der TAR-Archive in die Podman-Volumes importieren (siehe podman-volume-import(1)): gunzip -c hello.tar.gz | podman volume import myvol -
  7. Alle Container starten

Fazit

Bereitstellung, Sicherung und Wiederherstellung funktionieren wie beschrieben. Damit kann ich nun beginnen und die Anwendung konfigurieren und mit meinem Papierkram füttern.

Die Samba-Freigabe habe ich ebenfalls getestet. Sie funktioniert wie erwartet. PDF-Dateien mit dem Befehl find Documents -type f -iname "*.pdf" -exec cp {} /consume \; hineinzukopieren ist übrigens besonders dann eine gute Idee, wenn man sehen möchte, welche Dateien so in den Tiefen des eigenen Dateisystems schlummern.

Mit Ansible über YAML Lists and Dictionaries iterieren

In diesem Artikel beschreibe ich die beiden Ansible-Variablen-Typen „List variables“ und „Dictionary variables“ sowie die Kombination beider Typen. Ich zeige mit einem einfachen Playbook, wie diese Variablen-Typen in einer Schleife (eng. loop) durchlaufen werden können.

Während der Text mir zur Übung und Erinnerung dient, hoffe ich, dass er für die Einsteiger unter euch eine hilfreiche Einführung bietet. Für weiterführende Informationen verlinke ich im Text direkt auf die Ansible-Dokumentation.

List

Eine Liste ist eine Variable mit einem Namen und einem bis mehreren Werten. Folgender Code-Block zeigt die List-Variable namens list mit ihren zwei Werten:

list:
  - Alice Cooper
  - Bob Marley

Die Einrückung der Werte ist wichtig. Sie erhöht nicht nur die Lesbarkeit, sondern vermeidet auch Lint-Fehler bei der Anwendung von ansible-lint. Bedauerlicherweise läuft euer Playbook auch, wenn ihr die Werte nicht einrückt, doch bitte ich euch, euch diesen schlechten Stil nicht anzugewöhnen.

Listen sind mit Arrays verwand. Sie besitzen einen Index, welcher bei 0 beginnt und für jedes Listen-Element (für jeden Wert) um 1 inkrementiert wird. Folgendes Beispiel zeigt, wie man das Listen-Element mit dem Wert „Alice Cooper“ der einfachen Variable favorit zuweisen kann:

favorit: "{{ list[0] }}"

Dictionary

Ein Dictionary speichert Daten in Schlüssel-Wert-Paaren (excuse my German). Dabei darf der Wert eines Dictionary wiederum ein Dictionary sein.

Ein einfaches Dictionary sieht wie folgt aus:

Felder:
  Feld1: 10ha
  Feld2: 40ha

Möchte man z.B. auf den Wert des Schlüssels Feld2 aus dem Dictionary Felder zugreifen, geht dies wie folgt:

mein_feld: "{{ Felder['Feld2'] }}"
# oder
mein_feld: "{{ Felder.Feld2 }}"

Die beiden folgenden Code-Blöcke zeigen zwei Beispiele für etwas komplexere Dictionaries, über die ich später iterieren werde:

dict:
  Alice:
    last_name: Cooper
    job: singer
  Bob:
    last_name: Marley
    job: singer
virtual_machines_with_params:
  vm1:
    cpu_count: 2
    memory_mb: 2048
    guest_os: rhel8
  vm2:
    cpu_count: 2
    memory_mb: 1024
    guest_os: rhel9

Auch hier ist die Einrückung sehr wichtig. Macht man dabei einen Fehler, fängt man sich einen Syntax-Fehler bei der Ausführung des Playbooks ein.

List of Dictionaries

Beide zuvor beschriebenen Variablen-Typen können miteinander kombiniert werden. Folgendes Beispiel zeigt eine Liste von Dictionaries:

list_of_dicts:
  - first_name: Alice
    last_name: Cooper
    job: singer
  - first_name: Bob
    last_name: Marley
    job: singer

Syntaxfehler

In Ansible und YAML spielt die Einrückung von Code eine sehr wichtige Rolle. Des Weiteren ist bei der Kombination von Variablen-Typen nicht alles erlaubt. Folgender Code-Block zeigt ein fehlerhaftes Beispiel und die Fehlermeldungen, die es generiert:

$ cat nonsense.yml 
---
nonsense:
 - first_name: Alice
     last_name: Cooper
     job: singer
 - first_name: Bob
     last_name: Marley
     job: singer

$ ansible-lint nonsense.yml
WARNING  Listing 1 violation(s) that are fatal
load-failure: Failed to load YAML file
nonsense.yml:1 mapping values are not allowed in this context
  in "<unicode string>", line 4, column 15


             Rule Violation Summary              
 count tag          profile rule associated tags 
     1 load-failure min     core, unskippable    

Failed after : 1 failure(s), 0 warning(s) on 1 files.

Tipp: Um Fehler bei der Eingabe zu vermeiden, habe ich meinen Editor Vim mit folgenden Optionen konfiguriert: set ts=2 sts=2 sw=2 et ai cursorcolumn

Playbook

Das folgende Playbook nutzt das Modul ansible.builtin.debug, um Werte der genannten Variablen-Typen auszugeben. Es zeigt dabei, wie diese Variablen in einer Schleife durchlaufen werden können.

Damit es übersichtlich bleibt, nutze ich Tags, um die Tasks im Playbook einzeln ausführen zu können.

$ cat output_dicts_and_lists.yml 
---
- name: Output content of dicts_and_lists.yml
  hosts: localhost
  gather_facts: false
  become: false
  vars_files:
    - dicts_and_lists.yml
  tasks:
    - name: Task 1 Ouput all vars in dicts_and_lists.yml
      loop:
        - "{{ list }}"
        - "{{ dict }}"
        - "{{ list_of_dicts }}"
      ansible.builtin.debug:
        var: item
      tags:
        - dicts_and_lists

    - name: Task 2 Loop over some list
      loop: "{{ list }}"
      ansible.builtin.debug:
        msg: "Name: {{ item }}"
      tags:
        - list

    - name: Task 3 Loop over some dictionary
      loop: "{{ dict | dict2items }}"
      ansible.builtin.debug:
        msg: "Firstname: {{ item.key }} Lastname: {{ item.value.last_name }}"
      tags:
        - dict

    - name: Task 4 Loop over some list_of_dicts
      loop: "{{ list_of_dicts }}"
      ansible.builtin.debug:
        msg: "Firstname: {{ item.first_name }} Lastname: {{ item.last_name }}"
      tags:
        - list_of_dicts

Task 1: Ouput all vars in dicts_and_lists.yml

Dies ist der erste Task aus obigem Playbook. Er gibt die Werte der Variablen list, dict und list_of_dicts aus. Diese habe ich als Liste an loop übergeben (siehe Loops in der Dokumentation).

$ ansible-playbook output_dicts_and_lists.yml --tags dicts_and_lists
…
PLAY [Output content of dicts_and_lists.yml] ***********************************

TASK [Task 1 Ouput all vars in dicts_and_lists.yml] ****************************
ok: [localhost] => (item=['Alice Cooper', 'Bob Marley']) => {
    "ansible_loop_var": "item",
    "item": [
        "Alice Cooper",
        "Bob Marley"
    ]
}
ok: [localhost] => (item={'Alice': {'last_name': 'Cooper', 'job': 'singer'}, 'Bob': {'last_name': 'Marley', 'job': 'singer'}}) => {
    "ansible_loop_var": "item",
    "item": {
        "Alice": {
            "job": "singer",
            "last_name": "Cooper"
        },
        "Bob": {
            "job": "singer",
            "last_name": "Marley"
        }
    }
}
ok: [localhost] => (item=[{'first_name': 'Alice', 'last_name': 'Cooper', 'job': 'singer'}, {'first_name': 'Bob', 'last_name': 'Marley', 'job': 'singer'}]) => {
    "ansible_loop_var": "item",
    "item": [
        {
            "first_name": "Alice",
            "job": "singer",
            "last_name": "Cooper"
        },
        {
            "first_name": "Bob",
            "job": "singer",
            "last_name": "Marley"
        }
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

In der Ausgabe ist zu erkennen, dass Listen mit [ ] und Dictonaries mit { } umschlossen werden. Der folgende Code-Block zeigt zum Vergleich den Inhalt der Datei dicts_and_lists.yml.

---
list:
  - Alice Cooper
  - Bob Marley

dict:
  Alice:
    last_name: Cooper
    job: singer
  Bob:
    last_name: Marley
    job: singer

list_of_dicts:
  - first_name: Alice
    last_name: Cooper
    job: singer
  - first_name: Bob
    last_name: Marley
    job: singer

Task 2: Loop over some list

Als Nächstes schauen wir uns die Ausgabe von Task 2 an, welcher lediglich die einzelnen Listenelemente nacheinander ausgibt.

$ ansible-playbook output_dicts_and_lists.yml --tags list
PLAY [Output content of dicts_and_lists.yml] ***********************************

TASK [Task 2 Loop over some list] **********************************************
ok: [localhost] => (item=Alice Cooper) => {
    "msg": "Name: Alice Cooper"
}
ok: [localhost] => (item=Bob Marley) => {
    "msg": "Name: Bob Marley"
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Die Variable item referenziert das jeweils aktuelle Element der Liste, welche mit loop durchlaufen wird.

Task 3: Loop over some dictionary

Um Scrollen zu vermeiden, zeigten die beiden folgenden Code-Blöcke noch einmal den entsprechenden Task aus obigem Playbook und das Dictionary, welches für dieses Beispiel benutzt wird. Der dritte Code-Block zeigt dann die dazugehörige Ausgabe.

    - name: Task 3 Loop over some dictionary
      loop: "{{ dict | dict2items }}"
      ansible.builtin.debug:
        msg: "Firstname: {{ item.key }} Lastname: {{ item.value.last_name }}"
      tags:
        - dict

Bevor ein Dictionary mit loop verarbeitet werden kann, muss es in eine Liste transformiert werden. Dies geschieht mit Hilfe des Filters dict2items.

In einigen älteren Playbooks sieht man statt loop ein Lookup-Plugin in der Form with_dict: "{{ dict }}". Dies ist ebenfalls korrekt, heute jedoch nicht mehr gebräuchlich.

dict:
  Alice:
    last_name: Cooper
    job: singer
  Bob:
    last_name: Marley
    job: singer
$ ansible-playbook output_dicts_and_lists.yml --tags dict

PLAY [Output content of dicts_and_lists.yml] ***********************************

TASK [Task 3 Loop over some dictionary] *****************************************
ok: [localhost] => (item={'key': 'Alice', 'value': {'last_name': 'Cooper', 'job': 'singer'}}) => {
    "msg": "Firstname: Alice Lastname: Cooper"
}
ok: [localhost] => (item={'key': 'Bob', 'value': {'last_name': 'Marley', 'job': 'singer'}}) => {
    "msg": "Firstname: Bob Lastname: Marley"
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Task 4: Loop over some list_of_dicts

Auch hier sind Dictionaries involviert, doch wird kein Filter dict2items benötigt, da es sich bereits um eine Liste handelt, welche an loop übergeben wird.

Die drei folgenden Code-Blöcke zeigen die verwendete Liste, den Task aus obigem Playbook und die Ausgabe.

list_of_dicts:
  - first_name: Alice
    last_name: Cooper
    job: singer
  - first_name: Bob
    last_name: Marley
    job: singer
    - name: Task 4 Loop over some list_of_dicts
      loop: "{{ list_of_dicts }}"
      ansible.builtin.debug:
        msg: "Firstname: {{ item.first_name }} Lastname: {{ item.last_name }}"
      tags:
        - list_of_dicts
$ ansible-playbook output_dicts_and_lists.yml --tags list_of_dicts

PLAY [Output content of dicts_and_lists.yml] ***********************************

TASK [Loop over some list_of_dicts] ********************************************
ok: [localhost] => (item={'first_name': 'Alice', 'last_name': 'Cooper', 'job': 'singer'}) => {
    "msg": "Firstname: Alice Lastname: Cooper"
}
ok: [localhost] => (item={'first_name': 'Bob', 'last_name': 'Marley', 'job': 'singer'}) => {
    "msg": "Firstname: Bob Lastname: Marley"
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Auch hier ist wieder an den { } zu erkennen, dass item jeweils eine Liste enthält. Der Zugriff auf die Werte geschieht durch die Referenzierung des jeweiligen Schlüssel-Namens. So ist z.B. Alice der Wert des Schlüssels first_name.

Bonusmaterial: Lists in Dicts

Jörn hat ein weiteres Beispiel beigesteuert. Da die Kommentarfunktion von WordPress den Code nicht sauber darstellt, spendiere ich Jörn eine eigene Überrschrift und baue sein Beispiel hier ein.

Jörns Datenstruktur sieht wie folgt aus:

dict_of_lists:
  - name: foo 
    elems:
      - foo one 
      - foo two 
      - foo three
  - name: bar 
    elems:
      - bar one 
      - bar two 
  - name: baz 
    elems:
      - baz one 
      - baz two 
      - baz three

Jörn möchte nun zuerst auf alle Elemente (elems) von foo zugreifen, dann auf jene von bar usw. Dazu nutzt Jörn das Lookup Plugin subelements.

Folgender Code-Block nutzt die Datenstruktur in einem Playbook, um die verschachtelten Elemente auszugeben. Aufruf und Ausgabe zeigt der darauf folgende Block.

---
- name: Lists in dicts
  hosts: localhost
  become: false
  vars:
    dict_of_lists:
      - name: foo
        elems:
          - foo one
          - foo two
          - foo three
      - name: bar
        elems:
          - bar one
          - bar two
      - name: baz
        elems:
          - baz one
          - baz two
          - baz three

  tasks:
    - name: Loop over lists in dicts
      ansible.builtin.debug:
        msg: "Name: {{ item.0.name }}, element {{ item.1 }}"
      loop: "{{ dict_of_lists | subelements('elems') }}

Und hier nun der Playbook-Aufruf mit Ausgabe:

$ ansible-playbook dict_of_lists.yml

PLAY [Lists in dicts] ************************************************************************

TASK [Gathering Facts] ************************************************************************
ok: [localhost]

TASK [Loop over lists in dicts] ************************************************************************
ok: [localhost] => (item=[{'name': 'foo', 'elems': ['foo one', 'foo two', 'foo three']}, 'foo one']) => {
    "msg": "Name: foo, element foo one"
}
ok: [localhost] => (item=[{'name': 'foo', 'elems': ['foo one', 'foo two', 'foo three']}, 'foo two']) => {
    "msg": "Name: foo, element foo two"
}
ok: [localhost] => (item=[{'name': 'foo', 'elems': ['foo one', 'foo two', 'foo three']}, 'foo three']) => {
    "msg": "Name: foo, element foo three"
}
ok: [localhost] => (item=[{'name': 'bar', 'elems': ['bar one', 'bar two']}, 'bar one']) => {
    "msg": "Name: bar, element bar one"
}
ok: [localhost] => (item=[{'name': 'bar', 'elems': ['bar one', 'bar two']}, 'bar two']) => {
    "msg": "Name: bar, element bar two"
}
ok: [localhost] => (item=[{'name': 'baz', 'elems': ['baz one', 'baz two', 'baz three']}, 'baz one']) => {
    "msg": "Name: baz, element baz one"
}
ok: [localhost] => (item=[{'name': 'baz', 'elems': ['baz one', 'baz two', 'baz three']}, 'baz two']) => {
    "msg": "Name: baz, element baz two"
}
ok: [localhost] => (item=[{'name': 'baz', 'elems': ['baz one', 'baz two', 'baz three']}, 'baz three']) => {
    "msg": "Name: baz, element baz three"
}

PLAY RECAP ************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Fazit

Das waren nun eine Menge Code-Blöcke. Mir hat es geholfen, dieses Thema noch einmal zu rekapitulieren. Listen können direkt an loop übergeben werden. Dictionaries müssen zuerst den Filter dict2items durchlaufen.

In diesem Text wurden noch nicht alle Fälle besprochen. So wurden nested lists und tiefer verschachtelte Dictionaries ausgespart, um den Artikel nicht noch mehr in die Länge zu ziehen.

Ich hoffe, der Text war auch für die Anfänger und Einsteiger unter euch hilfreich.

Internetanbindung um zweiten Anschluss erweitern

Hi. Heute bin ich an euren Ideen und Empfehlungen interessiert. Wie würdet ihr folgende Aufgabe angehen?

Ist-Zustand

Das Bild zeigt eine vereinfachte Skizze des Heimnetzwerks, bestehend aus Connect Box (Router), Pi-Hole und LAN.
Vereinfachte Skizze meines Heimnetzwerks

Aktuell ist mein Heimnetzwerk über einen Unitymedia/Vodafone-Kabelanschluss mit dem Internet verbunden. Für die Verbindung zum Netz verwende ich die Unitymedia-Connect-Box. Die WLAN-Funktion und der DHCPv4-Server sind deaktiviert, da sich der Pi-Hole und ein Netgear-Orbi-System um diese Funktionen kümmern.

Dieses Setup hat einen Nachteil. Das Router Advertisement der Connect Box lässt sich nicht deaktivieren und nicht weiter konfigurieren. Mit diesem werden die DNS-Server des Internet Service Provider (ISP) im LAN announced. Diese werden von den Clients mit einer höheren Priorität genutzt als der Pi-Hole, was dessen Einsatz ad absurdum führte. Um dieses Problem zu mitigieren, habe ich die DHCPv6 Adressvergabe der Connect Box auf das Minimum von 1 Adresse reduziert. Damit entfaltet der Pi-Hole seine Wirkung und wir bleiben von Werbung weitestgehend verschont. Da die Clients im LAN nun jedoch keine IPv6-Adressen mit Scope Global besitzen, lassen sich Hosts im Internet, welche nur über IPv6 erreichbar sind, nicht ansprechen.

Es kommt ein Glasfaseranschluss hinzu

Voraussichtlich gegen Ende diesen Jahres kommt ein Glasfaseranschluss des Anbieters Sewikom hinzu. Dieser wird bis in den Keller gelegt und endet im sogenannten Hausübergabepunkt (HÜP). An den HÜP wird ein eigener Router via Kupfer-Patch-Kabel angeschlossen.

Der Router ist noch nicht vorhanden und muss von mir gekauft werden.

Gewünschtes Zielszenario

Ich möchte zukünftig beide Anschlüsse parallel nutzen können. Entweder in einer Active-Standby-Konfiguration oder Active-Active-Konfiguration. In letzten Fall wäre auch eine Möglichkeit charmant, in der ich konfigurieren kann, welche Clients welchen WAN-Anschluss bevorzugt nutzen sollen. Fällt ein Anschluss aus, sollen alle Geräte den verbliebenen Anschluss nutzen können.

Damit der Router nicht zum Single-Point-of-Failure wird, möchte ich für diesen ein Cold-Standby-Gerät vorhalten, da Hardware mit Hot-Standby-Unterstützung für das Heimnetzwerk vermutlich übertrieben teuer wird.

Bei der Lösung muss berücksichtigt werden, dass ich auch zukünftig nicht auf DNS-Filterlisten verzichten möchte. Ob diese Funktionalität vom Pi-Hole oder von einer integrierten Router-/Firewall-Lösung bereitgestellt wird, ist jedoch zweitrangig.

Vermutlich bietet es sich an, ein Netzwerkgerät zu verwenden, welches neben der Gateway-/Routing-Funktionalität auch eine Firewall bietet, die den Verkehr zwischen verschiedenen Netzwerkzonen steuern kann.

Wie habt ihr das gelöst?

An dieser Stelle kommt ihr ins Spiel. Wer von euch betreibt bereits ein solches Szenario mit zwei Internetanschlüssen (Glasfaser und Kabel) und wie habt ihr das gelöst?

Welche Hardware verwendet ihr? Warum habt ihr euch für diese entschieden und wovon würdet ihr aus Erfahrung abraten?

Bitte schreibt mir eure Antworten in die Kommentare, per E-Mail oder in den Chat (#my-it-brain:matrix.org).