Archiv des Autors: Jörg Kastning

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

RHEL System Roles: storage

Willkommen zu Teil 6 meiner losen Reihe über die RHEL System Roles. In diesem Teil stelle ich euch die Rolle storage vor, mit welcher sich unpartitionierte Laufwerke und LVM-Volumes verwalten lassen.

Zuerst stelle ich meinen Anwendungsfall vor. Anschließend beschreibe ich, wie ich diesen mithilfe der RHEL System Role storage löse.

Während mir dieser Artikel zur Dokumentation dient, soll er euch den Einsatz von RHEL System Roles verdeutlichen.

Hinweis: Zum Zeitpunkt der Erstellung dieses Artikels unterstützt die Rolle die LVM-Konfiguration lediglich auf unpartitionierten Laufwerken, welche komplett als Physical Volume (PV) genutzt werden.

Wer sich an dieser Stelle fragt, was RHEL System Roles sind, wie man sie installiert und nutzt, dem empfehle ich am Anfang zu beginnen: Vorstellung der Red Hat Enterprise Linux (RHEL) System Roles.

Anwendungsfall

Mit der Ansible-Rolle kvm_provision_lab (siehe [1,2]) provisioniere ich virtuelle Maschinen (VM) auf KVM/QEMU-Hypervisoren. In „Labor-Umgebung mit Ansible in KVM erstellen“ habe ich die Anwendung dieser Rolle bereits detailliert beschrieben. Eine VM wird darin als ein YAML-Dictionary nach folgendem Muster definiert:

test-vm1:
    vm_ram_mb: 512
    vm_vcpus: 1
    vm_iftype: network
    vm_net: default
    os_type: rhel9
    file_type: qcow2
    base_image_name: rhel9-template
    vm_template: "rhel9-template"
    second_hdd: true
    second_hdd_size: "2G"

Das Beispiel im Code-Block provisioniert eine VM mit einem zweiten Blocklaufwerk. Dieses wird in der VM als /dev/vdb konfigruiert.

Um das zweite Laufwerk nutzen zu können, müssen zuerst eine Partitionstabelle und eine Partition erstellt und diese mit einem Dateisystem formatiert werden. Alternativ kann das Gerät auch für LVM verwendet werden.

Ich möchte aus /dev/vdb ein PV für LVM machen, um es einer Volume Group (VG) vg_data hinzuzufügen und ein Logical Volume (LV) zu erstellen, welches die gesamte Speicherkapazität von /dev/vdb nutzt.

Die Rolle

Durch die Installation des Pakets rhel-system-roles existiert diese Rolle storage bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.stroage/ und die Dokumentation in /usr/share/doc/rhel-system-roles/storage/README.md. Aus letzterer stammt auch folgendes Beispiel:

Example Playbook
----------------

```yaml
- hosts: all

  roles:
    - name: rhel-system-roles.storage
      storage_pools:
        - name: app
          disks:
            - sdb
            - sdc
          volumes:
            - name: shared
              size: "100 GiB"
              mount_point: "/mnt/app/shared"
              #fs_type: xfs
              state: present
            - name: users
              size: "400g"
              fs_type: ext4
              mount_point: "/mnt/app/users"
      storage_volumes:
        - name: images
          type: disk
          disks: ["mpathc"]
          mount_point: /opt/images
          fs_label: images

```

Da ich auf /dev/vdb ein LVM konfigurieren möchte, kopiere ich mir das Dictionary storage_pools aus obigen Beispiel und passe es für mein Playbook an.

Das Playbook

---
- hosts: test-vm1

  roles:
    - name: rhel-system-roles.storage
      storage_pools:
        - name: vg_data
          disks:
            - vdb
          volumes:
            - name: data1
              size: "2 GiB"
              mount_point: "/mnt"
              fs_type: ext4
              state: present

Obiges Playbook führt folgende Schritte auf dem Host test-vm1 durch:

  1. Das Blockgerät /dev/vdb wird als PV für LVM konfiguriert.
  2. Es wird die Volume Group (VG) vg_data auf dem PV /dev/vdb erstellt.
  3. In der VG vg_data wird das LV data1 erstellt.
  4. Das LV wird mit dem Dateisystem Ext4 formatiert.
  5. Das LV wird unterhalb von /mnt eingehängt.

Innerhalb des Gast-Betriebssystems lässt sich mit folgenden Kommandos prüfen, dass die Konfiguration wie gewünscht durchgeführt wurde.

[root@test-vm1 ~]# lsblk vdb
lsblk: vdb: not a block device
[root@test-vm1 ~]# lsblk /dev/vdb
NAME            MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vdb             252:16   0   2G  0 disk 
└─vg_data-data1 253:0    0   2G  0 lvm  /mnt
[root@test-vm1 ~]# pvs
  PV         VG      Fmt  Attr PSize  PFree
  /dev/vdb   vg_data lvm2 a--  <2.00g    0 
[root@test-vm1 ~]# vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  vg_data   1   1   0 wz--n- <2.00g    0 
[root@test-vm1 ~]# lvs
  LV    VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data1 vg_data -wi-ao---- <2.00g                                                    
[root@test-vm1 ~]# mount | grep mnt
/dev/mapper/vg_data-data1 on /mnt type ext4 (rw,relatime,seclabel)
[root@test-vm1 ~]# echo "Hallo Welt!" >/mnt/world.txt
[root@test-vm1 ~]# cat /mnt/world.txt
Hallo Welt!

Fazit

Der betrachtete Anwendungsfall lässt sich mit der vorgestellten Ansible-Rolle schnell und einfach umsetzen. Man deklariert lediglich die Wunschkonfiguration im Ansible-Playbook und die Rolle kümmert sich um den Rest, wie die Installation der notwendigen Pakete auf den Zielsystemen.

Unterstützt werden als Zielsysteme aktuell EL 7-9 sowie Fedora. Damit ist sie für die Anwendung auf Debian bzw. darauf basierende Systeme nicht geeignet. Wie man auch für diese Systeme ein einfaches Playbook entwirft, um LVM für Blockgeräte zu konfigurieren, werde ich in einem folgenden Artikel zeigen.

Ich hoffe, dass euch auch die Vorstellung dieser Rolle gefallen hat und wünsche euch viel Spaß bei der Nutzung der RHEL System Roles.

  1. https://galaxy.ansible.com/Tronde/kvm_provision_lab
  2. https://github.com/Tronde/kvm_provision_lab
  3. https://github.com/linux-system-roles/storage
  4. Vorstellung der Red Hat Enterprise Linux (RHEL) System Roles
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: sshd
  8. RHEL System Roles: firewall

Utilize PowerCLI to resize VMDK files of multiple VMs

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.

WP fail2ban: Gutes Plugin mit ausbaufähiger Dokumentation

WP fail2ban ist ein Plugin zum Schutz von WordPress-Installationen vor Brute-Force-Angriffen. Installation und Konfiguration habe ich bereits im Artikel WordPress mit Fail2Ban vor Brute-Force-Angriffen schützen dokumentiert. Dieser Text beschäftigt sich mit der offiziellen Dokumentation des Plugins, bzw. dem Text, der sich als Dokumentation ausgibt.

Ich stelle hier meine Erwartung an eine Dokumentation heraus, zeige die Schwächen der exemplarisch ausgewählten Dokumentation heraus und gebe einen Tipp, wie man weniger schlechte Dokus schreibt. Ich schließe mit Fragen an meine Leserinnen und Leser und freue mich auf eure Rückmeldungen.

In meinen Augen sind folgende drei Abschnitte zwingender Bestandteil einer jeden Dokumentation:

  1. Was ist dies für eine Anwendung? Wofür wird sie verwendet und wofür nicht?
  2. Wie wird diese Anwendung installiert?
  3. Wie wird diese Anwendung konfiguriert?

Die ersten beiden Punkte mag ich als erfüllt betrachten. Beim dritten Punkt sehe ich ein Problem.

Bildschirmfoto der WP fail2ban-Installationsanleitung. Zeitstempel 2023-06-04T20:54+02

Die Installationsanleitung ist prägnant. Sie enthält einen Link, der suggeriert, zur Konfigurationsanleitung zu führen. Dort erwartet den neugierigen Leser folgendes Bild.

Bildschirmfoto vom Einstieg in die WB fail2ban-Konfigurationsanleitung. Zeitstempel 2023-06-04T20:59+02

Hier gibt es noch keine nützlichen Informationen zu sehen. Die Seite ist in meinen Augen überflüssig. Aber gut, ein Satz tut nicht weh. Mit einem Klick auf „Next“ geht es weiter.

Bildschirmfoto WP fail2ban-Dokumentation. Zeitstempel 2023-06-04T21:04+02

Hier steht im Wesentlichen, dass Nutzer, welche sich bereits auskennen, zum nächsten Abschnitt gehen können. Leider finden sich für neue Nutzer hier kaum brauchbare Informationen. Der Hinweis, die Datei wp-config.php zu sichern, bevor man diese bearbeitet, ist nett, mehr nicht. Es wird erwähnt, dass die freie (im Sinne von Freibier) Version des Plugins durch Definition von Konstanten in der Datei wp-config.php konfiguriert wird. Wie so eine Konstante aussieht oder wo man weiterführende Informationen dazu findet, steht hier nicht. Ich habe an dieser Stelle entsprechende Hinweise erwartet. Gut, ich kann ja noch auf „Next“ klicken.

Bildschirmfoto WP fail2ban-Dokumentation, Abschnitt Logging. Zeitstempel 2023-06-04T21:14+02

Auch in diesem Abschnitt findet sich keine Information, was man nun mit der Datei wp-config.php soll. Immerhin gibt es in Abschnitt 4.2.1. einen Link, der Nutzer, welche nicht mit der Konfiguration vertraut sind, zur Konfigurationsanleitung führen soll. Ich habe ein Déja Vu und fühle mich langsam ver…hohnepiepelt. Also klicke ich auf den nächsten LInk. Es heißt ja schließlich: „Was lange währt, wird endlich gut.“

TL;DR: Auch auf der nächsten Seite erfahren wir nichts über die wp-config.php.

Bildschirmfoto der URL: https://docs.wp-fail2ban.com/en/5.0/configuration/fail2ban.html#configuration-fail2ban. Zeitstempel 2023-06-04T21:21+02

Zur Erinnerung: Ich nutze die freie Version des Plugins WP fail2ban, welches angeblich durch die Definition von Konstanten in der Datei wp-config.php konfiguriert wird. Welche Konstanten dies sind und wie man diese konfiguriert, wird auch auf Seite 4 immer noch nicht mit einem Wort erklärt.

Stattdessen lernt man in Abschnitt „4.3.1.1. Typical Settings“, dass die Dateien wordpress-hard.conf und wordpress-soft.conf in das Verzeichnis fail2ban/filters.d zu kopieren sind. Hier wurden in meinen Augen zwei Fehler gemacht:

  1. Es wird nicht erwähnt, wie man die Dateien wordpress-,{hard,soft}.conf erhält bzw. erstellt. Als unerfahrener Nutzer strandet man hier. Zum Glück hatte ich mir das damals aufgeschrieben.
  2. Es wird eine relative Pfadangabe fail2ban/filters.d genutzt. Dies ist nicht ganz so wild, ich persönlich bevorzuge es, wenn vollständige Pfadangaben genutzt werden, damit Nutzer das entsprechende Verzeichnis sicher finden.

Fazit

Eine Dokumentation sollte die notwendigen Informationen bereitstellen, mit denen auch neue Nutzer eine Anwendung installieren und konfigurieren können. Dies ist nicht so leicht, wie es auf den ersten Blick erscheint, leiden Autoren, welche die Anwendung bereits kennen, doch häufig unter Betriebsblindheit und können sich nur schwer in die Rolle des unerfahrenen Nutzers versetzen.

Wenn ich selbst Dokumentationen schreibe, gebe ich diese meist Kolleginnen und Kollegen zu lesen und arbeite deren Rückmeldungen mit ein. Dies hat in der Vergangenheit zu deutlich besseren Ergebnissen geführt.

Die hier kritisierte Dokumentation ist ein Beispiel dafür. Sie befindet sich damit leider in guter Gesellschaft im Internet.

Ohne meinen Eingangs erwähnten Artikel hier im Blog wäre ich nicht in der Lage gewesen, mir dieses Plugin wieder einzurichten. Nun werde ich einige Tage prüfen, ob es wie erhofft arbeitet und dann ggf. einen Merge-Request mit einigen Verbesserungsvorschlägen einreichen.

Fragen an meine Leserinnen und Leser

Wie steht ihr zu Dokumentation? Ist das eher etwas für alte weiße Männer mit grauen Bärten? Oder wünscht ihr euch ebenfalls belastbare und ausführliche Dokumentationen zu den von euch verwendeten Anwendungen?

Tragt ihr selbst zu Dokumentationen bei? Welche Erfahrungen habt ihr dabei gemacht? Welche Tipps könnt ihr Schreiberlingen geben, die ihr Projekt dokumentieren möchten?

Bitte hinterlasst mir eure Antworten in den Kommentaren oder im Chat.

Rollen müssen verfügbar sein, nicht einzelne Personen.

In diesem Artikel möchte ich euch ein Modell vorstellen, nach dem sich Wissen auf verschiedene Personen verteilen lässt, um dieses Wissen und die Funktion von Rollen in einem Unternehmen verfügbar zu halten.

Bei den Rollen kann es sich zum Beispiel um den Virtualisierungs-Administrator, den Linux-Admin oder die Rechnungseingangsprüfung sowie den Versand handeln. Die jeweilige Rolle kann dabei von ein oder mehreren Personen ausgefüllt werden. Wichtig ist lediglich, dass die Rolle jederzeit ihre Funktion erfüllen kann.

Das Modell, welches ich gleich vorstelle, stammt nicht von mir. Ein Nerd aus den USA, dessen Namen ich leider nicht mehr weiß, hat es mir am Rande des OpenStack Summit 2018 in Berlin vorgestellt.

RAID – Redundant Array of Independent Dudes

Ja, ihr habt richtig gelesen. Es geht um RAID, aber ohne Festplatten und dafür mit Dudes oder allgemein Personen, die Rollen ausfüllen. Ihr werdet in den folgenden Abschnitten lernen, wie sich die verschiedenen RAID-Level auf die Verfügbarkeit einer Rolle auswirken.

RAID 0 – Nur gemeinsam sind wir stark

Das Bild zeigt zwei Personen, die jeweils zwei Aufgaben wahrnehmen. Die beiden Personen haben nichts weiter miteinander zu tun. Es findet kein Wissensaustausch zwischen ihnen statt.
Zwei Personen nehmen unabhängig voneinander verschiedene Aufgaben wahr.

Dieses Konstrukt habe ich zum Glück noch nicht in der Praxis angetroffen. Hierbei wird eine Rolle von zwei Personen ausgefüllt, welche die Funktion der Rolle jedoch nur im Team sicherstellen können. Fällt eine Person aus, ist die andere allein nicht ausreichend handlungsfähig. Die Funktion der Rolle ist nicht sichergestellt.

RAID 1 – Zwei Personen für eine Rolle

Hier herrscht volle Redundanz. Zwei Personen sind für eine Rolle verantwortlich. Fällt eine Person aus, kann die andere sämtliche damit zusammenhängende Aufgaben allein ausführen. Die Vertretung ist im Falle von Krankheit, Urlaub oder Knast damit zu 100 % sichergestellt.

Gleichzeitig ist der Abstimmungsbedarf minimal, da sich nur zwei Personen miteinander abstimmen müssen.

Das Bild zeigt vier Personen. Jeweils zwei Personen nehmen die gleichen Aufgaben wahr. Pfeile symbolisieren den Informationsfluss zwischen den Personen.
Jeweils zwei Personen stimmen sich miteinander ab, um sich gegenseitig vertreten zu können (RAID 1).

Wenn es gut läuft und man bei der Personal-Akquise ein glückliches Händchen hat, lassen sich vielleicht sogar zwei Personen kombinieren, die zwei oder vielleicht sogar drei Rollen in Personalunion besetzen können.

Zu beachten ist, dass die Leistungsfähigkeit der Rolle beeinträchtigt sein mag, wenn 50 % der normalen Kapazität fehlen. Dies ist von der regelmäßigen Belastung bzw. Auslastung der einzelnen Personen abhängig.

RAID 5 – Parität und Leistung mit erhöhtem Abstimmungsbedarf

Das insgesamt erforderliche Wissen ist in diesem RAID-Level auf mindestens drei oder mehr Personen verteilt. Keine Person verfügt für sich allein über genug Wissen, um eine Rolle vollständig ausfüllen zu können. In der Gesamtheit ist das Wissen jedoch so verteilt, dass bei Ausfall einer Person (Krankheit, Urlaub, Knast, etc.) kein Wissen unwiederbringlich verloren geht, sondern der Verlust durch die verbliebenen Personen aufgefangen werden kann. Dies bezieht sich nicht nur auf das Wissen, sondern auch auf die zu erbringende Leistung.

Das Bild zeigt sechs Personen, von denen jeweils drei die gleichen Aufgaben wahrnehmen. Pfeile unterschiedlicher Farbe zeigen, welche Personen dabei in einer Kommunikationsbeziehung zueinander stehen.
Zwei Teams bestehend aus jeweils drei Personen. Jedes Team stimmt sich zu seinen Aufgaben ab. Es handelt sich quasi um zwei separate RAID-5-Verbünde.

Da jede Person nun mehr als eine Kollegin oder einen Kollegen hat, wird der Abstimmungsbedarf größer. Die einzelnen Personen müssen sich auf dem Laufenden halten, was die Kollegen so tun, um diese bei Bedarf vertreten zu können.

Hat jede Person in diesem RAID-Verbund nur die eine Rolle, für die dieses RAID gebildet wurde, ist das kein Problem. Man hat einfach ein größeres Team, das seinen Job macht. Das funktioniert auch noch, wenn alle in diesem Team/RAID noch eine zweite oder vielleicht auch dritte Rolle ausfüllen. Denn es bleiben dieselben beteiligten Personen, die sich untereinander austauschen können und müssen.

RAID 55 – Wie konnte das passieren?

Ein Bild sagt auf mehr als viele Worte:

Das Bild zeigt sechs Personen, von denen jede zwei Rollen ausfüllt. Jede Rolle ist dreimal im Bild vorhanden. Pfeile verbinden die Personen, die die gleiche Rolle ausfüllen, um darzustellen, wie unübersichtlich es bei ungünstiger Aufgabenverteilung wird.
RAID 55 – Wenn die Aufgabenverteilung unübersichtlich wird

In vorstehendem Bild werden die gleichen Aufgaben durch die gleiche Anzahl von Personen wahrgenommen. Allerdings sind in diesem Bild die Rollen ungeschickt zwischen den Personen verteilt, was einen hohen Kommunikationsaufwand zur Folge hat, da sich mehr Personen zu mehr Themen miteinander abstimmen müssen.

Hinzukommt, dass die Urlaubsplanung in diesem unübersichtlichen Szenario ebenfalls erschwert wird, muss doch darauf geachtet werden, dass die Funktionen der einzelnen Rollen verfügbar bleiben und man nicht versehentlich zwei von drei Personen in den Urlaub schickt, welche die gleiche Rolle ausfüllen und von denen mindestens zwei Personen verfügbar sein müssen.

Leider habe ich dieses Bild in der Praxis schon mehr als einmal gesehen. Es entsteht immer dann, wenn Teams immer weitere Themen übernehmen müssen und man versucht, eine Aufgabe auf immer mehr vorhandene Köpfe zu verteilen, weil gerade jemand da ist, der noch 10 Minuten freie Zeit pro Woche hat.

Dabei mag man sich ausmalen, wie das vorstehende Bild sich verändert, wenn die Anzahl der Personen und Aufgaben unter Beibehaltung der ungeschickten Aufgabenverteilung steigt. Ein Modell, das es in meinen Augen zu verhindern lohnt.

Zusammenfassung

Ich mag RAIDs, da sich mit ihnen auf einfache Weise die Komplexität von Aufgaben-, Arbeitslast-Verteilung und Kommunikations- und Abstimmungs-Aufwände visualisieren und erklären lassen.

Wie gefällt euch das Modell? Habt ihr ähnliche oder ganz andere Erfahrungen in vergleichbaren Team-Strukturen gemacht?

Ehre dem Ehrenamt

In diesem Text geht es einmal nicht um IT. Es ist ein Kommentar zu Tims Artikel „Zum Wochenende: Freiwillige Gesellschaft“ auf GNU/Linux.ch, welcher mir gut gefallen hat.

Tim und ich haben mehrere Dinge gemeinsam. Wir haben beide Familie, einen 40-Stunden-Job, Hobbys und sind Mitglieder einer Freiwilligen Feuerwehr. Ich „leide“ darüber hinaus noch an gewissen Wohlstandkrankheiten und zähle mich selbst daher definitiv nicht zu den fitten Menschen in unserer Gesellschaft. Das hält mich jedoch nicht davon ab, mich ehrenamtlich zu engagieren. Denn es ist mir wichtig, der Gesellschaft etwas zurückzugeben und Menschen in Not zu helfen.

Meine Ausbildung zum Fachinformatiker Systemintegration oder mein Studium der Angewandten Informatik helfen dabei nicht weiter. Das müssen sie aber auch gar nicht. Denn wer sich in der Freiwilligen Feuerwehr engagiert, wird auf Lehrgängen und regelmäßigen Dienstabenden ausgebildet.

Und ja, man muss auch manchmal Kompromisse eingehen. So sind für meine Frau und mich schon gemeinsame Abende ausgefallen, weil Papa zu einem Einsatz musste, um z.B. eine Ölspur abzustreuen, ein Feuer zu löschen, oder die Straße zu sperren, bis das Gasleck geschlossen wurde. Das fällt mir nicht immer leicht.

Erst diese Woche ist unser gemeinsamer Tanzabend ausgefallen, weil ich mit Kameraden zur Unterstützung einer Nachbarwehr gefahren bin. Ein Unwetter hat Massen von Schlamm und Wasser in die Keller, Gärten und Häuser vieler Menschen gespült. Wir konnten sehen, wo der Schlamm ca. 1,60-2,00 Meter hoch in den Kellern stand.

Schön zu sehen war die Hilfsbereitschaft der Menschen. Feuerwehrleute anderer Gemeinden und Städte, Nachbarn und Menschen aus ganz anderen Teilen der Stadt bildeten Eimerketten, um zerstörte Besitztümer und Schlamm aus den Kellern in Mulden zu transportieren. Wer nicht irgendwelchen Unrat schleppte, versorgte die Helfenden mit Verpflegung. In den Straßen gab es Bratwurst, belegte Brötchen, Kuchen, Suppe und Getränke. Es fehlte eigentlich an nichts.

Es war ein gutes Gefühl mitgeholfen zu haben, einen kleinen Teil dazu beigetragen zu haben, anderen Menschen in Not zu helfen. Noch schöner war allerdings, nach nicht ganz 5 Stunden mit langen Armen nach Hause zu kommen und von meiner Frau den Satz zu hören: „Ich bin stolz auf dich und finde es toll, dass du das machst.“

Wenn auch ihr euch ehrenamtlich engagieren möchtet und nicht wisst wie, seid nicht schüchtern oder ängstlich. Schaut bei eurer lokalen Feuerwehr, dem THW, dem Sportverein, der Kleiderkammer, etc. vorbei und fragt, ob ihr euch mal anschauen könnt, was da so passiert und ob das etwas für euch ist. Ich bin mir sicher, man wird euch freundlich empfangen und euch zeigen, was euch erwartet. Und denkt immer daran: „Vieles geht leichter, wenn wir es gemeinsam anpacken.“

Dokumentation meines Proxmox-Setups

Dies ist die lückenhafte Dokumentation meines Proxmox-Setups.

Als langjähriger Administrator von VMware vSphere probiere ich etwas Neues aus. Mein Setup und erste Erkenntnisse halte ich in diesem Artikel fest. Ich werde ihn in der Zukunft weiter ausgestalten und ergänzen.

Ich möchte euch nicht vom Lesen abhalten, doch erwartet nicht zu viel.

Betreiber, Standort und Server-Hardware

Für den Betrieb von Labor-Umgebungen habe ich mir einen Server mit folgender Hardware-Ausstattung in Hetzners Serverbörse gemietet.

Ausstattung:

  • Intel Core i9-9900K (8 Cores/16 Threads)
  • 2x SSD M.2 NVMe 1 TB
  • 4x RAM 32768 MB DDR4
  • NIC 1 Gbit Intel I219-LM
  • Standort: Deutschland, FSN1
  • Rescue-System (Englisch)
  • 1 x Primäre IPv4
  • 1x /64-Subnetz IPv4

Installation

Auf der Hardware habe ich eine Debootstrap-Installation mit Debian 11 (Bullseye) durchgeführt, bei der alle Datenträger mit Ausnahme von /boot LUKS-verschlüsselt sind. Dazu bin ich der hervorragenden Anleitung meines Kollegen Steffen gefolgt: „Manually installing Debian 11 (Bullseye) with fully encrypted LUKS (besides /boot) using debootstrap

Anschließend habe ich die Proxmox-Paketquellen eingebunden und Proxmox VE installiert. Ich weiß nicht mehr genau, welchem Tutorial ich gefolgt bin. Daher habe ich in [1-3] ein paar vielversprechend erscheinende Suchergebnisse verlinkt.

Hinweis: Die aktuelle Netzwerkkonfiguration ist im Abschnitt Netzwerkkonfiguration ab 2023-12-29 dokumentiert. Die vorhergehenden Konfigurationen belasse ich im Artikel, um die Historie nachvollziehen zu können.

Netzwerkkonfiguration bis 2023-07-21

Die physikalische NIC meines Hosts wird mit meiner öffentlichen IPv4 und einer IPv6-Adresse für die Außenanbindung konfiguriert. Im Betriebssystem erstelle ich eine Bridge, an welche später die virtuellen Maschinen (VMs) angeschlossen werden. Über diese Bridge haben die VMs Zugriff auf das Internet und sind vom Internet aus zu erreichen.

Das folgende Bild stellt die Konfiguration exemplarisch dar. Statt IPv4-Adressen verwende ich für die Bridge und VMs jedoch ausschließlich IPv6-Adressen.

Quelle: Proxmox-Wiki – Routed Configuration

Die Datei /etc/network/interfaces meines Hosts hat folgenden Inhalt. Die realen IP-Adressen habe ich dabei durch Adressen aus RFC 3849 und RFC 5737 ersetzt.

$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address 198.51.100.38/27
	gateway 198.51.100.33
	pre-up /sbin/ip addr flush dev eth0 || true

iface eth0 inet6 static
	address 2001:db8:dead:beef::1
	netmask 128
	gateway fe80::1
	up sysctl -w net.ipv6.conf.all.forwarding=1
	up sysctl -p

auto vmbr0
iface vmbr0 inet6 static
	address 2001:db8:dead:beef::2
	netmask 64
	up ip -6 route add 2001:db8:dead:beef::/64 dev vmbr0
	bridge-ports none
	bridge-stp off
	bridge-fd 0

Erläuterungen dazu folgen ggf. später. Als Einstieg empfehle ich einen Blick in die interfaces(5).

Damit eine VM auf das Routing-Netzwerk zugreifen und darüber das Internet erreichen kann, wird diese an die Bridge vmbr0 angeschlossen. Anschließend wird dieser eine IPv6-Adresse aus dem /64-Addressblock konfiguriert, wie es der folgende Code-Block exemplarisch darstellt, wobei static-ipv6 der Name der Verbindung und ens192 der Name der NIC ist:

# nmcli con add con-name static-ipv6 ifname ens192 type ethernet
# nmcli con mod static-ipv6 ipv6.addresses 2001:db8:dead:beef::3/128 ipv6.method manual ipv6.gateway 2001:db8:dead:beef::2
# nmcli con up static-ipv6

Zur Verwendung von nmcli habe ich die Red Hat Dokumentation unter [4] zu Rate gezogen.

Netzwerkkonfiguration ab 2023-07-21 bis 2023-12-29

Ursprünglich habe ich die Absicht verfolgt, alle VMs auf meinem Hetzner-Server ausschließlich mit IPv6 zu betreiben. Wir schreiben ja schließlich das Jahr 2023. Da sollte das doch problemlos möglich sein. Wäre da nicht (mindestens) ein Dienst, der IPv6 nicht unterstützt.

Da es offenbar nicht ganz ohne IPv4 geht, habe ich mir bei Hetzner eine zweite IPv4-Adresse gemietet [5] und bin der Anleitung Netzwerkkonfiguration für Proxmox VE in der Hetzner-Community gefolgt. Da die Anleitung mein bestehendes Setup für IPv6 nicht berücksichtigt, waren ein paar Anpassungen notwendig. Der folgende Code-Block stellt den Inhalt der Dateien /etc/network/interfaces und /etc/network/interfaces.d/vmbr0-extra dar, wobei die IP-Adressen ersetzt wurden.

$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface eth0 inet manual
	pre-up /sbin/ip addr flush dev eth0 || true

auto vmbr0
iface vmbr0 inet static
	address 198.51.100.38/27
	gateway 198.51.100.33
	bridge-ports eth0
	bridge-stp off
	bridge-fd 0

iface vmbr0 inet6 static
	address 2001:db8:dead:beef::1/64
	gateway fe80::1

$ cat /etc/network/interfaces.d/vmbr0-extra 
iface vmbr0 inet static
	hwaddress <zweite MAC-Adresse aus dem Kundenportal>

Die virtuelle Netzwerkkarte der VM, welche über die zweite IPv4-Adresse erreichbar sein soll, wird an die Bridge vmbr0 angeschlossen. Das Interface ens18 im Gastbetriebssystem wurde wie folgt konfiguriert:

# nmcli
ens18: connected to ens18
        "Red Hat Virtio"
        ethernet (virtio_net), 00:50:56:00:8C:22, hw, mtu 1500
        ip4 default, ip6 default
        inet4 198.51.100.36/32
        route4 198.51.100.33/32 metric 100
        route4 default via 198.51.100.33 metric 100
        inet6 fe80::250:56ff:fe00:8c22/64
        inet6 2001:db8:dead:beef::2/64
        route6 2001:db8:dead:beef::/64 metric 100
        route6 default via fe80::1 metric 100
        route6 fe80::/64 metric 1024

# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 185.12.64.1
nameserver 185.12.64.2
nameserver 2a01:4ff:ff00::add:1

Getestet habe ich die Konfiguration, indem ich eine Webseite einmal über IPv4 und einmal über IPv6 abgerufen habe. Dies kann man recht einfach mit curl nach folgendem Muster erledigen:

$ curl -4 [URL]
$ curl -6 [URL]

Netzwerkkonfiguration ab 2023-12-29

Leider bin ich mit der letzten Netzwerkkonfiguration in ein neues Problem gelaufen. Hetzner erlaubt nur registrierte MAC-Adressen auf seinen Switches. Mit dem letzten Setup erschienen jedoch auch die MAC-Adressen meiner virtuellen Maschinen auf den Switches und ich erhielt MAC-Absue-Meldungen.

Um das Problem zu beheben, habe ich mich vom Bridged-Modus verabschiedet und die Konfiguration gemäß der Hetzner-Anleitung Abschnitt „Netzwerkkonfiguration Hostsystem Routed“ umgesetzt.

Für meine Proxy-VM habe ich eine individuelle IPv4-Adresse bestellt und dieser eine separate MAC-Adresse zugewiesen. Damit die IPv4-Kommunikation dieser VM im routed-Setup funktioniert, musste ich die separate MAC-Adresse zurücksetzen. Seitdem können die VMs wieder kommunizieren, ohne MAC-Abuse-Meldungen zu verursachen.

Erster Eindruck

Wie ESXi und vSphere verfügt auch Proxmox VE über ein WebUI zur Administration der Umgebung und zur Erstellung virtueller Maschinen.

Selbstverständlich gibt es einige Unterschiede und nicht alles wirkt sofort vertraut. Bisher konnten die Proxmox-Dokumentation und das Proxmox-Wiki meine Fragen jedoch schnell beantworten.

Eine erste VM war schnell erstellt, installiert und in ein Template umgewandelt. Interessanterweise kann man Templates im WebUI nicht wieder in VMs umwandeln, was bei vSphere kein Problem ist.

Im Gegenzug können ISO-Images oder sonstige Dateien einfach per rsync auf den Proxmox-Host kopiert werden, was gerade beim erneuten Übertragen vorhandener Dateien eine enorme Zeitersparnis mit sich bringt. Hier muss bei vSphere und ESXi zum Upload von Dateien in den Datenspeicher das WebUI, SCP oder die Powershell bemüht werden und erneut zu kopierende Dateien werden jedes Mal komplett übertragen. Was bei Netzwerkgeschwindigkeiten im Datacenter nicht so dramatisch ist, nervt doch sehr, wenn man große ISO-Images über eine Internetleitung übertragen muss.

Der erste Eindruck ist zufriedenstellend. Als nächstes werde ich mich mal damit beschäftigen, wie man VMs mit Ansible auf Proxmox provisioniert. Das community.general.proxmox_kvm-Modul scheint dafür ein guter Einstiegspunkt zu sein.

  1. Install Proxmox VE on Debian 11 Bullseye
  2. So installieren Sie Proxmox auf einem Debian 11-Server
  3. How To Install Proxmox On Debian 11 – A Step-By-Step Guide
  4. Configuring an Ethernet connection with a static IP address by using nmcli
  5. Zusätzliche IP-Adressen bei Hetzner
  6. Proxmox VE Netzwerkkonfiguration