Der Virutal Private Server (VPS), welcher diesen Blog ausliefert, war heute in der Zeit zwischen 08:06 Uhr und 17:52 Uhr nicht erreichbar.
Screenshot aus meiner Uptime-Kuma-Instanz
Ursache ist eine Störung im Nürnberger Rechenzentrum meines Anbieters Contabo. Die Störung besteht offenbar schon seit dem 30.08. (siehe Screenhot der Meldung unten), betraf meinen VPS aber erst heute.
Screenshot einer Contabo-Status-Meldung aus meinen RSS Feed Reader
Screenshot der Contabo-Störungs-Meldung zum Zeitpunkt 2024-09-02T20:11+02
Die Störung bei Contabo ist noch nicht behoben. Es ist nicht auszuschließen, dass dieser Blog nocheinmal davon betroffen sein wird. Ich bitte in diesem Fall um etwas Geduld.
In diesem Beitrag erkläre ich kurz, was Ansible Lint ist und demonstriere dessen Anwendung am Beispiel meiner Ansible Collection tronde/nextcloud.
Er richtet sich primär an Personen, die mit Ansible Lint noch nicht vertraut sind. Linting-Profis werden vermutlich keine neuen Erkenntnisse gewinnen.
Was ist Ansible Lint und wofür ist es gut?
Lint (englisch für „Fussel“) ist eine Software zur statischen Code-Analyse. Davon abgeleitet hat sich das Verb linten (englisch to lint) für das Durchführen der statischen Code-Analyse etabliert.
Dem obigen Zitat und der Projektdokumentation folgend, ist Ansible Lint dementsprechend ein Werkzeug zur statischen Code-Analyse von Ansible Playbooks, Roles und Collections. Mit der Anwendung dieses Werkzeugs auf die eigenen Ansible-Inhalte kann sichergestellt werden, dass diese gängigen Konventionen und Standards entsprechen.
Ansible Lint liefert eine ganze Reihe von Profilen mit, welche Autoren unterstützen, die Code-Qualität schrittweise zu verbessern. Der Befehl ansible-lint --list-profiles gibt die verfügbaren Profile mit einer Beschreibung aus.
Ich werde im Folgenden mit dem Profil shared arbeiten, welches für Autoren gedacht ist, die ihre Collection auf https://galaxy.ansible.com veröffentlichen möchten.
Eine Collection linten
Bevor es zur Sache geht, wechsel ich in das Projektverzeichnis meiner Ansible Collection und erstelle einen neuen Branch, mit dem Befehl git checkout -b lint. Die in meinem Repo vorhandene Datei .ansible-lint-ignore lösche ich, da ich im folgenden alle Fehler und Regelverstöße sehen möchte. Zu Beginn stellt sich mein Arbeitsverzeichnis wie folgt dar:
(adt) nextcloud]$ git status
On branch lint
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: .ansible-lint-ignore
no changes added to commit (use "git add" and/or "git commit -a")
Das Programm ansible-lint besitzt mit der Option --fix die Fähigkeit, Fehler automatisch zu korrigieren und auch YAML-Dateien neu zu formatieren. Der folgende Code-Block umfasst die gekürzte Ausgabe, wenn das Kommando ansible-lint --profile=shared --fix im Arbeitsverzeichnis ausgeführt wird.
(adt) nextcloud]$ ansible-lint --profile=shared --fix
WARNING Listing 37 violation(s) that are fatal
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
galaxy.yml:1
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
…
risky-file-permissions: File permissions unset or incorrect.
roles/backup_restore_nextcloud/tasks/main.yml:18 Task/Handler: Copy backup files to container host
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:40 Task/Handler: Import tarball contents into an existing podman volume
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:54 Task/Handler: Export podman volumes to tarballs
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (MYSQL_DATABASE) (vars: MYSQL_DATABASE)
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml:13
…
Read documentation for instructions on how to ignore specific rule violations.
Modified 6 files.
Rule Violation Summary
count tag profile rule associated tags
33 var-naming[pattern] basic idiom
1 risky-file-permissions safety unpredictability
1 galaxy[no-changelog] shared metadata
2 no-changed-when shared command-shell, idempotency
Failed: 37 failure(s), 0 warning(s) on 25 files. Profile 'shared' was required, but 'min' profile passed.
Obige Ausgabe:
Benennt Funde mit Pfadangabe und Zeilennummer
Führt 37 Fehler auf, inkl. der Regeln, die nicht eingehalten werden; Beispiele
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
risky-file-permissions: File permissions unset or incorrect.
no-changed-when: Commands should not change things if nothing needs doing.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.
Informiert, dass ansible-lint Änderungen an 6 Dateien vorgenommen hat
Mit git diff verschaffe ich mir einen Überblick, welche Änderungen ansible-lint vorgenommen hat. Dies sind in meinem Fall:
galaxy[no-changelog]: No changelog found. Please add a changelog file.
Unter Galaxy: Changelog Details finden sich Hinweise, wie dieser Fehler zu beheben ist. Ich erstelle die leere Datei CHANGELOG.md im Wurzelverzeichnis meiner Collection und der Fehler ist abgestellt.
Natürlich werde ich diese Datei zukünftig nutzen, um die wichtigsten Änderungen zu dokumentieren. ;-)
risky-file-permissions: File permissions unset or incorrect.
Auch hier habe ich kurz in der Dokumentation unter risky-file-permissions nachgesehen. Den Fehler habe ich abgestellt, indem ich den Parameter mode: 0600 zum Task hinzugefügt habe.
Dies war ein Flüchtigkeitsfehler, wie er häufig passieren kann, wenn man seinen Code nicht konsequent überprüft. Ohne den Dateimode explizit zu setzen, kann dies zu unvorhersehbaren bzw. überraschenden Verhalten führen.
no-changed-when: Commands should not change things if nothing needs doing.
An zwei Stellen bin ich leider nicht herumgekommen, das ansible.builtin.command Modul zu verwenden, da kein natives Modul für diese Aufgabe existiert. Betrachtet man sich die beiden Tasks fällt auf, dass diese jedes Mal Daten verarbeiten werden. Sie sind nicht idempotent. Im Ergebnis können sie erfolgreich sein oder fehlschlagen, aber sie werden immer Daten verarbeiten und dadurch ändern.
Um herauszufinden, wie ich ansible-lint zufriedenstellen kann, schaue ich wieder in der Doku unter no-changed-when nach. Nach der dortigen Beschreibung ist mein Fehler, dass ich den Rückgabewert des Kommandos nicht behandel. Daher registriere ich nun eine Variable je Task, die die Task-Ausgabe aufnimmt und prüfe den Rückgabewert. Ist der Rückgabewert gleich 0 wird der Task-Status auf changed gesetzt, ist der Rückgabewert ungleich 0 wird der Status entsprechend auf failed gesetzt. Das ganze sieht nun wie folgt aus:
Collection-intern verwendete Variablen leite ich mit zwei Unterstrichen (‚_‘) ein, um mir zu verdeutlichen, dass diese nicht durch den Nutzer gesetzt werden und daher auch nicht im README.md oder defaults/main.yml dokumentiert sind.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.
Hier brauche ich nicht weiter nachzuschlagen. Ich verstoße gegen diese Regel, da ich meine Variablen-Namen großgeschrieben habe. Die Ausgabe von ansible-lint zeigt dies deutlich:
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
Diese Meldungen lassen sich mit folgendem Bash-Einzeiler abstellen:
$ for text in $(cut -d':' -f 1 roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml | grep -v '^$\|^#\|---'); do find roles -type f -iname "*.yml" | xargs sed -i -e "s/$text/\L&/g"; done
Aus verschiedenen Gründen hebe ich mir die Überarbeitung für später auf und nutze die Meldung, um zu demonstrieren, wie man ansible-lint dazu bringt, bestimmte Fehler zu ignorieren.
Um Regeln für ausgewählte Dateien zu ignorieren, spezifiziert man den jeweiligen Dateinamen und den Namen der Regel in der Datei .ansible-lint-ignore, welche im Wurzelverzeichnis der Collection erstellt wird:
Damit habe ich alle Probleme, die im ersten Durchlauf von ansible-lint gefunden wurden, adressiert. Ein zweiter Durchlauf zeigt das Ergebnis meiner Arbeit:
(adt) nextcloud]$ ansible-lint --profile=shared
WARNING Listing 33 violation(s) marked as ignored, likely already known
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML) (warning) # ignored
roles/backup_restore_nextcloud/defaults/main.yml:4
…Ausgabe gekürzt
WARNING Listing 1 violation(s) that are fatal
yaml[octal-values]: Forbidden implicit octal value "0600"
roles/backup_restore_nextcloud/tasks/main.yml:22
Read documentation for instructions on how to ignore specific rule violations.
Rule Violation Summary
count tag profile rule associated tags
1 yaml[octal-values] basic formatting, yaml
Failed: 1 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'min' profile passed.
Die ignorierten Regelverstöße werden als Warnung weiterhin ausgegeben, nehmen jedoch keinen Einfluss auf die abschließende Bewertung. Dafür habe ich einen neuen Fehler (yaml[octal-values]) eingebaut. Nach dem aktuellen Regelwerk erfordern oktale Werte ein explizites Quoting, um als Strings verarbeitet zu werden.
Nachdem ich das Problem mit mode: '0600' behoben habe, endet ein weiterer Lauf von ansible-lint schlussendlich mit:
Passed: 0 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'production' profile passed.
Damit erfüllt meine Collection aktuell sogar die Anforderungen des nächst höheren Profils production; allerdings nur, weil ich einige Regeln bewusst ignoriere. Daher ist aktuell noch nicht sichergestellt, dass meine Collection tatsächlich bei einem Import auf Ansible Galaxy akzeptiert wird.
Zusammenfassung
Ansible Lint ist ein Werkzeug zur statischen Analyse von Ansible Playbooks, Roles und Collections
Das Werkzeug unterstützt Autoren dabei, gängige Konventionen und Standards einzuhalten und die Qualität des eigenen Codes auf einem Mindest-Niveau zu halten
Ansible Lint bietet mehrere Profile für verschiedene Anwendungsfälle
Regeln können bei Bedarf ignoriert werden, was zwar das Ergebnis des Linting beeinflusst, die Qualität jedoch nicht steigert
Linting sollte fester Bestandteil des eigenen Entwicklungsworkflows sein und stets nach Änderungen durchgeführt werden
Ich persönlich führe ansible-lint gern in einem eigenständigen Schritt aus. Es besteht jedoch auch die Möglichkeit, dies in den verwendeten Editor, die genutzte IDE oder Molecule zu integrieren und bei Änderungen automatisch laufen zu lassen.
Ich freue mich, wenn euch dieser Artikel gefallen hat.
Dies ist ein Erfahrungsbericht zur Migration meiner Ansible-Rolle „Nextcloud im Container“ in eine Ansible Collection. Er umfasst die Migration der bestehenden Rolle und die Ergänzung der neuen Collection um eine weitere Rolle, welche sich um die Aufgaben Backup und Restore kümmert.
Wer es ganz eilig hat, kann direkt zur Zusammenfassung springen. Allen anderen wünsche ich viel Spaß bei der Lektüre.
Für grundlegende Informationen zu Ansible Collections siehe:
Randnotiz: Dass ihr zu meiner ersten Ansible Collection hier im Blog nicht fündig werdet, liegt darin begründet, dass meine Arbeit daran eingeschlafen ist.
Wie ihr in Teil 5 der Artikel-Serie nachlesen könnt, war ich mit der Lösung für Backup und Restore nicht ganz zufrieden. Ich möchte dieses Thema erneut angehen und mithilfe einer Ansible-Rolle lösen.
Backup und Restore beschreiben jedoch andere Anwendungsfälle als die Bereitstellung, weswegen ich den dafür notwendigen Quelltext nicht mit in die bestehende Rolle pressen möchte. Da Backup und Restore für mich jedoch zum Betrieb dazugehören, möchte ich alle Ansible-Rollen, die ich zum Betrieb meines Nextcloud-Setups benötige, in einer Collection zusammenfassen.
Migration der bestehenden Rolle in eine Collection
Ich orientiere mich hierzu an der englischsprachigen Dokumentation „Migrating a role to a collection“. Da ich bereits einen Galaxy Namespace besitze, nutze ich diesen auch für die Erstellung der Collection. Der folgende Codeblock zeigt die verwendeten Befehle.
]$ ansible-galaxy collection init tronde.nextcloud
- Collection tronde.nextcloud was created successfully
]$ mkdir tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod && rsync -a ../roles/ansible_role_deploy_nextcloud_with_mariadb_pod/ tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/
]$ tree -L 3 tronde/nextcloud/
tronde/nextcloud/
├── docs
├── galaxy.yml
├── meta
│ └── runtime.yml
├── plugins
│ └── README.md
├── README.md
└── roles
└── deploy_nextcloud_with_mariadb_pod
├── defaults
├── meta
├── README.md
├── tasks
├── tests
└── vars
]$ rm -rf tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/.git
Im letzten Schritt entferne ich das .git-Verzeichnis, da ich die Collection als Ganzes in einem Repository verwalten möchte, statt alle Rollen einzeln zu versionieren und dann in die Collection einzufügen.
Anschließend aktualisiere ich die Dateien galaxy.yml und README.md. In der Rolle habe ich ein Playbook zum Testen verwendet, welches im Pfad deploy_nextcloud_with_mariadb_pod/tests/test.yml liegt. Um konform mit der Struktur einer Ansible Collection zu sein, erstelle ich im Wurzelverzeichnis meiner Collection das Verzeichnis playbooks und kopiere das Test-Playbook hier hinein:
]$ tree playbooks/
playbooks/
└── deploy_nextcloud_with_mariadb_pod.yml
An dieser Stelle halte ich zunächst inne und überlege mir, welche Tools ich noch benötige, um meine Collection entwickeln und testen zu können.
Ansible Development Tools
Ansible Development Tools (ADT) ist ein Projekt mit dem Ziel, einen Werkzeugkasten mit allen wichtigen Werkzeugen zur Entwicklung von Ansible Content zu bieten. Genau so etwas habe ich gesucht. Das probiere ich gleich aus.
Um mir mein System nicht zu verhunzen, installiere ich die ADT in ein Python Virtual Environment und lasse mir anzeigen, welche Werkzeuge ADT mitbringt:
Bei molecule-podman handelt es sich um einen Molecule-Treiber, welcher benötigt wird um Molecule-Tests in Podman-Containern ausführen zu können. Ich habe dieses Paket mitinstalliert, da ich mir vorstellen kann, dies in naher Zukunft zu nutzen.
ansible-lint
Ansible Lint ist das erste Werkzeug aus der ADT-Sammlung, welches ich verwende, um den Quelltext meiner Collection zu prüfen. Dazu wird das Kommando einfach im Wurzelverzeichnis der Collection ausgeführt. Anschließend können die gefundenen Fehler behoben werden.
Da es den Rahmen dieses Artikels sprengen würde, werde ich dem Thema einen eigenen Text widmen.
molecule
Ansible Molecule eignet sich zum Testen von Ansible-Rollen und Collections. Ich nutze meine Ansible Collection, um mich mit diesem Werkzeug vertraut zu machen.
Zwar gibt es auch hier erst eine Lernkurve, doch wird mir eine durchdachte Test-Konfiguration bei der weiteren Entwicklung sicher zugutekommen. Ich orientiere mich zu Beginn am Ansible Molecule Getting Started Guide.
Zu Beginn möchte ich meine in die Collection migrierte Rolle testen. Dazu bearbeite ich die Datei tronde/nextcloud/extensions/molecule/default/converge.yml. Sie enthält schließlich folgenden Inhalt:
Und mit folgendem Befehl teste ich, ob meine Nextcloud-Instanz erfolgreich deployt wird:
extensions]$ molecule converge
…
PLAY RECAP *********************************************************************
localhost : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
extensions]$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
48438d1bd884 quay.io/centos/centos:stream8 bash -c while tru... 7 minutes ago Up 7 minutes instance
104c525a6b50 localhost/podman-pause:5.1.1-1717459200 About a minute ago Up About a minute 127.0.0.1:40671->80/tcp e34ddf4d4203-infra
f27842b12d56 docker.io/library/mariadb:10.11.2 mariadbd About a minute ago Up About a minute 127.0.0.1:40671->80/tcp nc_mariadb
9ee391a57fbd docker.io/library/nextcloud:25-apache apache2-foregroun... 13 seconds ago Up 13 seconds 127.0.0.1:40671->80/tcp nextcloud
Das Ergebnis ist positiv und kann durch Aufruf von http://127.0.0.1:40671 im Webbrowser überprüft werden. Ein Login mit den Default-Werten aus tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml bestätigt das erfolgreiche Deployment.
Es handelt sich hierbei noch nicht um ein adäquates Test-Setup; doch für den Moment ist es ausreichend. Ich werde mich noch weiter einarbeiten müssen, um das Test-Setup verbessern zu können. Vermutlich wird auch dazu dann ein weiterer Artikel folgen.
Falls sich jemand wundert, es ist durchaus Absicht, dass die Nextcloud nur via 127.0.0.1 und per HTTP erreichbar ist. Ich betreibe diese hinter einem Reverse-Proxy. Details können in Nextcloud im Container — Teil 3: Mit Reverse-Proxy nachgelesen werden.
Backup und Restore für die Nextcloud
Um die Konfiguration und die in der Nextcloud gespeicherten Daten sichern und wiederherstellen zu können, werde ich eine Offline-Sicherung der verwendeten Podman Volumes durchführen. Der Ablauf für die Sicherung sieht wie folgt aus:
Den Pod ˋnc_podˋ inkl. aller darin enthaltenen Container stoppen
Alle zum Setup gehörenden Podman Volumes in Tarballs exportieren
Diese Tarballs vom managed Node auf den Control Node sichern
Den ˋnc_podˋ wieder starten
Die Wiederherstellung läuft sinngemäß andersherum ab:
Die Tarballs werden vom Control Node auf den Managed Node kopiert
Der Pod ˋnc_podˋ inkl. aller darin enthaltenen Container wird gestoppt
Die Podman Volumes aus Schritt 1 werden importiert
Der nc_pod wird wieder gestartet
Die zur Wiederherstellung auf den Managed Node kopierten Tarballs werden wieder entfernt
Um diese neue Rolle der Collection hinzuzufügen, navigiere ich in das Rollenverzeichnis tronde/nextcloud/roles/ und erstelle dort das Grundgerüst für die Rolle: ansible-galaxy role init backup_nextcloud
Die Struktur sieht bei mir wie folgt aus, wobei nicht benötigte Verzeichnisse noch nicht entfernt wurden:
Das dortige README.md enthält wie bei dedizierten Rollen die Dokumentation zu dieser Rolle. Um doppelte Texte zu vermeiden, verweise ich im Collection-README auf die jeweiligen README-Dateien in den einzelnen Rollen.
Getestet wird diese Rolle ebenfalls mit Molecule. Zu den Tests mit Molecule werde ich noch mehr schreiben, sobald ich dies etwas verfeinert habe.
Fallen mir noch weitere Anwendungsfälle ein, können diese nun einfach als weitere Rollen der Collection hinzugefügt werden.
Ansible-Variablen definieren
Jede Rolle in dieser Collection ist für sich alleine nutzbar. Somit definiert jede Rolle die Eingangs-Variablen in der defaults/main.yml der jeweiligen Rolle.
Bei der Entwicklung achte ich darauf, dass Variablen, die z.B. den Namen eines Podman Volumes enthalten, in allen Rollen gleich geschrieben werden. Damit ist es möglich, diese Variablen an anderer Stelle zu definieren und in den verschiedenen Rollen nutzbar zu machen. So können an individuelle Deployments angepasste Variablen in Playbooks, group_vars, host_vars, etc. definiert werden.
Weitere Rollen können der Collection hinzugefügt werden, indem man sie im Verzeichnis roles der Collection-Verzeichnisstruktur wie gewohnt mit ansible-galaxy role init <Rollenname> erstellt und mit Leben füllt. Sorgfalt ist und bleibt bei der Benennung von Variablen und deren Präzedenz geboten, um nicht wahnsinnig zu werden. Dies ist nicht wirklich schwierig, doch muss ich fast jedes Mal in der Dokumentation nachschlagen, um sicher zu sein.
Die Ansible Development Tools (ADT) sind eine praktische Sammlung von Werkzeugen zur Entwicklung von Rollen und Collections für Ansible. Für mich sind aktuell Ansible Lint und Ansible Molecule die wichtigsten Werkzeuge aus dieser Sammlung. Wobei gerade die Dokumentation von Molecule auf dem Weg zu meinem Ziel, nämlich meine Collections in verschiedenen rootless Podman Containern mit nested Podman und Ansible zu testen, leider viele Fragen offen lässt. Grundsätzlich lassen sich Testpläne damit realisieren und vereinfachen mein bisheriges Testsetup bestehend aus diversen Skripts und virtuellen Maschinen. Und sie bieten Stoff für weitere Einträge in diesem Blog.
Die weitere Entwicklung meiner Nextcloud Collection findet auf Codeberg statt. Ihr findet sie dort unter der URL: https://codeberg.org/Tronde/nextcloud
Heute möchte ich euch wissen lassen, welche Kombination es geworden ist.
Die Hardware
Ich habe mich für ein wiederaufbereitetes Lenovo T570 entschieden, welches für günstige 240 Euro im Onlinehandel verfügbar war. Da war dann auch noch für 30 Euro ein Schutzbrief drin, der Flüssigkeiten und Stürze abdeckt.
Mit dem Intel Core-i5 der 6. Generation, 8 GB RAM und einer 256 GB SSD bietet dieses Gerät mehr als ausreichend Leistung.
Das Gerät weist einige Gebrauchsspuren auf. Den Preis empfinde ich dennoch günstig, da Geräte dieser Klasse nicht unter 1.000 Euro Neupreis zu bekommen sind. Viel wichtiger jedoch ist, dass der Nutzer sich ebenfalls über das Gerät freut.
Linux-Distribution und Desktopumgebung
Wer die Wahl hat, hat die Qual. Um mir einen ersten Eindruck zu verschaffen, habe ich mir einen USB-Stick mit Ventoy und einer Auswahl an verschiedenen Linux-Distributionen erstellt. So konnte ich die verschiedenen Live-Systeme booten und prüfen, ob alles funktioniert und wie es sich in der Oberfläche navigieren lässt.
Schlussendlich habe ich mich für Debian Cinnamon entschieden. Dies machte nach dem ersten kurzen Test insgesamt den besten Eindruck. Firefox, Thunderbird, Bookmarks, Desktop-Verknüpfungen und Zoom-Client waren schnell eingerichtet und das Gerät bereit zur Übergabe.
Die Übergabe ist erfolgt
Mit der Übergabe gab es eine kurze Einweisung in das Gerät:
Wo schließt man das Netzteil an
Wo schaltet man das Gerät ein
Wie meldet man sich an
Wo findet man die Programme inkl. Tests aller wichtigen Dienste
Druck eines Anhangs aus Thunderbird
Wie fährt man das Gerät herunter
So reibungslos hat das bisher noch nie geklappt. Die Nutzungserfahrung ist positiv. Wir freuen uns.
In diesem Überblick beschreibe ich am Beispiel der Proxmox inventory source, wie eine eigene Inventory Source im Ansible Automation Controller hinzugefügt werden kann.
Die folgenden Schritte wurden mit der Ansible Automation Platform 2.4 getestet. Die einzelnen Schritte sollten in gleicher Weise auch in Ansible AWX ausgeführt werden können.
Um diesem Text folgen zu können, werden Kenntnisse im Umgang mit Ansible und Git auf der Kommandozeile vorausgesetzt.
Der Text verweist, wo möglich, auf bestehende Dokumentation. Es handelt sich bei diesem Text nicht um ein klassisches Tutorial. Er dient mir als Gedächtnisstütze und mag euch eine Anregung sein, bzw. im besten Fall die Wissenslücken schließen, die sich mit der Dokumentation allein nicht schließen lassen.
Für das Beispiel in diesem Text werden Hosts aus der Bestandsliste eines PVE als Inventory Source hinzugefügt. Die dabei verwendete Vorgehensweise kann auch für andere Inventory Plugins verwendet werden. Die Entwicklung von Inventory Plugins ist jedoch nicht Gegenstand dieses Textes. Hierzu wird auf die Dokumentation unter „Developing dynamic inventory“ verwiesen.
Mein Kollege Steffen Scheib hat mir geholfen, das Proxmox-Plugin zu konfigurieren, wofür ich ihm an dieser Stelle nochmal ganz herzlich danke. Es liegt auf meiner Arbeitsstation als Ansible Project in folgender Verzeichnisstruktur vor:
Mit Ausnahme der Datei vault_password_file wurden alle Dateien und Verzeichnisse in Git aufgenommen. Ich verwende einen einfachen Git-Server in meiner Laborumgebung, auf welchen ich meine lokalen Repositorys pushe. Der Automation Controller synchronisiert das Projekt aus dem Git-Repo, um es als Inventory Source verfügbar zu machen.
Das Proxmox Inventory Plugin befindet sich in einem Git-Repository, auf welches mit SSH-Key-Authentifizierung zugegriffen werden kann. Damit auch der Automation Controller auf dieses Repository zugreifen kann, wird ein Credential vom Typ Source Control erstellt.
Beipsiel für einen Source Control Credential Typ im Ansible Automation Controller
Der SSH-Private-Key wurde von meinem Host hochgeladen und verschlüsselt im Automation Controller gespeichert. Der Key lässt sich in der GUI nicht wieder sichtbar machen, lediglich ersetzen.
Die Datei vault_password_file befindet sich jedoch nicht im Git, da sie das Passwort im Klartext enthält. Aus diesem Grund möchte ich die Datei auch nicht auf dem Automation Controller ablegen. Irgendwie müssen auf dem Automation Controller jedoch Credentials hinterlegt werden, um die Ansible Vault encrypted_strings zu entschlüsseln. Die Lösung steckt in diesem Kommentar auf Github. Im Automation Controller User Guide gibt es dazu Chapter 11. Custom credential types.
Das Schlüssel-Wert-Paar secret: true stellt sicher, dass das Passwort verschlüsselt gespeichert wird. Es kann danach im Automation Controller nicht mehr im Klartext angezeigt werden. Nachdem der neue Credential Typ erstellt ist, kann dieser instanziiert werden:
Beispiel des neuen Custom Credential Typs ‚encrypted_vault_password‘
Das Vault Passwort wird in das entsprechende Formularfeld kopiert. Es ist standardmäßig nicht sichtbar und wird wie oben bereits erwähnt, verschlüsselt gespeichert. Mit diesem Credential verfügt der Automation Controller nun über die notwendigen Informationen, um das Proxmox Inventory auszulesen.
In diesem Beitrag gebe ich einige Beispiele mit Erklärungen zu Ansible Conditionals, welche mir in der Dokumentation fehlen. Dieser Artikel dient mir zur Erinnerung und mag Einsteigern helfen, ein besseres Verständnis der Bedingung is defined zu gewinnen.
Wird in einem Task eine Variable verwendet, welche nicht definiert ist, bricht Ansible die Verarbeitung eines Playbooks mit einem Fehler ab. Der folgende Code-Block zeigt ein einfaches Playbook mit anschließender Ausgabe des Playbooklaufs, um dies zu verdeutlichen. Der Task beinhaltet dabei bereits eine Bedingung. Er soll nur dann ausgeführt werden, wenn die Variable my_var den Wert Hello world! enthält.
]$ cat test_conditionals.yml
---
- name: Play around with conditionals
hosts: localhost
gather_facts: false
tasks:
- name: >-
When all conditionals are met, print the variable value using
ansible.builtin.debug
when:
- my_var == "Hello world!"
ansible.builtin.debug:
var: my_var
]$ ansible-playbook -i hosts test_conditionals.yml
PLAY [Play around with conditionals] *******************************************
TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
fatal: [localhost]: FAILED! => {"msg": "The conditional check 'my_var == \"Hello world!\"' failed. The error was: error while evaluating conditional (my_var == \"Hello world!\"): 'my_var' is undefined. 'my_var' is undefined\n\nThe error appears to be in '/home/tronde/ansible/test_conditionals.yml': line 7, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n tasks:\n - name: >-\n ^ here\n"}
PLAY RECAP *********************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
Der Text 'my_var' is undefined in obiger Fehlerausgabe benennt den Grund des Scheiterns.
Nun gibt es Fälle, in denen Tasks, welche undefinierte Variablen enthalten, nicht zum Abbruch des gesamten Playbooks führen sollen. Stattdessen soll der betroffene Task einfach übersprungen werden. Dies erreicht man mit der Bedingung `is defined`. Der nächste Code-Block liefert wieder ein Beispiel dazu.
]$ cat test_conditionals.yml
---
- name: Play around with conditionals
hosts: localhost
gather_facts: false
tasks:
- name: >-
When all conditionals are met, print the variable value using
ansible.builtin.debug
when:
- my_var is defined
- my_var == "Hello world!"
ansible.builtin.debug:
var: my_var
]$ ansible-playbook -i hosts test_conditionals.yml
PLAY [Play around with conditionals] *******************************************
TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
skipping: [localhost]
PLAY RECAP *********************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
Der Task mit der undefinierten Variable wurde übersprungen (skipped) und das Playbook erfolgreich beendet.
Im nächsten Beispiel habe ich die Variable my_var im Playbook definiert und den passenden Wert zugewiesen.
]$ cat test_conditionals.yml
---
- name: Play around with conditionals
hosts: localhost
gather_facts: false
vars:
my_var: Hello world!
tasks:
- name: >-
When all conditionals are met, print the variable value using
ansible.builtin.debug
when:
- my_var is defined
- my_var == "Hello world!"
ansible.builtin.debug:
var: my_var
]$ ansible-playbook -i hosts test_conditionals.yml
PLAY [Play around with conditionals] *******************************************
TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
ok: [localhost] => {
"my_var": "Hello world!"
}
PLAY RECAP *********************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Das war auch schon alles für heute. Ihr seht, es ist keine Hexerei. Mir hilft es, die Bedeutung von is defined zu erinnern, wenn ich es einmal aufgeschrieben habe.
Zum Ende gibt es noch einen Code-Block, der zeigt, dass dies auch mit Dictionaries funktioniert:
]$ cat test_conditionals.yml
---
- name: Play around with conditionals
hosts: localhost
gather_facts: false
vars:
my_dict:
my_var: Hello world!
tasks:
- name: >-
When all conditionals are met, print the variable value using
ansible.builtin.debug
when:
- my_dict.my_var is defined
- my_dict.my_var == "Hello world!"
ansible.builtin.debug:
var: my_dict.my_var
]$ ansible-playbook -i hosts test_conditionals.yml
PLAY [Play around with conditionals] *******************************************
TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
ok: [localhost] => {
"my_dict.my_var": "Hello world!"
}
PLAY RECAP *********************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
In der Kategorie Ansible findet ihr weitere Artikel rund um Ansible. Viel Spaß beim Stöbern.
Und in diesem Text möchte ich euch mitteilen, welche Faktoren zu meiner Zufriedenheit beitragen.
Seit März 2023 arbeite ich als Senior Technical Account Manager (TAM) bei Red Hat. In diesem Artikel habe ich beschrieben, wie eine Arbeitswoche für mich aussehen kann.
Doch was gefällt mir nun so sehr an diesem Job?
Ich arbeite full remote. Dies passt aktuell am besten zu meinen Lebensumständen. Hier findet sich ein Erfahrungsbericht dazu.
Dass ich nicht mehr pendeln muss, gibt mir mehr Zeit für die Familie und schont die Umwelt.
Unser gesamtes Team arbeitet full remote und alle beherrschen unsere Tools, sodass die Zusammenarbeit reibungslos klappt.
Wir haben eine tolle Unternehmenskultur und ich fühlte mich selten von so hilfsbereiten Menschen umgeben.
Diese Kultur motiviert mich, mich selbst stets einzubringen und zu unterstützen, wo ich kann.
Wir haben anspruchsvolle Ziele und stets mehr als genug zu tun. Dennoch nehmen wir uns stets die Zeit einander zu helfen, unser Wissen zu teilen.
Wenn jemand mal nicht direkt helfen kann, wird man nicht mit Sätzen wie: „Dafür bin ich nicht zuständig.“ oder „Da kenne ich mich selbst nicht mit aus.“ abgespeist. Bei uns hört man dann eher:
„Da kann ich dir leider nicht direkt helfen, aber versuch es mal bei XY, die haben mir schonmal in einer ähnlichen Angelegenheit geholfen.“
Oder die Anfrage wird direkt an das richtige Team weitergeleitet
Wir sind in unserer Arbeitsweise sehr frei. Es gibt kein Mikromanagement. Unser aller Ziel ist, unseren Enterprise-Kunden eine gute Erfahrung zu bescheren. Natürlich gibt es Leitlinien, die einen Rahmen vorgeben. Diese empfinde ich nicht als Einschränkung, sondern als richtungsweisend.
Im Zweifel haben wir das gemeinschaftlich gepflegte TAM Manual, das uns erklärt, wie was gemacht wird.
Wir ziehen Besprechungen nicht in die Länge. Wenn wir fertig sind, hören wir einfach auf. Selbst dann, wenn die Zeit noch nicht vorbei ist.
Natürlich gibt es auch bei Red Hat genug Dinge, die verbessert werden können bzw. sollten. Doch konzentriere ich mich hier bewusst auf die Punkte, die zu meiner Zufriedenheit führen, um mich daran zu erfreuen.
Die obigen Punkte beziehen sich nicht ausschließlich auf mein eigenes Team. Ich erlebe dies regelmäßig auch teamübergreifend. Das ist eine tolle Erfahrung.
Mein Tipp für euch: Denkt nicht immer nur an Dinge, die euch nicht gefallen. Macht euch aktiv der Dinge bewusst, die euch gefallen und motivieren. Ihr werdet evtl. erstaunt sein, wie viel Energie ihr draus schöpfen könnt. Mich hat bspw. die Methode Journaling dabei unterstützt, zu einem positiven Mindset zu finden.
Was gefällt euch besonders an eurem Job? Teilt eure Gedanken und Erfahrungen gerne mit uns.
Liebe Leser*innen, heute seid ihr gefragt. Denn ich möchte von euch wissen, welchen Laptop und welche Linux-Distribution, ihr für ältere, nicht EDV-affine Menschen und Windows-Umsteiger empfehlen könnt.
Hardware
Der Laptop soll über folgende Merkmale verfügen:
Größe: 15-17 Zoll
Webcam
Mikrofon und Lautsprecher
für Videokonferenzen
zum Schauen von Videos in sozialen Netzwerken
Linux- und Windows-Unterstützung
Die Unterstützung von Linux und Windows ist sehr wichtig. Sollte der Feldversuch mit Linux scheitern, möchte auf der gleichen Hardware ein aktuelles Windows-Betriebssystem installieren können.
Mir schwebt etwas in der Richtung der Lenovo IdeaPad oder ein ThinkPad der L-Serie vor, ich bin jedoch auf eure Empfehlungen gespannt.
Desktop-Umgebung
Ich suche nach einer Desktop-Umgebung, die folgende Merkmale bietet:
Ein Startmenü, welches sich in der unteren linken Ecke befindet
Erstellungen von Anwendungsstartern und Verknüpfungen auf der Desktopoberfläche
Dies sind Muss-Kriterien, die unbedingt erfüllt sein müssen. Ich möchte, dass die Desktopoberfläche diese Eigenschaften in der Standardkonfiguration erfüllt und ich diese nicht erst konfigurieren oder drölfzig Plug-ins installieren muss, um diesen Zustand zu erreichen.
Software
Die wichtigsten Anwendungen sind:
Thunderbird für E-Mail
Aktuelle Webbrowser (Chrome/Firefox) für den Rest
Facebook
YouTube
Zoom, MS Teams, Webex und wie sie alle heißen
Ein PDF-Anzeigeprogramm
Libre/Open Office zum Lesen von MS Office-Dokumenten
Linux-Distribution
Die Linux-Distribution muss die oben genannten Anforderungen an die Desktop-Umgebung und die Software erfüllen und dabei stabil allerdings nicht steinalt sein.
Ich möchte nicht vor jeder Videokonferenz mit den Audio-Einstellungen kämpfen müssen, um deutlich zu machen, wo meine Priorität liegt.
Das Training auf einer virtuellen Maschine mit Fedora 40 Server, 10 CPU-Threads und 32 GB RAM dauerte 180 Std. 44 Min. 7 Sek. Ich halte an dieser Stelle fest, ohne GPU-Beschleunigung fehlt es mir persönlich an Geduld. So macht das Training keinen Spaß.
Nach dem Training mit ilab train findet man ein brandneues LLM auf dem eigenen System:
(venv) tronde@instructlab:~/src/instructlab$ ls -ltrh models
total 18G
-rw-r--r--. 1 tronde tronde 4.1G May 28 20:34 merlinite-7b-lab-Q4_K_M.gguf
-rw-r--r--. 1 tronde tronde 14G Jun 6 12:07 ggml-model-f16.gguf
Test des neuen Modells
Den Chat mit dem LLM starte ich mit dem Befehl ilab chat -m models/ggml-model-f16.gguf. Das folgende Bild zeigt zwei Chats mit jeweils unterschiedlichem Ergebnis:
Zwei Chats mit dem frisch trainierten LLM. Beide Male erhalte ich nicht die erhoffte Antwort.
Fazit
Schade, das hat nicht so funktioniert, wie ich mir das vorgestellt habe. Es kommt weiterhin zu KI-Halluzinationen und nur gelegentlich gesteht das LLM seine Unkenntnis bzw. seine Unsicherheit ein.
Für mich sind damit 180 Stunden Rechenzeit verschwendet. Ich werde bis auf Weiteres keine Trainings ohne Beschleuniger-Karten mehr durchführen. Jedoch werde ich mir von Zeit zu Zeit aktualisierte Releases der verfügbaren Modelle herunterladen und diesen Fragen stellen, deren Antworten ich bereits kenne.
Wenn sich mir die Gelegenheit bietet, diesen Versuch auf einem Rechner mit entsprechender GPU-Hardware zu wiederholen, werde ich die Erkenntnisse hier im Blog teilen.
Dies ist mein Erfahrungsbericht zu den ersten Schritten mit InstructLab. Ich gehe darauf ein, warum ich mich über die Existenz dieses Open Source-Projekts freue, was ich damit mache und was ich mir von Large Language Models (kurz: LLMs, zu Deutsch: große Sprachmodelle) erhoffe. Der Text enthält Links zu tiefergehenden Informationen, die euch mit Hintergrundwissen versorgen und einen Einstieg in das Thema ermöglichen.
Dieser Text ist keine Schritt-für-Schritt-Anleitung für:
Beim Bezug auf große Sprachmodelle bediene ich mich der englischen Abkürzung LLM oder bezeichne diese als KI-ChatBot bzw. nur ChatBot.
Was ist InstructLab?
InstructLab ist ein von IBM und Red Hat ins Leben gerufenes Open Source-Projekt, mit dem die Gemeinschaft zur Verbesserung von LLMs beitragen kann. Jeder
Hugging Face. The AI community building the future. The platform where the machine learning community collaborates on models, datasets, and applications. URL: https://huggingface.co/
Meine Einstellung gegenüber KI-ChatBots
Gegenüber KI-Produkten im Allgemeinen und KI-ChatBots im Speziellen bin ich stets kritisch, was nicht bedeutet, dass ich diese Technologien und auf ihnen basierende Produkte und Services ablehne. Ich versuche mir lediglich eine gesunde Skepsis zu bewahren.
Was Spielereien mit ChatBots betrifft, bin ich sicherlich spät dran. Ich habe schlicht keine Lust, mich irgendwo zu registrieren und unnötig Informationen über mich preiszugeben, nur um anschließend mit einer Büchse chatten und ihr Fragen stellen zu können, um den Wahrheitsgehalt der Antworten anschließend noch verifizieren zu müssen.
Mittlerweile gibt es LLMs, welche ohne spezielle Hardware auch lokal ausgeführt werden können. Diese sprechen meine Neugier und meinen Spieltrieb schon eher an, weswegen ich mich nun doch mit einem ChatBot unterhalten möchte.
Der lokale LLM-Server wird mit dem Befehl ilab serve gestartet. Mit dem Befehl ilab chat wird die Unterhaltung mit dem Modell eingeleitet.
Im folgenden Video sende ich zwei Anweisungen an das LLM merlinite-7b-lab-Q4_K_M. Den Chatverlauf seht ihr in der rechten Bildhälfte. In der linken Bildhälfte seht ihr die Ressourcenauslastung meines Laptops.
Screencast eines Chats mit merlinite-7b-lab-Q4_K_M
Wie ihr seht, sind die Antwortzeiten des LLM auf meinem Laptop nicht gerade schnell, aber auch nicht so langsam, dass ich währenddessen einschlafe oder das Interesse an der Antwort verliere. An der CPU-Auslastung im Cockpit auf der linken Seite lässt sich erkennen, dass das LLM durchaus Leistung abruft und die CPU fordert.
Mit den Antworten des LLM bin ich zufrieden. Sie decken sich mit meiner Erinnerung und ein kurzer Blick auf die Seite https://www.json.org/json-de.html bestätigt, dass die Aussagen des LLM korrekt sind.
Anmerkung: Der direkte Aufruf der Seite https://json.org, der mich mittels Redirect zu obiger URL führte, hat sicher deutlich weniger Energie verbraucht als das LLM oder eine Suchanfrage in irgendeiner Suchmaschine. Ich merke dies nur an, da ich den Eindruck habe, dass es aus der Mode zu geraten scheint, URLs einfach direkt in die Adresszeile eines Webbrowsers einzugeben, statt den Seitennamen in eine Suchmaske zu tippen.
Ich halte an dieser Stelle fest, der erste kleine Test wird zufriedenstellend absolviert.
KI-Halluzinationen
Da ich einige Zeit im Hochschulrechenzentrum der Universität Bielefeld gearbeitet habe, interessiert mich, was das LLM über meine ehemalige Dienststelle weiß. Im nächsten Video frage ich, wer der Kanzler der Universität Bielefeld ist.
Frage an das LLM: „Who is the chancellor of the Bielefeld University?“
Da ich bis März 2023 selbst an der Universität Bielefeld beschäftigt war, kann ich mit hinreichender Sicherheit sagen, dass diese Antwort falsch ist und das Amt des Kanzlers nicht von Prof. Dr. Karin Vollmerd bekleidet wird. Im Personen- und Einrichtungsverzeichnis (PEVZ) findet sich für Prof. Dr. Vollmerd keinerlei Eintrag. Für den aktuellen Kanzler Dr. Stephan Becker hingegen schon.
Da eine kurze Recherche in der Suchmaschine meines geringsten Misstrauens keine Treffer zu Frau Vollmerd brachte, bezweifle ich, dass diese Person überhaupt existiert. Es kann allerdings auch in meinen unzureichenden Fähigkeiten der Internetsuche begründet liegen.
Bei der vorliegenden Antwort handelt es sich um eine Halluzination der Künstlichen Intelligenz.
Im Bereich der Künstlichen Intelligenz (KI) ist eine Halluzination (alternativ auch Konfabulation genannt) ein überzeugend formuliertes Resultat einer KI, das nicht durch Trainingsdaten gerechtfertigt zu sein scheint und objektiv falsch sein kann.
Solche Phänomene werden in Analogie zum Phänomen der Halluzination in der menschlichen Psychologie als von Chatbots erzeugte KI-Halluzinationen bezeichnet. Ein wichtiger Unterschied ist, dass menschliche Halluzinationen meist auf falschen Wahrnehmungen der menschlichen Sinne beruhen, während eine KI-Halluzination ungerechtfertigte Resultate als Text oder Bild erzeugt. Prabhakar Raghavan, Leiter von Google Search, beschrieb Halluzinationen von Chatbots als überzeugend formulierte, aber weitgehend erfundene Resultate.
Oder wie ich es umschreiben möchte: „Der KI-ChatBot demonstriert sichereres Auftreten bei völliger Ahnungslosigkeit.“
Wenn ihr selbst schon mit ChatBots experimentiert habt, werdet ihr sicher selbst schon auf Halluzinationen gestoßen sein. Wenn ihr mögt, teilt doch eure Erfahrungen, besonders jene, die euch fast aufs Glatteis geführt haben, in den Kommentaren mit uns.
Welche Auswirkungen überzeugend vorgetragene Falschmeldungen auf Nutzer haben, welche nicht über das Wissen verfügen, diese Halluzinationen sofort als solche zu entlarven, möchte ich für den Moment eurer Fantasie überlassen.
Ich denke an Fahrplanauskünfte, medizinische Diagnosen, Rezepturen, Risikoeinschätzungen, etc. und bin plötzlich doch ganz froh, dass sich die EU-Staaten auf ein erstes KI-Gesetz einigen konnten, um KI zu regulieren. Es wird sicher nicht das letzte sein.
Um das Beispiel noch etwas auszuführen, frage ich das LLM erneut nach dem Kanzler der Universität und weise es auf seine Falschaussagen hin. Der Chatverlauf ist in diesem Video zu sehen:
ChatBot wird auf Falschaussage hingewiesen
Die Antworten des LLM enthalten folgende Fehler:
Professor Dr. Ulrich Heidt ist nicht der Kanzler der Universität Bielefeld
Die URL ‚https://www.uni-bielefeld.de/english/staff/‘ existiert nicht
Die URL ‚http://www.universitaet-bielefeld.de/en/‘ existiert ebenfalls nicht
Die Universität hieß niemals „Technische Universitaet Braunschweig“
Der Chatverlauf erweckt den Eindruck, dass der ChatBot sich zu rechtfertigen versucht und nach Erklärungen und Ausflüchten sucht. Hier wird nach meinem Eindruck menschliches Verhalten nachgeahmt. Dabei sollten wir Dinge nicht vermenschlichen. Denn unser Chatpartner ist kein Mensch. Er ist eine leblose Blechbüchse. Das LLM belügt uns auch nicht in böser Absicht, es ist schlicht nicht in der Lage, uns eine korrekte Antwort zu liefern, da ihm dazu das nötige Wissen bzw. der notwendige Datensatz fehlt. Daher versuche ich im nächsten Schritt, dem LLM mit InstructLab das notwendige Wissen zu vermitteln.
Wissen und Fähigkeiten hinzufügen und das Modell anlernen
Das README.md im Repository instructlab/taxonomy enthält die Beschreibung, wie man dem LLM Wissen (englisch: knowledge) hinzufügt. Weitere Hinweise finden sich in folgenden Dateien:
Diese Dateien befinden sich auch in dem lokalen Repository unterhalb von ~/instructlab/taxonomy/. Ich hangel mich an den Leitfäden entlang, um zu sehen, wie weit ich damit komme.
Wissen erschaffen
Die Überschrift ist natürlich maßlos übertrieben. Ich stelle lediglich existierende Informationen in erwarteten Dateiformaten bereit, um das LLM damit trainieren zu können.
Da aktuell nur Wissensbeiträge von Wikipedia-Artikeln akzeptiert werden, gehe ich wie folgt vor:
Konvertiere den Wikipedia-Artikel Bielefeld University ohne Bilder und Tabellen in eine Markdown-Datei und füge sie dem in Schritt 1 erstellten Repository unter dem Namen unibi.md hinzu
Füge dem lokalen Taxonomy-Repository neue Verzeichnisse hinzu: mkdir -p university/germany/bielefeld_university
Erstelle in dem neuen Verzeichnis eine qna.yaml und eine attribution.txt Datei
Führe ilab diff aus, um die Daten zu validieren
Der folgende Code-Block zeigt den Inhalt der Dateien qna.yaml und eine attribution.txt sowie die Ausgabe des Kommandos ilab diff:
(venv) [tronde@t14s instructlab]$ cat /home/tronde/src/instructlab/taxonomy/knowledge/university/germany/bielefeld_university/qna.yaml
version: 2
task_description: 'Teach the model the who facts about Bielefeld University'
created_by: tronde
domain: university
seed_examples:
- question: Who is the chancellor of Bielefeld Universtiy?
answer: Dr. Stephan Becker is the chancellor of the Bielefeld University.
- question: When was the University founded?
answer: |
The Bielefeld Universtiy was founded in 1969.
- question: How many students study at Bielefeld University?
answer: |
In 2017 there were 24,255 students encrolled at Bielefeld Universtity?
- question: Do you know something about the Administrative staff?
answer: |
Yes, in 2017 the number for Administrative saff was published as 1,100.
- question: What is the number for Academic staff?
answer: |
In 2017 the number for Academic staff was 1,387.
document:
repo: https://github.com/Tronde/instructlab_knowledge_contributions_unibi.git
commit: c2d9117
patterns:
- unibi.md
(venv) [tronde@t14s instructlab]$
(venv) [tronde@t14s instructlab]$
(venv) [tronde@t14s instructlab]$ cat /home/tronde/src/instructlab/taxonomy/knowledge/university/germany/bielefeld_university/attribution.txt
Title of work: Bielefeld University
Link to work: https://en.wikipedia.org/wiki/Bielefeld_University
License of the work: CC-BY-SA-4.0
Creator names: Wikipedia Authors
(venv) [tronde@t14s instructlab]$
(venv) [tronde@t14s instructlab]$
(venv) [tronde@t14s instructlab]$ ilab diff
knowledge/university/germany/bielefeld_university/qna.yaml
Taxonomy in /taxonomy/ is valid :)
(venv) [tronde@t14s instructlab]$
Synthetische Daten generieren
Aus der im vorherigen Abschnitt erstellten Taxonomie generiere ich im nächsten Schritt synthetische Daten, welche in einem folgenden Schritt für das Training des LLM genutzt werden.
(venv) [tronde@t14s instructlab]$ ilab generate
[…]
INFO 2024-05-28 12:46:34,249 generate_data.py:565 101 instructions generated, 62 discarded due to format (see generated/discarded_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.log), 4 discarded due to rouge score
INFO 2024-05-28 12:46:34,249 generate_data.py:569 Generation took 12841.62s
(venv) [tronde@t14s instructlab]$ ls generated/
discarded_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.log
generated_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.json
test_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.jsonl
train_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.jsonl
Zur Laufzeit werden alle CPU-Threads voll ausgelastet. Auf meinem Laptop dauerte dieser Vorgang knapp 4 Stunden.
Das Training beginnt
Jetzt wird es Zeit, das LLM mit den synthetischen Daten anzulernen bzw. zu trainieren. Dieser Vorgang wird mehrere Stunden in Anspruch nehmen und ich verplane mein Laptop in dieser Zeit für keine weiteren Arbeiten.
Um möglichst viele Ressourcen freizugeben, beende ich das LLM (ilab serve und ilab chat). Das Training beginnt mit dem Befehl ilab train… und dauert wirklich lange.
Nach 2 von 101 Durchläufen wird die geschätzte Restlaufzeit mit 183 Stunden angegeben. Das Ergebnis spare ich mir dann wohl für einen Folgeartikel auf und gehe zum Fazit über.
Fazit
Mit dem InstructLab Getting Started Guide gelingt es in kurzer Zeit, das Projekt auf einem lokalen Linux-Rechner einzurichten, ein LLM auszuführen und mit diesem zu chatten.
KI-Halluzinationen stellen in meinen Augen ein Problem dar. Da LLMs überzeugend argumentieren, kann es Nutzern schwerfallen oder gar misslingen, die Falschaussagen als solche zu erkennen. Im schlimmsten Fall lernen Nutzer somit dummen Unfug und verbreiten diesen ggf. weiter. Dies ist allerdings kein Problem bzw. Fehler des InstructLab-Projekts, da alle LLMs in unterschiedlicher Ausprägung von KI-Halluzinationen betroffen sind.
Wie Knowledge und Skills hinzugefügt werden können, musste ich mir aus drei Guides anlesen. Dies ist kein Problem, doch kann der Leitfaden evtl. noch etwas verbessert werden.
Knowledge Contributions werden aktuell nur nach vorheriger Genehmigung und nur von Wikipedia-Quellen akzeptiert. Der Grund wird nicht klar kommuniziert, doch ich vermute, dass dies etwas mit geistigem Eigentum und Lizenzen zu tun hat. Wikipedia-Artikel stehen unter einer Creative Commons Attribution-ShareAlike 4.0 International License und können daher unkompliziert als Quelle verwendet werden. Da sich das Projekt in einem frühen Stadium befindet, kann ich diese Limitierung nachvollziehen. Ich wünsche mir, dass grundsätzlich auch Primärquellen wie Herstellerwebseiten und Publikationen zugelassen werden, wenn Rechteinhaber dies autorisieren.
Der von mir herangezogene Wikipedia-Artikel ist leider nicht ganz aktuell. Nutze ich ihn als Quelle für das Training eines LLM, bringe ich dem LLM damit veraltetes und nicht mehr gültiges Wissen bei. Das ist für meinen ersten Test unerheblich, für Beiträge zum Projekt jedoch nicht sinnvoll.
Die Generierung synthetischer Daten dauert auf Alltagshardware schon entsprechend lange, das anschließende Training jedoch nochmals bedeutend länger. Dies ist meiner Ansicht nach nichts, was man nebenbei auf seinem Laptop ausführt. Daher habe ich den Test auf meinem Laptop abgebrochen und lasse das Training aktuell auf einem Fedora 40 Server mit 32 GB RAM und 10 CPU-Kernen ausführen. Über das Ergebnis und einen Test des verbesserten Modells werde ich in einem folgenden Artikel berichten.
Was ist mit euch? Kennt ihr das Projekt InstructLab und habt evtl. schon damit gearbeitet? Wie sind eure Erfahrungen?
Arbeitet ihr mit LLMs? Wenn ja, nutzt ihr diese nur oder trainiert ihr sie auch? Was nutzt ihr für Hardware?
Ich freue mich, wenn ihr eure Erfahrungen hier mit uns teilt.
Ich bin in meiner Familie der Nerd. Ich kümmere mich um den Internetzugang, das WLAN, die Speicherung der Familienfotos, etc. Ja manchmal kümmere ich mich sogar um Drucker.
Meine Familie vertraut darauf, dass das Heimnetzwerk die meiste Zeit des Jahres reibungslos funktioniert. Und wenn dies nicht der Fall ist, ist es mein Job, die Sache wieder in Ordnung zu bringen.
Erkennt ihr euch in dieser Beschreibung wieder? Dann habe ich gleich noch weitere Fragen an euch.
Stellt euch vor, dass ihr eines Tages nicht mehr für eure Familie da sein könnt und eure Angehörigen plötzlich allein mit der IT-Umgebung zurechtkommen müssen, die ihr hinterlassen habt.
Wie bereitet ihr eure Familie auf diesen Fall vor?
Habt ihr mit euren Angehörigen mal über dieses Thema gesprochen?
Wie dokumentiert ihr euer Heimnetzwerk, sodass eure Angehörigen etwas mit der Dokumentation anfangen können?
Bitte teilt eure Erfahrungen und Ideen in den Kommentaren zu diesem Beitrag. Habt ihr selbst schon zu diesem Thema gebloggt? Dann teilt doch bitte den Link zu eurem Beitrag mit mir und den Leserinnen und Lesern dieses Blogs.
Gedanken zur Dokumentation
Die Dokumentation soll in ausgedruckter Form vorliegen, um auch bei einem Totalausfall des Heimnetzwerks nutzbar zu sein
Es ist eine leichtverständliche Sprache zu wählen, die ohne Fachchinesisch auskommt oder notwendige Fachbegriffe erklärt, damit auch Nicht-IT-Personal den Text verstehen und Anweisungen folgen kann
Hinzugezogenem IT-Support-Personal soll die Dokumentation ebenfalls nützlich sein
Die Gliederung orientiert sich an Anwendungsfällen der Nutzer; mögliche Überschriften sind
Wie kommt das Internet ins Haus?
Wie wird das Internet im Haus verteilt?
Wo finde ich unsere Fotos, Videos, Dokumente und digitalen Einkäufe?
Was kann ich tun, wenn
das Internet nicht geht
das WLAN nicht geht
das weiße Ding im Keller blinkt/piept
Gerade der Abschnitt zur Entstörung von IT-Komponenten wird sicherlich eine Herausforderung. Generationen von Supportern werden ein Lied davon singen können, doch es hilft ja nunmal alles nichts. Wir sind unseren Angehörigen diese Informationen schuldig, wollen wir sie nicht hilflos zurücklassen.
Für mich ist eine Dokumentation, mit der ein Mensch mit IT-Affinität arbeiten kann das Muss und Hinweise zur Entstörung für technische Laien die Kür.
Was denkt ihr?
Könnt ihr meinem Ansatz folgen?
Habe ich etwas vergessen?
Trennung von Heimlabor und Heimnetzwerk
Wie viele Nerds betreibe auch ich ein kleines Heimlabor. Beim Aufbau des Heimnetzwerks habe ich darauf geachtet, dass mein Heimlabor komplett abgeschaltet werden kann, ohne die Funktion des Heimnetzwerks und den Internetzugang negativ zu beeinflussen.
Dies ermöglicht es mir, in meinem Heimlabor häufige Änderungen durchführen zu können, ohne dass dadurch Änderungen an der Notfalldokumentation notwendig werden.
Frisch ans Werk
Dann werde ich mal ein Git-Repository im Heimnetzwerk erstellen und ein LaTeX-Dokument beginnen.
Ich freue mich, an dieser Stelle von euren Ideen und Vorgehensweisen zu lernen und das Thema mit euch zu diskutieren.
Dies ist der Folgeartikel, den ich in der Einführung in das Advanced Intrusion Detection Environment (AIDE) versprochen hatte. Es handelt sich hierbei um einen Proof of Concept (PoC), der zeigt, wie AIDE mithilfe einer Ansible-Rolle ferngesteuert werden kann. Die Einführung wird als bekannt vorausgesetzt.
Grundlegende Ansible-Kenntnisse, wie die Verwendung von Ansible-Rollen und das Ausführen von Playbooks werden ebenfalls als bekannt vorausgesetzt. Wer Ansible nicht kennt, sei an die offizielle Dokumentation verwiesen.
Welche Aufgaben sind mit Ansible zu lösen?
Das Paket aide ist auf den Zielsystemen installiert
Die optionale Generierung und Verteilung der Konfigurationsdatei aide.conf
Die Initialisierung der AIDE-Datenbank
Zentrale Speicherung der AIDE-Datenbanken aller verwalteter Hosts auf dem Ansible Control Node (ACN)
Durchführung von Integritäts-Checks
Aktualisierung der AIDE-Datenbanken und erneute Speicherung auf dem ACN
Durch die Speicherung der AIDE-Datenbanken und -Konfigurationsdateien auf dem ACN sind diese gegen Veränderung auf einem kompromittierten Host geschützt. Gegen Veränderungen auf dem ACN selbst sind die Dateien nur mit Unix-Dateiberechtigungen geschützt. Doch wenn der ACN kompromittiert ist, hat man eh ein ganz anderes Problem, als sich um AIDE Sorgen zu machen.
Labor-Umgebung
Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:
ansible-ctrl (RHEL 8 mit installiertem ansible-core)
rhel7
rhel8
rhel9
Der ACN kann sich via SSH zu den Zielsystemen (rhel{7,8,9}) verbinden und dort Programmcode mit erhöhten Rechten ausführen.
Die Rolle ist nicht idempotent. Sie ruft das Programm aide auf den Zielsystemen mit verschiedenen Optionen auf und verarbeitet deren Ausgabe. Dazu macht die Rolle Gebrauch des Moduls ansible.builtin.command.
Gesteuert wird die Rolle über Ansible-Tags. Wird die Rolle in einem Playbook ohne Angabe von Tags ausgeführt, werden keinerlei Veränderungen an den Zielsystemen vorgenommen.
Der folgende Code-Block zeigt ein Beispiel-Playbook zum Aufruf der Rolle. Die Tags und die Variable aide_db_fetch_dir werden im Anschluss erläutert.
# SPDX-License-Identifier: MIT
---
- name: Example aide role invocation
hosts: targets
tasks:
- name: Include role aide
tags:
- install
- generate_config
- init
- check
- update
vars:
aide_db_fetch_dir: files
ansible.builtin.include_role:
name: aide
install – Bei Angabe dieses Tags stellt die Rolle sicher, dass das Paket aide auf den Zielsystemen installiert ist
generate_config – Generiert die Datei /etc/aide.conf unter Nutzung von templates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster Abschnitt
init – Hiermit wird die AIDE-Datenbank initialisiert, welche als Referenzdatenbank für zukünftige Checks dient
check – Führt einen Integritäts-Check unter Verwendung der Referenzdatenbank durch
update – Führt einen Integritäts-Check durch und erzeugt eine neue AIDE-Datenbank, welche zukünftig als Referenz dient
Die Variable aide_db_fetch_dir erwartet im Auslieferungszustand das Verzeichnis files parallel zum Playbook. In diesem Verzeichnis werden Unterverzeichnisse für jeden Host erstellt, in denen die AIDE-Datenbank der verwalteten Systeme gespeichert wird. Soll ein anderer Speicherort verwendet werden, ist der Wert dieser Variablen entsprechend anzupassen. Die AIDE-Datenbanken werden mit dem Ansible-Module ansible.builtin.fetch von den verwalteten Systemen geholt.
Nutzung für die verschiedenen Anwendungsfälle
In diesem Abschnitt beschreibe ich die fünf Anwendungsfälle für den PoC. Alle Anwendungsfälle wurden gegen RHEL 7, RHEL 8 und RHEL 9 getestet. Für diesen Blog beschränke ich mich jedoch auf Tests gegen RHEL 9, um die Übersichtlichkeit der Ausgaben zu verbessern.
Um AIDE nutzen zu können, muss es zuerst installiert sein. Dies wird mit folgendem Playbook-Aufruf festgestellt:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Ensure required packages are installed] ***************************
changed: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Für diesen Anwendungsfall arbeitet die Rolle idempotent. Bei einer zweiten Ausführung werden keine weiteren Änderungen am System vorgenommen:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Ensure required packages are installed] ***************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Anwendungsfall 2: Generierung der Datei /etc/aide.conf
Zusammen mit der Rolle wird die Datei templates/aide.conf.j2 ausgeliefert. Dabei handelt es sich um die Standardkonfigurationsdatei aus einer RHEL9-Installation, in welcher zusätzlich der Pfad /root/.ansible* von der Überwachung ausgenommen wurde, um falsch positive Ergebnisse zu vermeiden.
Diese Datei ist an die individuellen Bedürfnisse anzupassen. Wer Hilfe zum Templating mit Jinja2 benötigt, findet in der Ansible-Dokumentation einen Einstieg.
Ausgerollt wird die Konfigurationsdatei dann wie folgt:
Auch mit diesem Tag arbeitet die Rolle idempotent.
Wird dieser Schritt ausgelassen, wird in allen folgenden Anwendungsfällen die Standardkonfigurationsdatei verwendet, welche bei der Installation des Pakets aide mitinstalliert wurde.
Anwendungsfall 3: Initialisierung der AIDE-Datenbank
Um Integritäts-Checks durchführen zu können, muss zuerst die AIDE-Datenbank initialisiert werden. Dies geschieht mit dem folgenden Aufruf:
Nach der Initialisierung der AIDE-Datenbank wird diese auf den ACN kopiert und von den verwalteten Systemen entfernt. Dies hat den Hintergrund, dass es sich beim ACN um ein sehr gut gesichertes System handelt und die Datenbanken hier am besten vor einer Kompromittierung geschützt sind.
Wird der Standardwert der Variable aide_db_fetch_dir verwendet, findet sich die AIDE-Datenbank jetzt im Pfad files/rhel9/var/lib/aide/aide.db.new.gz. Dabei entspricht rhel9 in der Pfadangabe dem inventory_hostname des jeweiligen Zielsystems.
Dieser Teil der Rolle ist nicht idempotent. Wird das Playbook erneut ausgeführt, wird eine neue AIDE-Datenbank erstellt, auf den ACN heruntergeladen und vom Zielsystem gelöscht.
Anwendungsfall 4: Ausführung einer Integritätsprüfung
Der nun folgende Code-Block zeigt den Playbook-Aufruf zur Integritätsprüfung. Hier wird zuerst die AIDE-Datenbank auf das Zielsystem kopiert, anschließend ein AIDE-Check ausgeführt. Da im folgenden Beispiel keine Änderungen detektiert wurden, besitzt der Task „[aide : Check against AIDE reference database]“ den Status „ok“.
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]
TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Dieser Teil der Rolle ist nicht idempotent. Bei jedem Aufruf wird ein neuer Integritäts-Check ausgeführt.
Ich habe die Datei /etc/hosts auf dem Zielsystem manipuliert, um auch den Fall zu zeigen, wenn eine Änderung erkannt wurde.
Zu Beginn der folgenden Ausgabe ist zu erkennen, dass der Task „[aide : Copy AIDE reference database to remote]“ den Status „ok“ besitzt. Ansible hat erkannt, dass die AIDE-Datenbank bereits in unverändertem Zustand auf dem Zielsystem existiert, und hat sie deshalb nicht erneut übertragen. Der Task „[aide : Check against AIDE reference database]“ schlägt nun allerdings fehl (Status: „fatal“), da Veränderungen erkannt wurden. Die zugegeben etwas unübersichtliche Ausgabe enthält die Nachricht, dass die Datei /etc/hosts verändert wurde.
An dieser Stelle wurde gezeigt, dass sowohl unveränderte Systeme als auch Systeme mit Veränderungen erkannt und gemeldet werden. Dabei muss natürlich niemand die Standardausgabe beobachten. Stattdessen kann Logging für Ansible Ausgaben konfiguriert werden.
Anwendungsfall 5: Update der AIDE-Datenbank
Dieser Anwendungsfall nimmt an, dass erfolgte Änderungen legitim sind und in die AIDE-Referenzdatenbank aufgenommen werden sollen. Dies geschieht wie folgt:
Nachdem die Referenzdatenbank aktualisiert wurde, wird diese wieder auf den ACN kopiert und vom Zielsystem entfernt.
Das folgende Beispiel zeigt, dass auf dem Zielsystem der AIDE-Check nun ohne Fehler absolviert wird:
[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check
PLAY [Example aide role invocation] ********************************************
TASK [Gathering Facts] *********************************************************
ok: [rhel9]
TASK [Include role aide] *******************************************************
TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]
TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]
PLAY RECAP *********************************************************************
rhel9 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Ansible hat erkannt, dass die AIDE-Datenbank auf dem Zielhost nicht mit der aktuellen Referenzdatenbank übereinstimmt und hat letztere daher auf das Zielsystem übertragen. Die Überprüfung endet mit dem Status „ok“. Das System entspricht dem Soll-Zustand.
Zusammenfassung
Der Proof of Concept hat gezeigt, dass AIDE mit der verwendeten Ansible-Rolle ferngesteuert genutzt werden kann. AIDE-Datenbank und Konfigurationsdatei werden dabei getrennt von den verwalteten Systemen gespeichert und sind daher gegen Veränderung bei Kompromittierung der Zielsysteme geschützt. Bei Bedarf, wenn Ansible Abweichungen des Ist- zum Soll-Zustand erkennt, werden diese Dateien auf die Zielsysteme übertragen.
Der größte Arbeitsaufwand steckt in der Erstellung einer oder mehrerer AIDE-Konfigurationsdateien, die optimal zur eigenen Umgebung passen und möglichst keine falsch positiven Ergebnisse erzeugen. Dieser Aufwand besteht jedoch auch, wenn man AIDE ohne Ansible einsetzt.
Einen Punkt hat dieser PoC unberücksichtigt gelassen. Es nützt natürlich nichts, wenn man die Ausgaben der Playbooks nur protokolliert, die Protokolle jedoch nicht analysiert, um entsprechende Alarme in Monitoring- oder Ticket-Systemen zu erzeugen. Dies sei den Anwendern zur selbstständigen Übung überlassen. ;-)
Dies ist mein Erfahrungsbericht der Chemnitzer Linux-Tage 2024. Es war mal wieder eine sehr schöne Veranstaltung.
Die Anreise
Im vergangenen Jahr hatte mich die Deutsche Bahn in Chemnitz sitzengelassen und ich musste mit einem kurzfristig angemieteten Leihwagen heimfahren.
Da die Deutsche Bahn und die Gewerkschaft Deutscher Lokomotivführer sich noch immer nicht auf einen neuen Tarifvertrag einigen können und ich mich nicht erneut über eine schlechte Verbindung ärgern wollte, bin ich dieses Jahr mit dem eigenen Pkw gefahren.
Am Freitag um 13:30 Uhr ging die Reise los. Mit viel Verkehr, Baustellen und Stau waren ich etwa 4,5 Stunden später im Hotel, wo ich direkt über Stoeps gestolpert bin.
Wir spazierten vom Residenz Hotel Chemnitz zum Veranstaltungsgebäude, um uns anzumelden und unsere Badges zu empfangen. Damit ersparten wir uns das Warten in der Schlange am Samstagmorgen.
Am Hörsaalgebäude traf ich schon erste vertraute Gesichter, wie z.B. Andreas, welcher fleißig beim Aufbau geholfen hat. Hier haben wir uns auch mit Michael von der Aspicon GmbH getroffen, mit dem ich für Sonntag einen Vortrag geplant hatte. Wir sind gemeinsam in die Stadt gegangen, um uns bei Speis und Trank kennenzulernen und den Abend zu verplaudern.
Der Samstag
Um 07:00 Uhr begann ich den Tag mit dem Frühstück. So war der erste Hunger bereits gestillt, als der Frühstücksraum sich zu füllen begann. Bekannte Gesichter und nerdige T-Shirts verrieten, dass es sich bei sehr vielen der Gäste um Besucher der Chemnitzer Linux-Tage handelte.
Die 20 Minuten zum Veranstaltungsort wurden auch diesmal wieder zu Fuß zurückgelegt. Und der erste Konferenztag konnte beginnen.
Um 10:00 Uhr war ich an der Reihe und durfte in einem rappelvollen Raum V6 meinen „::1“-Vortrag halten. An dieser Stelle euch allen nochmal vielen Dank für eure Teilnahme. Ich hoffe, ihr hattet so viel Spaß wie ich und konntet ein paar neue Eindrücke gewinnen.
Es hat mich gefreut, auch nach dem Vortrag noch einige Fragen beantworten zu können und über IPv6 zu fachsimpeln. Ganz nebenbei konnte ich auch noch die Frage eines Red Hat-Kunden beantworten. Darüber freute sich dieser sehr, bleibt ihm der Support eine zufriedenstellende Antwort doch seit langer Zeit schuldig. Es ist halt stets eine gute Erfahrung, einen TAM zu treffen.
Die Chemnitzer Linux-Tage gibt es übrigens schon seit 25 Jahren. Da eine Veranstaltung aufgrund der Pandemie ausfallen musste, findet die 25. Veranstaltung allerdings erst im nächsten Jahr am 22. und 23. März statt.
20-jähriges Jubiläum feiert in diesem Jahr Ubuntu, weshalb der Community-Stand dieses Jahr besonders schön geschmückt war und toddy mehrfach mit Luftschlangen gefesselt wurde.
Ich genieße die Zeit unter gleichgesinnten Nerds oder wie Stoeps es ausdrückte: „Endlich wieder unter normalen Menschen“. Mich hat es dieses Jahr sehr gefreut, auch viele jüngere Gesichter zu sehen. So sehr ich mich freue, auch die gleichen alten Nasen immer wiederzutreffen ist es doch schön, dass die Gemeinschaft nicht einfach alt wird, sondern auch junge Menschen mit Interesse, Motivation und Freude an Open Source nachwachsen.
Da die Hörsäle hier bei den Vorträgen meist aus allen Nähten platzen, hatte ich mich im Vorfeld als Sessionleitung für die drei Vorträge
gemeldet. So war mir ein guter Platz im Raum sicher. Ich danke den drei Referenten für ihre interessanten Vorträge.
Am Abend waren alle Aussteller, Helfer und Referenten zum gemütlichen Beisammensein in die Mensa eingeladen, welche schräg gegenüber dem Veranstaltungsgebäude liegt. Hier gab es ein reichhaltiges Angebot an warmem und kaltem Essen sowie eine Auswahl verschiedenster Getränke. Vielleicht ist es in der Zukunft möglich, die Getränke zu kühlen. Dann wird das Bier nicht so schnell warm und schmeckt länger gut.
Ich schätze es sehr, mich auf Konferenzen mit alten und neuen Bekannten auszutauschen, zu fachsimpeln und ganz allgemein angeregte Gespräche zu führen. Das musikalische Rahmenprogramm traf auch in diesem Jahr nicht meinen Geschmack. Ich würde mir etwas Hintergrundberieselung wünschen, um sich gut unterhalten zu können. Doch sind Geschmäcker verschieden und ich erkenne durchaus an, was das Organisations-Team der Chemnitzer Linux-Tage hier Jahr für Jahr auf die Beine stellt. Euch allen vielen Dank für euren unermüdlichen Einsatz.
Der Sonntag
Nach einem frühen Frühstück und Check-out ging es heute mit dem Auto zum Veranstaltungsgelände. Noch vor dem zweiten Kaffee wurden hier die Folien für den nächsten Vortrag nochmal geprüft. Um 10:00 Uhr war es wieder soweit. Diesmal durfte ich zusammen mit Michael den Vortrag „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ halten.
@Michael: „Es hat mir gut gefallen, mit dir einen Vortrag zu halten. Das können wir gerne wiederholen.“
Beim Mittagessen habe ich dann auch noch Christian getroffen. Für ihn waren es die ersten Chemnitzer Linux-Tage und auch ihm haben sie sehr gut gefallen.
Und wie immer war die Zeit auch viel zu schnell wieder vorbei. So habe ich Henning zwar kurz gesehen, doch für mehr als ein kurzes „Hi und Tschüss, bis zum nächsten Mal“ reichte es diesmal leider nicht.
Die Heimreise
Auch die schönsten Chemnitzer Linux-Tage gehen vorbei. Doch im Auto sitzend freute ich mich auch schon darauf, meine Familie wiederzusehen. Die Straße war frei und nach nur 3 Stunden 20 Minuten war ich wieder daheim. Zum Vergleich, mit der Bahn wäre ich je nach Verbindung erst nach 5,5-6,5 Stunden daheim gewesen, wenn alles nach Plan fährt.
So konnte ich mehr Zeit vor Ort verbringen und war rechtzeitig daheim, um noch etwas Zeit mit meinem Sohn zu verbringen, bevor dieser ins Bett ging.
Fazit
Es war schön. Ich hoffe, ihr seid alle wieder gut heimgekommen und behaltet auch diese Chemnitzer Linux-Tage in guter Erinnerung.
Nun habe ich auch noch den tollen Beitrag von Andreas Scherbaum „Chemnitzer Linux-Tage 2024: Hinweise und Tipps“ gelesen. Er enthält unter anderem Hinweise und Tipps zur Anfahrt, Parken, Verpflegung, Merchandise, Kinderparadies und CLT Junior, Übernachtung, Abendessen am Freitag, Ruhezonen, etc.
Danke Andreas, für den tollen Text, den ich hier gerne teile.
Mit einem Dualstack-Proxy Internet-Protokolle verbinden beschrieb eine Möglichkeit, um von Hosts, welche ausschließlich über IPv6-Adressen verfügen, auf Ziele zugreifen zu können, die ausschließlich über IPv4-Adressen verfügen. In diesem Beitrag betrachte ich die andere Richtung.
Zu diesem Beitrag motiviert hat mich der Kommentar von Matthias. Er schreibt, dass er für den bei einem Cloud-Provider gehosteten Jenkins Build Server IPv4 deaktivieren wollte, um Kosten zu sparen. Dies war jedoch nicht möglich, da Kollegen aus einem Co-Workingspace nur mit IPv4 angebunden sind und den Zugriff verloren hätten.
Doch wie kann man nun ein IPv6-Netzwerk für ausschließlich IPv4-fähige Clients erreichbar machen, ohne für jeden Host eine IPv4-Adresse zu buchen? Dazu möchte ich euch anhand eines einfachen Beispiels eine mögliche Lösung präsentieren.
Vorkenntnisse
Um diesem Text folgen zu können, ist ein grundsätzliches Verständnis von DNS, dessen Resource Records (RR) und des HTTP-Host-Header-Felds erforderlich. Die Kenntnis der verlinkten Wikipedia-Artikel sollte hierfür ausreichend sein.
Umgebung
Zu diesem Proof of Concept gehören:
Ein Dualstack-Reverse-Proxy-Server (HAProxy) mit den DNS-RR:
haproxy.example.com. IN A 203.0.113.1
haproxy.example.com IN AAAA 2001:DB8::1
Zwei HTTP-Backend-Server mit den DNS-RR:
www1.example.com IN AAAA 2001:DB8::2
www2.example.com IN AAAA 2001:DB8::3
Zwei DNS-RR:
www1.example.com IN A 203.0.113.1
www2.example.com IN A 203.0.113.1
Ein Client mit einer IPv4-Adresse
Ich habe mich für HAProxy als Reverse-Proxy-Server entschieden, da dieser in allen Linux- und BSD-Distributionen verfügbar sein sollte und mir die HAProxy Maps gefallen, welche ich hier ebenfalls vorstellen möchte.
Der Versuchsaufbau kann wie folgt skizziert werden:
Ein Dualstack-Reverse-Proxy-Server (B) verbindet IPv4-Clients mit IPv6-Backend-Servern
HAProxy-Konfiguration
Für dieses Minimal-Beispiel besteht die HAProxy-Konfiguration aus zwei Dateien, der HAProxy Map hosts.map und der Konfigurationsdatei poc.cfg.
Eine HAProxy Map besteht aus zwei Spalten. In der ersten Spalte stehen die FQDNs, welche vom HTTP-Client aufgerufen werden können. In der zweiten Spalte steht der Name des Backends aus der HAProxy-Konfiguration, welcher bestimmt, an welche Backend-Server eine eingehende Anfrage weitergeleitet wird. In obigem Beispiel werden Anfragen nach www1.example.com an das Backend serversa und Anfragen nach www2.example.com an das Backend serversb weitergeleitet.
Die HAProxy Maps lassen sich unabhängig von der HAProxy-Konfigurations-Datei pflegen und bereitstellen. Map-Dateien werden in ein Elastic Binary Tree-Format geladen, so dass ein Wert aus einer Map-Datei mit Millionen von Elementen ohne spürbare Leistungseinbußen nachgeschlagen werden kann.
Die HAProxy-Konfigurations-Datei poc.cfg für dieses Minimal-Beispiel ist ähnlich simpel:
~]$ cat /etc/haproxy/conf.d/poc.cfg
frontend fe_main
bind :80
use_backend %[req.hdr(host),lower,map(/etc/haproxy/conf.d/hosts.map)]
backend serversa
server server1 2001:DB8::1:80
backend serversb
server server1 2001:DB8::2:80
In der ersten Zeile wird ein Frontend mit Namen fe_main definiert. Zeile 2 bindet Port 80 für den entsprechenden Prozess und Zeile 3 bestimmt, welches Backend für eingehende HTTP-Anfragen zu nutzen ist. Dazu wird der HTTP-Host-Header ausgewertet, falls notwendig, in Kleinbuchstaben umgewandelt. Mithilfe der Datei hosts.map wird nun ermittelt, welches Backend zu verwenden ist.
Die weiteren Zeilen definieren zwei Backends bestehend aus jeweils einem Server, welcher auf Port 80 Anfragen entgegennimmt. In diesem Beispiel sind nur Server mit IPv6-Adressen eingetragen. IPv4-Adressen sind selbstverständlich auch zulässig und beide Versionen können in einem Backend auch gemischt auftreten.
Kann eine HTTP-Anfrage nicht über die hosts.map aufgelöst werden, läuft die Anfrage in diesem Beispiel in einen Fehler. Für diesen Fall kann ein Standard-Backend definiert werden. Siehe hierzu den englischsprachigen Artikel Introduction to HAProxy Maps von Chad Lavoie.
Der Kommunikationsablauf im Überblick und im Detail
Der Kommunikationsablauf im Überblick
Von einem IPv4-Client aus benutze ich curl, um die Seite www1.example.com abzurufen:
~]$ curl -4 -v http://www1.example.com
* processing: http://www1.example.com
* Trying 203.0.113.1:80...
* Connected to www1.example.com (203.0.113.1) port 80
> GET / HTTP/1.1
> Host: www1.example.com
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 200 OK
< server: nginx/1.20.1
< date: Sat, 06 Jan 2024 18:44:22 GMT
< content-type: text/html
< content-length: 5909
< last-modified: Mon, 09 Aug 2021 11:43:42 GMT
< etag: "611114ee-1715"
< accept-ranges: bytes
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>
Der FQDN www1.example.com wird mit der IPv4-Adresse 203.0.113.1 aufgelöst, welche dem Host haproxy.example.com gehört. Bei der Zeile Host: www1.example.com handelt es sich um den HTTP-Host-Header, welchen der HAProxy benötigt, um das richtige Backend auszuwählen.
Es ist zu sehen, dass wir eine Antwort von einem NGINX-HTTP-Server erhalten. Der HTML-Quelltext wurde gekürzt.
Damit ist es gelungen, von einem IPv4-Client eine Ressource abzurufen, die von einem IPv6-Server bereitgestellt wird.
Im Access-Log des Backend-Servers mit der IPv6-Adresse 2001:DB8::2 sieht man:
Die Anfrage erreicht den Backend-Server von der IPv6-Adresse des haproxy.example.com (2001:DB8::1). Die am Ende der Zeile zu sehende IPv4-Adresse (192.0.2.1) gehört dem IPv4-Client, von dem ich die Anfrage gesendet habe.
Gedanken zur Skalierung
In diesem Beispiel sind die Server www1.example.com und www2.example.com über ihre IPv6-Adressen direkt erreichbar. Nur die Client-Anfragen von IPv4-Clients laufen über den Reverse-Proxy. Wenn man es wünscht, kann man selbstverständlich sämtliche Anfragen (von IPv4- und IPv6-Clients) über den Reverse-Proxy laufen lassen.
In kleinen Umgebungen kann man einen Reverse-Proxy wie HAProxy zusammen mit Squid (vgl. Artikel Mit einem Dualstack-Proxy Internet-Protokolle verbinden) auf einem Host laufen lassen. Selbstverständlich kann man sie auch auf separate Hosts verteilen.
Hochverfügbarkeit lässt sich auch hier mit keepalived nachrüsten:
Die Internet-Protokolle IPv4 und IPv6 werden wohl noch eine ganze Zeit gemeinsam das Internet bestimmen und parallel existieren. Ich bin mir sogar sicher, dass ich das Ende von IPv4 nicht mehr miterleben werde. Dualstack-(Reverse)-Proxy-Server stellen eine solide und robuste Lösung dar, um beide Welten miteinander zu verbinden.
Sicher bleiben noch ausreichend Herausforderungen übrig. Ich denke da nur an Firewalls, Loadbalancer, NAT und Routing. Und es werden sich auch Fälle finden lassen, in denen Proxyserver nicht infrage kommen. Doch mit diesen Herausforderungen beschäftige ich mich dann in anderen Artikeln.
In drei Wochen beginnen die Chemnitzer Linux-Tage 2024 mit dem diesjährigen Motto „Zeichen setzen“. Am 16. und 17. März erwartet euch im Hörsaalgebäude an der Richenhainer Straße 90 ein vielfältiges Programm an Vorträgen und Workshops. Hier finden sich Vorträge für interessierte Neueinsteiger wie für alte Hasen.
So geht es am Samstag im Einsteigerforum beispielsweise um die Digitalisierung analoger Fotos, das Erstellen von Urlaubsvideos mit der Software OpenShot oder die Verschlüsselung von E-Mails. In der Rubrik „Schule“ gibt Arto Teräs einen Einblick in den Einsatz der Open-Source-Lösung Puavo an finnischen und deutschen Schulen. Zusätzlich stehen Vorträge aus den Bereichen Finanzen, Medien, Datensicherheit, KI oder Netzwerk auf dem Programm. Am Sonntag gibt das Organisationsteam der Chemnitzer Linux-Tage mit „make CLT“ Einblicke in die Planung und Strukturen der Veranstaltung selbst. In der Rubrik „Soft Skills” wird es um die Schätzung von Aufwänden oder notwendige Fähigkeiten von Software-Entwicklern gehen.
Eintrittskarten können online im Vorverkauf und an der Tageskasse erworben werden. Kinder bis 12 Jahren haben freien Eintritt.
Während viele Besucher bereits Stammgäste sind, werden auch neue Gesichter herzlich willkommen. Lasst euch gern von der hier herrschenden Atmosphäre voller Begeisterung für freie Software und Technik anstecken und begeistern.
Ich selbst freue mich, am Samstag um 10:00 Uhr in V6 den Vortrag mit dem obskuren Namen ::1 beisteuern zu dürfen. Update: Unverhofft kommt oft. Uns so freue ich mich am Sonntag um 10:00 Uhr in Raum V7 noch in einem zweiten Vortrag vertreten zu sein. Zusammen mit Michael Decker von der ASPICON GmbH erfahrt ihr, wie man „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ angehen kann.
Darüber hinaus beteilige ich mich als Sessionleiter für die folgenden drei Vorträge an der Veranstaltung:
So habe ich auf jeden Fall einen Platz im Raum sicher. ;-)
Wer ebenfalls helfen möchte, kann sich unter Mitmachen! informieren und melden.
Für mich ist dieses Jahr einiges im Programm dabei. Doch freue ich mich ebenso sehr auf ein Wiedersehen mit alten Bekannten aus der Gemeinschaft und darauf, neue Gesichter (Namen kann ich mir meist erst Jahre später merken) kennenzulernen.
Am 16. und 17. März 2024 werde ich euch auf den Chemnitzer Linux-Tagen um 10:00 Uhr in Raum V6 mit einem Vortrag über IPv6 unterhalten.
Dazu bin ich noch auf der Suche nach ein paar Beispielen aus dem echten Leben. Falls ihr mögt, teilt mir doch eure schönsten und schlimmsten Momente im Zusammenhang mit IPv6 mit und ich prüfe, ob ich sie in meinen Vortrag mit einbauen kann.
Wann und wie hat IPv6 euren Tag gerettet?
Wieso hat euch das Protokoll Alpträume beschehrt?
Was funktioniert wider Erwarten immer noch nicht mit IPv6?
Habt ihr lustige Geschichten, die ihr (anonym) mit der Welt teilen möchtet?
Ich freue mich über Einsendungen, Beiträge und Rückmeldungen:
Bitte schreibt dazu, ob ihr eine Namensnennung wünscht oder euer Beispiel anonym einfließen soll.
Um einen runden Vortrag zu erstellen, wird evtl. nicht jeder Beitrag einfließen können. Bitte habt Verständnis dafür und verzeiht, wenn ihr euch nicht im Vortrag wiederfindet. Ich werde eure Geschichten ggf. im Nachgang hier im Blog veröffentlichen.
Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.
Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?
Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:
Ablauf der Netzwerkkommunikation eines IPv6-Hosts mit einem IPv4-Host über einen Dualstack-Proxy-Server
Im Bild ist zu sehen:
Wie IPv6-Host A eine Verbindung über IPv6 zum Proxy-Server B aufbaut und diesem bspw. die gewünschte URL mitteilt
Der Proxy-Server B baut nun seinerseits eine IPv4-Verbindung zu IPv4-Host C auf, welcher die gewünschten Inhalte bereitstellt
IPv4-Host C sendet seine Antwort über IPv4 an den Proxy-Server
Der Proxy-Server sendet die gewünschten Inhalte anschließend via IPv6 an den IPv6-Host A zurück
Screencast zur Demonstration der Proxy-Nutzung
Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:
Mit dem host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbar
Mit dem ip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügt
Ohne Proxy ist die Demo-Seite nicht abrufbar
Erst durch Nutzung des Proxys kann die Seite abgerufen werden
Funktioniert das auch von IPv4 nach IPv6?
Ja. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.
Welcher Proxy ist empfehlenswert?
Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.
Sind damit alle Herausforderungen bewältigt?
Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.
Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.
Wie mache ich meine IPv6-Dienste für IPv4-User erreichbar, die keinen Proxy haben?
Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)
Das ist eine gute Frage. Hat man „IPv6… Kein Anschluss unter dieser Nummer“ gelesen, kann man mich sicher fragen, warum ich mir das antue, wo doch überall Stolpersteine und Probleme lauern. Und ich kenne einige Personen, die sich lieber eine Axt ins Bein schlagen, eine Nadel unter die Fingernägel schieben oder Broccoli essen würden, statt sich mit IPv6 zu beschäftigen.
Die Antwort ist ganz einfach. Ich tue dies, weil ich es kann, Spaß daran habe und IPv4-Adressen knapper und teurer werden.
Möchte man Dienste im Internet anbieten, benötigt man IP-Adressen. Üblicherweise bekommt man zu den gängigen Angeboten von Virtual Private Server, Dedicated Server, etc. eine IPv4-Adresse und ein /64-IPv6-Netzsegment kostenlos. Zusätzliche IPv4-Adressen kosten Stand heute zwischen 2,00 € und 5,00 € pro Monat, wobei häufig noch eine saftige Einrichtungsgebühr hinzukommt. Im Abschnitt Preisübersicht findet ihr das Ergebnis einer kurzen Internetrecherche.
Da ich einen Proxmox-Host und ein /64-IPv6-Netzsegment für Spiel-, Spaß- und Laborumgebungen besitze, möchte ich mich gern damit auseinandersetzen. Und sei es nur, um zu lernen, wo es noch überall klemmt und mit welchen Workarounds man die existierenden Klippen umschiffen kann. Wundert euch also nicht, wenn es in Zukunft noch den ein oder anderen Artikel zu diesem Thema gibt.
Das Jahr 2024 ist nun schon zwei Wochen alt. Dennoch möchte ich noch einen Blick zurückwerfen und mich erinnern, wie das Jahr 2023 für meinen Blog verlaufen ist.
In 2023 wurden auf My-IT-Brain insgesamt 45 Artikel veröffentlicht. Dies sind 16 mehr als in 2022 und 14 mehr als in 2021. Jeden Monat sind mindestens zwei Artikel veröffentlicht worden.
Die Themen waren dabei wieder bunt gemischt. Allein Artikel über die Red Hat Enterprise Linux (RHEL) System Roles zogen sich wie ein roter Faden durch den Blog. Welche Artikel haben denn euch am besten gefallen? Lasst es mich gerne in den Kommentaren wissen.
Ich hoffe, es war für jeden von euch etwas Interessantes mit dabei und ihr folgt diesem Blog auch in 2024. Ihr könnt mir auch gerne Anregungen in die Kommentare schreiben, welche Themen ihr hier gerne behandelt sehen wollt. Vielleicht greife ich ja einige davon auf.
Der Anbieter meines Virtual Private Server (VPS) führt Wartungsarbeiten durch, wodurch es in genanntem Zeitraum zu einer Downtime von ca. 45 Minuten kommen wird.
Im März 2023 wechselte ich von Flex-Work in eine neue Rolle, in der ich 100 % remote arbeite. Heute möchte ich meine Erfahrungen mit euch teilen, die ich bisher damit gemacht habe.
Terminologie
Bevor es richtig losgeht, schreibe ich etwas zur Terminologie der Remote-Arbeit. Denn hier geht es mit den Begrifflichkeiten teilweise ganz schön durcheinander. Daher möchte ich sicherstellen, dass ihr versteht, was ich mit bestimmten Begriffen meine.
Telearbeit
Von allen verwendeten Begriffen ist dies der Einzige, welcher in Deutschland in der Arbeitsstättenverordnung definiert ist:
Telearbeitsplätze sind vom Arbeitgeber fest eingerichtete Bildschirmarbeitsplätze im Privatbereich der Beschäftigten, für die der Arbeitgeber eine mit den Beschäftigten vereinbarte wöchentliche Arbeitszeit und die Dauer der Einrichtung festgelegt hat. Ein Telearbeitsplatz ist vom Arbeitgeber erst dann eingerichtet, wenn Arbeitgeber und Beschäftigte die Bedingungen der Telearbeit arbeitsvertraglich oder im Rahmen einer Vereinbarung festgelegt haben und die benötigte Ausstattung des Telearbeitsplatzes mit Mobiliar, Arbeitsmitteln einschließlich der Kommunikationseinrichtungen durch den Arbeitgeber oder eine von ihm beauftragte Person im Privatbereich des Beschäftigten bereitgestellt und installiert ist.
Erbringen Arbeitnehmende die geschuldete Arbeitsleistung zum Teil am Telearbeitsplatz und zum Teil in einem Büro des Arbeitgebers, wird von alternierender Telearbeit gesprochen.
Bei dieser Form ist der Arbeitgebende für die vollständige Ausstattung des Arbeitsplatzes mit Mobiliar und Arbeitsmitteln sowie der Einhaltung arbeitsrechtlicher Vorschriften (z.B. Ergonomie, UVV, Prüfung ortsveränderlicher Elektrogeräte, etc.) verantwortlich.
Flex-Work oder auch Flex-Office
Diese Begriffe werden häufig verwendet, wenn Arbeitnehmende die geschuldete Arbeitsleistung teilweise außerhalb der Büroräume des Arbeitgebers erbringen und es sich nicht um Telearbeit handelt.
Angestellte erhalten hierbei häufig keine komplette Büroeinrichtung für den Telearbeitsplatz im privaten Raum, sondern lediglich die notwendigen Arbeitsmittel, wie z.B. Laptop und Telefon. Dafür dürfen sie häufig auch außerhalb der eigenen vier Wände bzw. des Büros z.B. aus einer Ferienwohnung arbeiten.
In manchen Fällen werden voll ausgestattete Büroarbeitsplätze für die Angestellten vorgehalten. In anderen Fällen existiert eine Form von Desksharing.
Details werden in Arbeitsverträgen, Betriebsvereinbarungen und Tarifverträgen geregelt.
Homeoffice
Der Duden definiert das Wort Homeoffice wie folgt:
[mit Kommunikationstechnik ausgestatteter] Arbeitsplatz im privaten Wohnraum
Der Begriff wird jedoch nicht einheitlich verwendet. Betrachtet man die Quellen [1]-[5], so wird er sowohl als Synonym für Telearbeit als auch als Oberbegriff für alle Formen von Arbeit verwendet, die nicht in Büroräumen des Arbeitgebers ausgeführt werden.
Wenn ich in diesem Text den Begriff Homeoffice verwende, meine ich damit mobile Arbeit, wie sie im folgenden Abschnitt beschrieben wird.
Mobile Arbeit
Bei der mobilen Arbeit sind Angestellte keinem Büro zugeordnet und nicht an einen Teleheimarbeitsplatz gebunden. Die geschuldete Arbeitsleitung kann von einem beliebigen Ort wie z.B. dem Auto, Café, Hotel oder dem Strand erbracht werden. Dies schließt die eigenen vier Wände jedoch explizit mit ein.
Dem Arbeitnehmenden werden bei dieser Form häufig nur die zwingend benötigten Arbeitsmittel wie Laptop, Mobiltelefon und ggf. Headset gestellt. Bring you own device ist ebenso möglich. Häufig erhalten Angestellte eine Pauschale, mit der sie benötigte Arbeitsmittel selbst beschaffen können.
Details werden auch hierbei im Arbeitsvertrag, in Betriebsvereinbarungen oder Tarifverträgen geregelt.
Merkmale meiner beruflichen Tätigkeit
Nicht jede Tätigkeit ist dazu geeignet, im Homeoffice ausgeführt zu werden. Pflegepersonal kann den Beruf meist ebensowenig aus den eigenen vier Wänden ausüben wie Bus-, LKW-, Zug-Fahrer und Kapitäne. Auch Berufe mit Laufkundschaft eignen sich in der Regel schlecht für Arbeit außerhalb eines festen Büros.
Ich gehöre hingegen zu den glücklichen Menschen, deren Job von einem fast beliebigen Ort aus erfüllt werden kann. Die einzige Bedingung ist eine gute Daten- und Kommunikations-Verbindung. Meine berufliche Tätigkeit lässt sich dabei mit folgenden Stichpunkten beschreiben:
Ich kann meine Tätigkeit überwiegend eigen- und selbstständig ausführen
Meine Kunden und Teammitglieder sind über Europa verteilt
Viele Kollegen sitzen sogar in noch weiter entferntliegenden Ländern
Ich benötige neben einem Laptop, einem Mobiltelefon und einer stabilen Netzwerk- bzw. Internetverbindung keine besonderen Werkzeuge
Mit diesen Merkmalen habe ich die besten Voraussetzungen, um nicht auf einen festen Arbeitsplatz beschränkt bzw. angewiesen zu sein.
Arbeitsmittel
Zu Beginn meines Arbeitsverhältnisses wurde ich mit folgenden Arbeitsmitteln ausgestattet:
Ausgeliefert wurde das System mit einem RHEL 8 Corporate Standard Build (CSB). Die Installation wird also von unserer internen IT verwaltet. Ich selbst habe sudo-Rechte auf dem System und fühle mich in keinster Weise eingeschränkt. Ich bin fasziniert, wie gut die Inbetriebnahme ablief und es so gut wie keine Probleme gab, wegen denen ich den IT-Support bemühen musste.
Bei dem Laptop handelte es sich nicht um ein topaktuelles Modell, doch ist es für meine tägliche Arbeit sehr gut geeignet. Ich nutze es täglich für die Arbeit mit:
Bis zu zwei verschiedenen Webbrowsern
Slack
1-3 virtuellen Maschinen zum Test verschiedenster Dinge
Vim
GNU Tools
Im Vergleich mit meinem privaten ThinkPad T14s ist das Gerät nach einigen Videokonferenzen deutlich lauter. Die Effizienz der CPU und Lüftersteuerung sind beim P1 nicht so gut wie beim T14s.
Das Thunderbold-Dock hingegen ist das schlechteste Dock, das ich je selbst benutzen musste. Dass für diesen elektronischen Briefbeschwerer im Online-Versandhandel zwischen 250,- und 300,- EUR aufgerufen werden, macht mich fassungslos. Hier funktioniert nichts, wie es soll. Und auch nach einer Firmware-Update-Orgie ändern sich die Fehler, in Summe bleiben sie jedoch gleich. Ich musste mich jedoch nicht lange damit ärgern. Da die Probleme bekannt sind, konnte ich mir ein Dock meiner Wahl beschaffen und die Kosten dafür erstatten lassen.
Zusätzlich zu diesen Arbeitsmitteln bekam ich noch ein Budget, für das ich mir weitere notwendige Arbeitsmittel kaufen konnte, plus ein separates Budget für ein Mobiltelefon. Von diesen Mitteln habe ich beschafft:
Zum Telefon gehört ein Vertrag. Ich konnte beides aus einer Liste auswählen. Zur Auswahl standen auch diverse Geräte von Apple, Samsung und weiteren Herstellern.
Meine Schreibtischoberfläche im November 2023
Mein Arbeitsplatz sieht in der Regel sehr aufgeräumt und unaufgeregt aus.
Ich besaß bereits vor meinem Jobwechsel einen höhenverstellbaren Schreibtisch, den ich mir für meinen Rücken gegönnt habe. Aus privater Tasche habe ich mir dann noch Bürostuhl Tailwind 2 mit Pending-System und Ponso-Sitzfläche beim lokalen Händler https://www.fair-kauf.net/ gekauft.
Wenn während der Zeit etwas kaputtgeht oder ich feststelle, dass mir doch noch etwas fehlt, bespreche ich dies mit meinem Manager. Bisher war es kein Problem, die Ausgaben für Anschaffungen, die ich sinnvoll begründen konnte, erstattet zu bekommen.
Ich bin mit meinen Arbeitsmitteln sehr zufrieden und kann meine Arbeit damit gut erledigen. Neben der Technik betrachte ich es als unschlagbaren Vorteil, ein eigenes Arbeitszimmer zu besitzen, welches nur von mir zum Zweck der Arbeit genutzt wird. Dies hat für mich folgende unschlagbare Vorteile:
Ich muss es nicht fluchtartig räumen, wenn Zeit zum Mittagessen ist
Ich kann die Tür hinter mir zumachen und sehe die Arbeit nicht mehr; dies hilft beim Abschalten und Feierabend machen
Die Trennung von Berufs- und Privatleben fällt mir so sehr leicht
Hinsichtlich Raum und Arbeitsmittel kann ich aktuell nichts bemängeln und fühle mich gut ausgestattet.
Kommunikation im Team und darüber hinaus
Kommunikation ist wichtig und findet statt, sobald sich mindestens zwei Menschen eine Situation teilen, sich am gleichen Ort oder in der gleichen Videokonferenz befinden. Die Kommunikation findet dabei auf unterschiedlichen Ebenen statt, der Sach- und der Beziehungsebene, wobei die Beziehungsebene die Sachebene bestimmt.
Eine Nachricht, die von Mensch zu Mensch übertragen wird, hat mehrere Seiten und muss vom Empfänger nicht so verstanden werden, wie der Sender sie gemeint hat.
Bei diesen Aussagen handelt es sich um Erkenntnisse von Paul Watzlawick und Friedemann Schulz von Thun aus der Kommunikationswissenschaft (siehe [7]-[10] in den Quellen unten). Kommunikation stellt einen sehr wichtigen Faktor bei der Arbeit dar und beeinflusst in hohem Maße die Produktivität sowie die Motivation der Angestellten.
Viele Artikel und Blogs verkürzen dieses Thema auf Aussagen wie:
Die Kommunikation ist im Büro besser als im Homeoffice
Im Homeoffice findet weniger Kommunikation statt als im Büro
Die Ablenkungen im Homeoffice sind geringer
Im Büro gibt es mehr unnötige Meetings
Im Büro wird man häufiger bei der Arbeit gestört als im Homeoffice
Mich stört, wenn so getan wird, als wäre die Realität schwarz oder weiß. Ist sie doch in Wirklichkeit grau (ein Blick aus dem Fenster bestätigt dies aktuell) und liegt die Wahrheit doch meist in der Mitte.
Ich möchte hier die Kommunikationskultur in der Firma und dem Team beschreiben, wo ich aktuell beruflich zu Hause bin. Da ich zu 100 % remote arbeite, finden für mich, von wenigen Kundenbesuchen im Jahr abgesehen, fast alle Meetings per Videokonferenz oder Telefon statt. Die einzige Bewertung, die ich dabei vornehme ist, dass es mir persönlich gut gefällt.
Regelmäßig wiederkehrende Meetings
Wie in vermutlich jeder Firma gibt es auch bei uns regelmäßig wiederkehrende Meetings. Dazu gehören unter anderem:
Ein zweiwöchentliches 1:1 mit meinem Manager
Ein zweiwöchentliches TEAM-Meeting
Wöchentlich bzw. zweiwöchentlich stattfindende Treffen verschiedener Virtual Account Teams
Daily Stand-up
Wöchentliche produktspezifische Q&A-Meetings
Company Meeting (einmal pro Quartal)
…
Kurz gesagt, die 40-Stunden-Woche bietet nicht genug Zeit, um an allen möglichen Meetings teilzunehmen. Doch das erwartet auch niemand.
Was mir gut gefällt:
Regelmäßige Meetings ohne Einträge auf der Agenda werden vom Organisator abgesagt
Fragen für das Daily Stand-up und Q&A-Sessions werden meist vorab in das jeweilige Meeting-Dokument eingetragen
Die Teilnehmer sind in aller Regel gut vorbereitet
Sind alle Themen besprochen, wird das Meeting einfach beendet und nicht bis zum Ende durchgezogen
Meetings werden regelmäßig hinterfragt, bringen sie keinen Mehrwert mehr, hört man einfach damit auf
Wichtige Meetings werden aufgezeichnet und es werden Protokolle erstellt
Ad-Hoc-Meetings
Benötigt man ein paar zusätzliche Augen bzw. Ideen beim Troubleshooting bzw. der Suche nach Informationen, öffnet man ein virtuelles Meeting und lädt Kolleg*innen via Chat ein. Entweder wählt man einen Kanal mit vielen Mitgliedern und hofft, dass jemand kommt oder man schreibt Teilnehmer gezielt an. Dabei gebietet die Etikette, dass man vorher prüft, ob die entsprechende Person auch frei ist. Möglich ist dies mithilfe unserer Kalender oder des Status im Chat.
Dabei ähneln diese Meetings den Störungen im Büro, wo die Tür aufgeht und Kollegen mit ihren Sorgen, Nöten und Anträgen plötzlich vor dem eigenen Schreibtisch stehen. Vorteil der Remote-Arbeit ist in meinen Augen, dass die Hemmschwelle sich diesen Störungen zu entziehen geringer ist. Eine Meetinganfrage lehnt man schneller ab oder verlässt ein Meeting schneller, als jemanden aus dem Büro hinauszubitten.
Für mich ist wichtig, vorher zu überlegen, ob der synchrone Austausch einen Vorteil über asynchrone Kommunikation bietet. Dies ist zum Beispiel der Fall, wenn sich ein Sachverhalt nur umständlich in einer E-Mail erklären lässt, oder das Risiko eines Missverständnisses hoch ist. Grundsätzlich gebe ich der asynchronen Kommunikation den Vorzug, da ich Kollegen so nicht in ihrer Arbeit störe, sie in ihrer eigenen Zeit antworten können und E-Mails Beweise generieren.
Obwohl ich ausschließlich aus dem Homeoffice arbeite, habe ich das Gefühl, weniger Zeit in Meetings zu verbringen als zuvor. Gemessen habe ich dies jedoch nicht.
Soziale-Meetings
Kaffeeküchengespräche, Gesabbel beim Mittagessen und Flurfunk sterben bei mobiler Arbeit aus. Das stimmt in meiner Erfahrung so nicht.
Wir treffen uns sporadisch zum Kaffeetrinken in einer Videokonferenz und sprechen darüber, wie unser Tag so läuft, was es Neues gibt. Dabei werden sowohl dienstliche wie private Themen diskutiert.
Manche Kollegen treffen sich sogar in einer Videokonferenz, ohne aktiv miteinander zu sprechen. Man könnte auch sagen: „Sie schweigen sich konstruktiv an.“ Dies kann das Gefühl reduzieren, allein zu sein. Es ist jemand in der Nähe, der zuhört und in aller Regel auf geräuschvolle Äußerungen reagiert.
Persönliche Treffen in der realen Welt
„Vermisse ich regelmäßige persönliche Treffen in der realen Welt? Nein.“
„Weiß ich diese Treffen dennoch zu schätzen? Ja.“
In meinen Augen ist dies kein Widerspruch in sich. Ich habe mich schnell daran gewöhnt, dass mein Team verteilt sitzt und die meisten Kontakte durch Chat, E-Mail und Videokonferenz stattfinden. Dennoch freue ich mich, diese Menschen am Rande von Veranstaltungen auch mal persönlich zu treffen. Besonders gern, wenn dies ungezwungen außerhalb formal organisierter Teambildungsmaßnahmen passiert.
Chat und E-Mail
Dies sind definitiv zwei meiner Hauptarbeitsmittel. Beide sind Werkzeuge zur asynchronen Kommunikation. Chat ist dabei in der Regel schneller als E-Mail, wobei ich persönlich E-Mails besser strukturieren kann und Dinge leichter in E-Mails wiederfinde.
Aus Gesprächen mit Menschen aus verschiedenen Unternehmen weiß ich, dass Chat Fluch und Segen sein kann. Dies ist jedoch kein technisches Problem, sondern hängt von der Unternehmenskultur und der persönlichen Disziplin ab. Wird erwartet, dass jeder zu jederzeit erreichbar ist und prompt reagiert, kann das die Produktivität ziemlich in den Keller drücken.
Setzt man einen Status wie verfügbar, beschäftigt, im Termin u.ä. und wird dies respektiert, kann Chat die Kommunikation wunderbar unterstützen. Das klappt selbst dann, wenn es mehrere Chats-Werkzeuge gibt.
Telefon
Zum Glück werde ich nur sehr selten angerufen und ich rufe auch nur selten jemanden an. Warum? Ich empfinde unangekündigte Anrufe als Störung, denn sie unterbrechen meine Arbeit. Und was ich selbst nicht will, das man mir tu, das füge ich niemand anderem zu.
Das Telefon ist für mich ein Kommunikationsmittel für den Fall, wenn es etwas sehr Dringendes zu bereden gibt. Oder wenn ich weiß, dass es das bevorzugte Kommunikationsmittel der Person ist, von der ich etwas möchte.
Es gibt Dinge, die kann man am Telefon oder in einer Videokonferenz schneller bzw. einfacher klären als in einer langen Chat- oder E-Mail-Diskussion. Ich empfinde es dann allerdings als höflich, wenn man für das Telefonat einen Termin vereinbart, statt ohne Vorwarnung durchzuklingeln.
Mich freut es sehr, dass ich nicht ständig von eingehenden Anrufen und Video-Calls gestört werde.
Dinge, die mir persönlich wichtig sind
Ich sehe meine Familie morgens, bevor mein Kind in die Schule muss und ich mit der Arbeit beginne
Meine Frau bringt mir liebevoll Kaffee!
Mittags kann ich gemeinsam mit meiner Frau essen (Sorry Ex-Kollegen, meine Frau kocht deutlich besser als die Mensa)
Ich bin schon daheim, wenn mein Sohn heim kommt; ich sehe ihn länger als wenn ich pendel
Ich muss nicht mehr pendeln; diese hat mich über die Jahre immer mehr genervt (siehe dazu auch [11] in den Quellen)
Fazit
Aktuell passt die Form der mobilen Arbeit, wie sie in meinem Team bei Red Hat gelebt wird, sehr gut zu meinen persönlichen Vorlieben und meiner Lebenssituation.
Mir gefällt es, dass ich in Ruhe und allein arbeiten kann, gleichzeitig aber ein guter Kontakt zu Kolleg*innen existiert, mit denen ich mich austauschen kann. Ich bin sehr zufrieden und hoffe, dass es noch lange so weitergeht.
Herausforderungen in der Zusammenarbeit und Kommunikation liegen in meiner Erfahrung meist in der Unternehmenskultur begründet und nur selten in der Technik. Daher empfehle ich allen, bei denen es nicht optimal läuft, über Anforderungen zu sprechen und erst danach über mögliche Programme zur Lösung derselben.
Euch wünsche ich, dass ihr ein Arbeits(zeit)modell findet, das gut zu euch passt. Wenn ihr Lust habt, teilt doch gern eure Erfahrungen mit eurer Arbeit im Büro, hybrid oder remote hier. Ich freue mich zu erfahren, wie ihr heute arbeitet und wie zufrieden ihr damit seid.
Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.
In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.
Red Hat Satellite 6.14
Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:
You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.
Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.
Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:
You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.
Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:
Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.
subscription-manager cli command does not support IPv6 proxy
Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.
Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.
ansible-galaxy does not work on IPv6 only hosts
Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:
So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…
IPv6 support for cloning Git repositories #10539
Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:
$ host -t AAAA github.com
github.com has no AAAA record
Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“
Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.
Welche Erfahrungen habt ihr mit IPv6 gemacht?
Habt ihr es schon an den Nagel gehängt; oder bleibt ihr hartnäckig und gebt nicht auf?
Ich freue mich auf eure schönsten Fehlschläge und Erfolgsmomente.
Ich kann nicht für alle TAMs bei Red Hat sprechen, denn wir arbeiten sehr selbstständig und haben nur wenige feste Vorgaben. Doch möchte ich euch einen Einblick geben, wie eine Woche in meinem aktuellen Job aussehen kann.
Bitte bedenkt, dass nicht jede Woche gleich aussieht. Das wäre ja auch schrecklich eintönig und langweilig. Dennoch habe ich eine gewisse Routine, mit der ich den Alltag bewältige.
Ich wünsche euch viel Spaß bei diesem Wochenrückblick.
Hinweis: Die hier beschriebene Woche liegt schon etwas zurück. Der Bericht wurde erst kürzlich fertiggestellt.
Montag
Die Woche begann mit einem etwas ungewöhnlichen Montag. Denn mein Sohn hatte schulfrei und brachte meine Morgenroutine gehörig durcheinander.
Statt vor dem Monitor begann mein Arbeitstag daher mit dem Diensthandy. Hierauf habe ich mir einen Überblick über Chat und E-Mail verschafft, um zu sehen, ob über das Wochenende irgendetwas eskaliert ist oder es Themen gibt, denen ich mich zuerst widmen muss. Bei dieser Gelegenheit habe ich direkt alle E-Mails, die ich ob ihres Betreffs als unwichtig klassifiziert habe, direkt gelöscht.
Beim Üerfliegen verschiedener Newsletter ist mir aufgefallen, dass mein Name im letzten TGIF Newsletter auftaucht. Denn ich habe letzte Woche KCS2 erreicht. KCS ist die Abkürzung für Knowledge-centered support. Level 2 bedeutet, dass ich mein Training abgeschlossen habe und zukünftig Lösungs-Artikel selbst veröffentlichen darf. Bisher hat dies mein KCS-Coach nach einem Review der jeweiligen Artikel getan. Ich habe mich über diese kleine Anerkennung gefreut. :-)
Wie fast jeden Morgen habe ich einen Blick in unser Support-Tool geworfen, um mir einen Überblick über mir zugewiesene Cases und ggf. neue Cases meiner Kunden zu verschaffen. Heute sah es hier sehr ruhig aus und es gab nichts zu tun.
Als TAMs arbeiten wir an strategischen und wichtigen Cases unserer Kunden. Damit ihr euch ein bisschen besser vorstellen könnt, was damit gemeint ist, beschreibe ich euch, wie ich Support-Cases handhabe.
Exkurs: Case Work
Als TAM arbeite ich auf Kundenseite mit einem Team zusammen, welches in der Regel aus 4-6 Personen besteht. Dies sind meine TAM-Kontakte. Wenn ein TAM-Kontakt einen Support-Case öffnet, wird dieser mit einem TAM-Flag versehen und wird in meiner View des Support-Tools sichtbar.
Üblicherweise wird der TAM Eigentümer dieser Tickets und bearbeitet sie, bis sie mit dem Einverständnis des Kunden als gelöst geschlossen werden. Die folgende Liste bietet einen kleinen Auszug aus den Themen, die ich überlichweise selbst bearbeite:
Requests for Enhancements (RFE) zu Bestandteilen von RHEL
Bereitstellung von Informationen zur Zertifizierung von Anwendungen Dritter für RHEL
Beantwortung allgemeiner Fragen zu unseren Produkten, deren Life Cycle und zur Roadmap
Anfragen, die sich zu Beginn nicht richtig einordnen lassen und wo Ziel und Umgebung erst näher bestimmt werden müssen
Fälle, wo ich der Meinung bin, dazu beitragen zu können, dass die Bearbeitung besser verläuft
Break&Fix-Fälle, bei denen ich mir zutraue, das Problem in angemessener Zeit selbst lösen zu können
Allerdings bearbeite ich nicht alle Support-Fälle selbst. In folgenden Fällen überlasse ich dies unseren Spezialisten aus den unterschiedlichen Support-Bereichen:
Es handelt es sich um ein Thema, von dem ich selbst so gar keine Ahnung habe
Ich bin ausgelastet und kann mich nicht in angemessener Zeit und notwendigen Umfang um den Fall kümmern
Kunden haben bereits mit ihrer RHEL-Subskription den Support erworben, der ihnen im Fehlerfall hilft. Als TAM bin ich bestrebt, Support-Fälle dann zu bearbeiten, wenn ich für den Kunden dadurch einen Mehrwert bieten kann. Dies ist nicht der Fall, wenn ich nur als Durchlauferhitzer oder zusätzliches Glied in der Stille-Post-Kette beteiligt bin. Jedoch habe ich auch ein Auge auf die Cases meiner TAM-Kontakte, die ich nicht selbst bearbeite. Ich teile in diesen Fällen häufig Informationen über die Umgebung des Kunden und den Einfluss des Problems auf die Geschäftsprozesse, welche ich in meinen Abstimmungsterminen mit dem Kunden gesammelt habe.
TL;DR: Ich bearbeite Support-Fälle dann, wenn ich dadurch einen Mehrwert für meine Kunden bieten kann.
Exkurs Ende.
Der Montag Vormittag ist in aller Regel eher ruhig. Daher nutze ich die Zeit für Themen, die ich in Ruhe bearbeiten möchte. Darunter fallen Dinge wie:
Erstellen von Laborumgebungen
Durchführung verschiedener Use Cases im Labor
Erstellung von Demos
Arbeit ein Vorträgen und Dokumenten
Persönliche Fort- und Weiterbildung
Arbeit an Themen von meiner ToDo-Liste
Diese Woche war es wirklich ein sehr ruhiger Montag. Ich habe eine Übergabe an meine Vertretung für einen Kunden organisiert und Account-Informationen aktualisiert. Mein Posteingang, ToDo-Liste und Check-Status sind bearbeitet und bei den Kontakten in der WaitingOnReply-Box habe ich um ein Update ersucht. Heute war ein schöner Tag. :-)
Dienstag
Der Dienstag begann mit einem TAM-Team-Meeting. Vorbildlich mit Agedna, Moderator, Protokollant und Zeitwächter. Dies haben wir alle zwei Wochen, wenn es Themen gibt. Die Stimmung war gut. So bin ich gut gelaunt in den Tag gestartet.
Mit dem Daily Stand-up und einem Abstimmungsmeeting zu unserem Vortrag auf dem Summit Connect Darmstadt hatte ich noch zwei weitere Meetings am Vormittag.
Daneben standen heute insgesamt 3,5 Stunden Focus Time in meinem Kalender. Dabei handelt es sich um Zeiten, die ich mir reserviere, um konzentriert an Themen zu arbeiten. Heute habe ich die Zeit genutzt, um:
Die Agenda für einen TAM-Call zu erstellen und die Themen für diesen vorzubereiten
Die Demo für den Summit Connect vorzubereiten und zu testen
Am Ende des Tages die Out-of-Office-Procedure durchzugehen, ohne wichtige Schritte zu vergessen
Das besondere an Focus Time ist bei uns, dass weitere Termineinladungen, die in die Focus Time fallen, automatisch abgelehnt werden und man im Chat als beschäftigt markiert ist. Dies wird von den allermeisten Kollegen respektiert und man kann in Ruhe arbeiten.
Zwischendurch habe ich nach offenen Support-Cases geschaut und Informationen ergänzt. Manchmal reagieren Kunden nicht auf Updates im Support-Portal. Wenn ich dies feststelle, kontaktiere ich sie per E-Mail und informiere über Updates und stelle sicher, dass auf beiden Seiten die gleiche Erwartungshaltung zum Verlauf der Bearbeitung existiert.
Mittwoch
Der Tag begann um Punkt 09:00 Uhr einem Quarterly Service Review für einen unserer Kunden. Hier präsentieren meine TAM-Kollegen und ich, was wir im letzten Quartal für unseren Kunden geleistet haben und gleichen dies mit der Wahrnehmung unseres Kunden ab. Der Termin endete mit einer Aussicht auf das laufende Quartal.
Danach hieß es für mich meine Sachen zu packen, denn heute stand noch die Reise nach Darmstadt auf dem Programm. Ich bin mit der Bahn gereist, da ich so im Zug arbeiten konnte.
Damit meinen Kunden während meiner Reise und Teilnahme am Summit Connect der TAM-Service in gewohnter Weise zur Verfügung steht, habe ich mir im Vorfeld Vertretungen für meine Kunden organisiert.
Während der Bahnfahrt habe ich einen TAM-Call durchgeführt. Dies war nicht optimal, aber besser, als den Termin ausfallen zu lassen. Während eines TAM-Call bespreche ich mit Kunden aktuelle Themen wie offene Support-Cases, anstehende Changes und Projekte, Trainingsbedarf, etc. Er dient der Abstimmung untereinander und Planung der nächsten Schritte.
Mit 45 Minuten Verspätung erreichte ich am Abend Darmstadt Hbf. Nun hieß es schnell im Hotel einchecken und zum Abendessen eilen.
Den Abend verbrachte ich in angenehmer Atmosphäre mit tollen Kollegen. Es war schön, sie mal wieder persönlich zu treffen.
Vier Stichpunkte, die mich von 08:00-23:00 Uhr beschäftigt haben. Es hat sich aus meiner Sicht gelohnt. Unser Vortrag kam trotz der Kürze der Zeit gut an und ich habe einige Kunden das erste Mal in der Realität getroffen (und erst gar nicht wiedererkannt).
Freitag
Heimreise mit der Bahn. Während der Fahrt in verschiedenen Zügen habe ich mit einem Support-Engineer und meinem Kunden zusammen an einem kniffligen Case gearbeitet, Life-Cycle- und Support-Dokumente geprüft, die Folien zum Quarterly Service Review vom Mittwoch an den betreffenden Empfängerkreis verteilt sowie abgelegt und an diesem Blog-Post geschrieben.
Die Kunden bekommen meist gar nicht mit, wie viel hinter dem Support-Ticket kommuniziert wird. Mir macht es Spaß auch mal über knifflige Problem zusammen mit Kollegen nachzudenken, nach Lösungen und Workarounds zu suchen.
Die ungeplante Verlängerung der Reisezeit nutzte ich, um mein Compliance & Ethics Training abzuschließen. Damit ist dieser Punkt auch erledigt.
Mit 3 Stunden Verspätung, was mich tierisch genervt hat, bin ich daheim bei meiner Familie angekommen, was mich dann sehr gefreut hat.
Fazit
Eine spannende und anstrengende Woche ist vorbei. Ich hoffe ich konnte euch einen kleinen Einblick in eine nicht ganz normale Woche meiner Arbeit geben.
In diesem Artikel stelle ich euch die RHEL System Rolenbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese:
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
Einem Ansible-Controller (RHEL 9) mit den Paketen
ansible-core
rhel-system-roles
Jeweils einem RHEL 8 und RHEL 9 Server mit Minimalinstallation und einem LUKS-Gerät (/dev/sdc in den Beispielen in diesem Text)
Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Anwendungsfall
In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.
Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.
Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.
Das Playbook
Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.
Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.
Der erste Task stellt sicher, dass das Netzwerkinterface aktiviert und mit einer IP-Adresse konfiguriert wird; dies ist notwendig, um den Tang-Server kontaktieren zu können, da in dem genutzten Netzwerk-Segment kein DHCP verfügbar ist; Solltet ihr ein Netzwerk-Segment nutzen, in dem DHCP zur Verfügung steht, kann der erste Task entfallen
Um das LUKS-Device für NBDE zu konfigurieren wird die LUKS-Passphrase benötigt, welche in der Variablen luks_password steckt
Ich empfehle die Variable luks_password mit ansible-vault vor neugierigen Blicken zu schützen
Durch password_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurde
Achtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.
Fazit
Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.
In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.
Anmelden
