Red Hat baut die Red Hat Ansible Automation Platform zum zentralen „Trusted Execution Layer“ für KI-gestützte Prozesse aus.

…dann können keine Ansible-Playbooks auf dem Zielsystem ausgeführt werden, Sysadmins lassen vom Schreiben der Playbooks ab und wenden sich der Fehleranalyse zu. Genau das mache ich nämlich gerade.

Und damit ihr auch etwas davon habt, halte ich das Ganze in diesen Beitrag fest. Die Gründe dafür sind vielfältig:

• Unerfahrene Sysadmins können lernen, wie man bei einer Fehleranalyse vorgehen kann, um nach endlich vielen Schritten zu einem Ergebnis zu kommen
• Falls ich meine Arbeit unterbrechen muss, kann ich mich mithilfe dieses Textes besser erinnern, was ich schon getestet habe und meine Arbeit fortsetzen
• Falls ich Expertenrat einholen muss, kann ich zeigen, was ich schon alles versucht habe

Die erfahrenen Supporter und Sysadmins unter euch sind gerne eingeladen, in den Kommentaren zu ergänzen, wie ihr bei so einem Problem vorgeht und was ich hätte besser machen können. So lernen wir alle etwas dabei.

Die Methode

Bei einer Fehleranalyse stochert man nicht einfach im Heuhaufen herum, in der Hoffnung eine Nadel zu finden. Ich gehe während der Fehleranalyse in folgender Schleife (Pseudocode) vor:

Solange das Problem besteht:
  Sichte und bewerte die vorhandenen Informationen;
  Forumuliere eine Hypothese zur Ursache des Problems;
  Überprüfe die Hypothese;
  Hast du damit das Problem gefunden, stelle es ab und höre auf;
  Hast du das Problem damit noch nicht gefunden, nimm die gewonnenen Erkenntnisse und iteriere;

Das Problem

$ ansible -i hosts host.example.com -m ping
host.example.com | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "module_stderr": "Shared connection to host.example.com closed.\r\n",
    "module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757269581.9965136-5304-74956742819711/AnsiballZ_ping.py': [Errno 1] Operation not permitted\r\n",
    "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error",
    "rc": 2
}

Der obige Code-Block zeigt das fehlgeschlagene Ansible-Ad-hoc-Kommando. Das Kommando führt das Module ansible.builtin.ping aus, welches prüft, ob eine Verbindung zum Zielsystem hergestellt werden kann und eine nutzbare Python-Umgebung gefunden wird. Wenn dies erfolgreich ist, sieht die Ausgabe wie im folgenden Code-Block aus:

$ ansible -i hosts host2.example.com -m ping
host2.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "ping": "pong"
}

Die Ausgangslage

Bevor ich mit der Fehleranalyse beginne, schreibe ich auf, was ich über meinen Ansible Control Node und meine beiden Managed Nodes weiß.

Ansible Control Node

• Fedora release 42 (Adams)
• ansible [core 2.18.6]
  • config file = /etc/ansible/ansible.cfg
  • ansible python module location = /usr/lib/python3.13/site-packages/ansible
  • executable location = /usr/bin/ansible
  • python version = 3.13.7 (main, Aug 14 2025, 00:00:00) GCC 15.2.1 20250808 (Red Hat 15.2.1-1)
  • jinja version = 3.1.6
  • libyaml = True

Ansible Managed Nodes

Über host.example.com und host2.example.com ist bekannt, dass es:

• sich um Red Hat Enterprise Linux release 9.6 (Plow) handelt
• Ich mich mit dem User tronde und SSH-Private-Key einloggen kann
  • Bei tronde handelt es sich um einen unprivilegierten Benutzer
  • Dieser darf sudo nutzen, um seine Rechte auszuweiten; dazu muss ein Passwort eingegeben werden
• SELinux auf Enforcing steht

Die Fehlermeldung

Und ich habe natürlich eine Fehlermeldung:

"module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757269581.9965136-5304-74956742819711/AnsiballZ_ping.py': [Errno 1] Operation not permitted\r\n",

Python meldet, dass die Ausführung von AnsiballZ_ping.py nicht zugelassen ist.

Hypothese 1: Es liegt nicht an AnsiballZ_ping.py

Wenn dieses Python-Skript nicht ausgeführt werden kann, kann ein anderes Python-Skript ebenfalls nicht ausgeführt weden. Um diese Hypothese zur überprüfen, versuche ich, die UID des Benutzers mit dem Modul ansible.builtin.command abzufragen:

$ ansible -i hosts host.example.com -m command -a 'id'
host.example.com | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "module_stderr": "Shared connection to host.example.com closed.\r\n",
    "module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757271016.543905-6189-111082369101490/AnsiballZ_command.py': [Errno 1] Operation not permitted\r\n",
    "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error",
    "rc": 2
}

Damit ist bewiesen, dass die Fehlerursache nicht allein im Skript AnsiballZ_ping.py liegt.

Hypothese 2: Es ist ein Problem mit Berechtigungen

Die Meldung [Errno 1] Operation not permitted deutet an, dass fehlende Berechtigungen die Ursache sein können. Also führe ich das Kommando auf dem betroffenen Managed Node einmal als root aus.

$ ansible -i hosts host.example.com -m ping -b -K
BECOME password: 
host.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "ping": "pong"
}

Root darf also, was tronde nicht darf, denn mit erweiterten Berechtigungen kann das Kommando erfolgreich ausgeführt werden. Die Python-Skripte, die tronde nicht ausführen darf, liegen im Pfad /home/tronde/.ansible/tmp/<von-Ansible-temporär-erstelltes-Verzeichnis>/AnsiballZ_{command,ping}.py.

Hypothese 3: tronde darf keine Python-Skripte ausführen

Genauer gesagt, tronde darf keine Python-Skripte ausführen, welche unterhalb von /home/tronde/.ansible/tmp/ abgelegt sind. Auch diese These wird direkt geprüft. Dazu logge ich mich per SSH als User tronde auf dem Zielsystem ein, erstelle ein einfaches Python-Skript und versuche dieses auszuführen:

$ mkdir /home/tronde/.ansible/tmp/test
$ cat << EOF > /home/tronde/.ansible/tmp/test/hello.py
> #!/usr/bin/env python3.9
> print("Hello World")
> EOF
$ chmod u+x /home/tronde/.ansible/tmp/test/hello.py
$ /usr/bin/python3.9 /home/tronde/.ansible/tmp/test/hello.py
/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/test/hello.py': [Errno 1] Operation not permitted

Durch diesen Test habe die Hypothese verifiziert und zusätzlich folgendes gelernt: Meine Ansible-Konfiguration auf meinem Ansible Control Node hat nichts mit dem Problem zu tun, da das Problem auftritt, wenn Ansible gar nicht beteiligt ist.

Hypothese 4: Falsche Datei-Berechigungen verhindern die Ausführung der Datei

Ich schaue mir die Datei-Berechtigungen bis zur Datei hello.py mit dem Programm namei(1) an:

$ namei -mo /home/tronde/.ansible/tmp/test/hello.py
f: /home/tronde/.ansible/tmp/test/hello.py
 dr-xr-xr-x root      root      /
 drwxr-xr-x root      root      home
 drwxr-x--- tronde tronde tronde
 drwxrwxr-x tronde tronde .ansible
 drwx------ tronde tronde tmp
 drwxr-xr-x tronde tronde test
 -rwxr--r-- tronde tronde hello.py

Das sieht auf den ersten Blick nicht verkehrt aus. Ich wechsel in das Verzeichnis und lasse mir die Attribute der Datei mit verschiedenen Programmen anzeigen.

$ cd .ansible/tmp/test/
$ stat hello.py
  File: hello.py
  Size: 46        	Blocks: 8          IO Block: 4096   regular file
Device: fd06h/64774d	Inode: 51511298    Links: 1
Access: (0744/-rwxr--r--)  Uid: ( 1000/tronde)   Gid: ( 1000/tronde)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2025-09-07 21:21:08.201875001 +0200
Modify: 2025-09-07 21:23:04.564787755 +0200
Change: 2025-09-07 21:23:25.642771941 +0200
 Birth: 2025-09-07 21:21:08.201875001 +0200

$ getfacl hello.py
# file: hello.py
# owner: tronde
# group: tronde
user::rwx
group::r--
other::r--

$ file hello.py 
hello.py: writable, executable, regular file, no read permission

Datei-Berechtigungen und Linux-ACL bescheinigen dem User tronde Lesezugriff auf die Datei hello.py. Das file-Kommando bescheinigt jedoch no read permission.

Hypothese 5: Das chmod u+x verursacht das Problem

Nach der Erstellung des Skripts habe ich dieses mit chmod u+x ausführbar gemacht. Vielleicht verursacht erst dieser Befehl das Problem. Also schaue ich mir die Informationen zum Dateityp vor und nach dem Kommando an. Dazu erstelle ich ein neues Skript.

$ cat <<EOF >hello2.py
> #!/usr/bin/env python3.9
> print("Hello Sysadmin.")
> EOF
$ file hello2.py 
hello2.py: writable, regular file, no read permission

Damit kann ich chmod ebenfalls als Fehlerquelle ausschließen.

Hypothese 6: Shebang verursacht das Problem

Die Shebang #! sorgt dafür, dass das folgende Kommando mit dem Dateinamen als Argument ausgeführt wird. Gleichzeitig gibt die Shebang auch dem Programm file einen Hinweis darauf, um welchen Dateityp es sich handelt.

Zur Überprüfung dieser Hypothese erhebe ich zuerst die Antworten zu folgenden Fragen.

Kann das Skript ohne Shebang ausgeführt werden?

Bei der Überprüfung von Hypothese 2 habe ich verifiziert, dass root die Dateien wie gewohnt ausführen kann. Nun editiere ich die Datei hello2.py mit root-Rechten und entferne die Shebang. Anschließend versuche ich als User tronde, die Datei mit Hilfe des Python3.9-Interpreters auszuführen.

$ file hello2.py 
hello2.py: ASCII text
$ cat hello2.py 
print("Hello Sysadmin.")
$ /usr/bin/python3.9 hello2.py 
Hello Sysadmin.

Ohne Shebang kann ich das Skript ausführen. Füge ich die Shebang wieder ein, ist der Fehler zurück. Ich kann die Datei noch nicht mal mehr lesen:

$ cat hello2.py 
cat: hello2.py: Operation not permitted

$ sudo !!
sudo cat hello2.py 
#!/usr/bin/python3.9
print("Hello Sysadmin.")

Zeigen Bash-Skripte mit Shebang das gleiche Verhalten?

$ cat <<EOF >world.sh
> #!/usr/bin/env bash
> echo "Hello world."
> EOF

$ file world.sh 
world.sh: Bourne-Again shell script, ASCII text executable

$ cat world.sh 
#!/usr/bin/env bash
echo "Hello world."

$ bash world.sh 
Hello world.

$ chmod u+x world.sh

$ ./world.sh 
Hello world.

Hier ist das Verhalten wie erwartet. Damit ist zwar noch nicht sicher bewiesen, dass das Shebang-Problem mit dem Python-Interpreter zusammenhängt, es gibt aber einen ersten Hinweis.

Wie sieht die Ausgabe von file auf einem Referenzsystem aus?

Mit host2 habe ich ja ein System, das Python-Skripte ohne Fehler ausführt. Ich erstelle auch hier das hello.py-Skript inkl. Shebang und lasse mir die Ausgabe von file anzeigen:

$ cat <<EOF >hello.py
> #!/usr/bin/env python3.9
> print("Hello, world.")
> EOF

$ file hello.py 
hello.py: Python script, ASCII text executable

Hier findet sich kein Hinweis auf no read permission.

Hypothese 7: Es ist nur der User tronde betroffen

Um diese Hypothese zu prüfen, erstelle ich einen neuen Benutzer test, ein Python-Skript und prüfe, ob das Problem auftritt:

# useradd test
# su - test
$ pwd
/home/test
$ cat <<EOF >hello.py
> #!/usr/bin/env python3
> print("Hello, world.")
> EOF
$ cat hello.py 
cat: hello.py: Operation not permitted

Das Problem ist nicht auf den User tronde beschränkt. Es scheint alle nicht privilegierten User zu betreffen.

Zwischenfazit

• Das Problem scheint Host-spezifisch zu sein, da es auf einem Referenzsystem nicht auftritt
• Das Problem tritt nur auf, wenn nicht privilegierte User ein Python-Skript ausführen, welches eine Shebang enthält
  • Diese Skripte können jedoch mit root-Rechten ausgeführt werden
  • Ohne die Shebang können die Skripte mittels /usr/bin/python3 <scriptname> ausgeführt werden
• Ist eine Shebang enthalten, die einen Python-Interpreter enthält, verlieren unprivilegierte User den Lesezugriff auf die Datei (cat, less, etc. sind dann ebenfalls betroffen)
• Trage ich eine andere Shebang z.B. #!/usr/bin/bash ein, kann ich das Skript als unprivilegierter User mittels `python3 <scriptname>` korrekt ausführen

Für mich bedeutet das leider, dass ich mir nun Hilfe suchen muss, da mir die Ideen ausgehen. Also beginne ich mit einer Internetsuche nach „troubleshooting shebang in python3″… und frage anschließend eine Kollegin um Rat. Vielen lieben Dank Michi für deine Zeit und Ideen!

Die Ursache

Michi und ich haben uns in einer Videokonferenz zusammengefunden und das Problem gemeinsam untersucht. Dabei sind wir nach obigen Muster vorgegangen:

1. Genau eine Sache überprüfen
2. Ergebnis auswerten
3. Eine weitere Vermutung prüfen
4. Ergebnis auswerten usw.

Dabei haben wir uns SELinux, das Audit-Log, die Linux-ACLs, das Environment, alias, locale und die Ausgabe diverser strace-Kommandos angeschaut. Die Details spare ich an dieser Stelle ein und komme zum Wesentlichen. Michi fand diesen Foreneintrag: Non-root users unable to read perl scripts. Darin wird fapolicyd als Fehlerquelle identifiziert. Und das ist tatsächlich auch in meinem Fall der Übeltäter.

Stoppe ich fapolicyd.service, kann ich die Python-Skripte mit Shebang wieder ausführen. Starte ich den Dienst erneut, ist auch das Problem zurück. Die Ursache ist identifiziert.

Moment, was ist fapolicyd?

Das Software-Framework fapolicyd steuert die Ausführung von Anwendungen basierend auf einer benutzerdefinierten Richtlinie. Dies ist eine der effizientesten Methoden, um die Ausführung nicht vertrauenswürdiger und potenziell bösartiger Anwendungen auf dem System zu verhindern.

Übersetzung aus Introduction to fapolicyd

Die von Ansible generierten und die von mir zum Test erstellten Python-Skripte wurden in der Ausführung blockiert, da diese als nicht vertrauenswürdig eingestuft wurden.

Allerdings fällt das in diesem Fall in die Kategorie „Gut gemeint ist nicht gleich gut gemacht“. Denn während zwar der Zugriff auf Python-Skripte mit Shebang für nicht-privilegierte User blockiert wird, können Skripte ohne entsprechende Shebang weiterhin ausgeführt werden. Wirkliche Sicherheit bietet dies nicht. Ich mache mir dazu mal eine Notiz, um das beobachtete Verhalten im Nachgang mit den Entwicklern zu diskutieren. Vielleicht habe ich das Design und Konzept von fapolicyd noch nicht ganz verstanden.

Warum ich da nicht früher drauf gekommen bin

• Keine Ausgabe gab einen Hinweis darauf, dass fapolicyd die Ausführung blockiert
• Ich habe fapolicyd vor langer Zeit zum Test auf diesem Host installiert und vergessen, dass es läuft
• Durch fehlende Konfiguration gab es keine Einträge im Audit-Log, die auf die Ursache hätten hinweisen können

Wie findet man die Ursache, wenn man weiß, dass fapolicyd läuft?

Erstmal muss man wissen bzw. sich in meinem Fall daran erinnern, dass fapolicyd läuft. Dann kann man für einen schnellen Test fapolicyd.service stoppen und prüfen, ob das Problem noch besteht.

Um nun herauszufinden, warum fapolicyd die Ausführung von Python-Skripten mit Shebang blockiert, folge ich der Dokumentation in Kapitel 12.6. Troubleshooting problems related to fapolicyd. Ich stoppe fapolicyd.service und starte den Dienst mit dem Befehl fapolicyd --debug-deny. Damit werden nur Einträge ausgegeben, die blockierte Zugriffe zeigen. In diesem Modus führe ich den ursprünglichen Ansible-Ad-hoc-Befehl ansible -i hosts host.example.com -m ping aus, der wie erwartet fehlschlägt. In der Ausgabe auf host.example.com sehe ich nun:

09/08/2025 20:39:07 [ DEBUG ]: Rule number API supported yes                                            
09/08/2025 20:39:08 [ DEBUG ]: rule=11 dec=deny_audit perm=open auid=1000 pid=693342 exe=/usr/bin/python3.9 : path=/home/tronde/.ansible/tmp/ansible-tmp-1757356747.8650832-23284-14960045792104/AnsiballZ_ping.py ftype=text/x-python trust=0
09/08/2025 20:39:08 [ DEBUG ]: rule=11 dec=deny_audit perm=open auid=1000 pid=693342 exe=/usr/bin/python3.9 : path=/home/tronde/.ansible/tmp/ansible-tmp-1757356747.8650832-23284-14960045792104/AnsiballZ_ping.py ftype=text/x-python trust=0

Die Lösung

Damit ich host.example.com mit Ansible verwalten kann, muss ich die Ausführung von Python-Skripten unterhalb von /home/tronde/.ansible/tmp/ erlauben. Das dazu erforderliche Vorgehen ist in der Dokumentation in Kapitel 12.4. Adding custom allow and deny rules for fapolicyd beschrieben. Für meinen konkreten Fall sehen die einzelnen Schritte wie folgt aus:

Nach obiger Ausgabe habe ich Regel 11 (rule=11) getriggert. Also schaue ich mir zuerst an, was in Regel 11 steht und anschließend, in welcher Datei unterhalb von /etc/fapolicyd/rules.d diese Regel steht:

~]# fapolicyd-cli --list | grep 11
11. deny_audit perm=any all : ftype=%languages

~]# grep 'deny_audit perm=any all : ftype=%languages' /etc/fapolicyd/rules.d/*
/etc/fapolicyd/rules.d/70-trusted-lang.rules:deny_audit perm=any all : ftype=%languages

Anschließend erstelle ich eine Allow-Regel, in einer neuen Datei. Diese muss lexikalisch vor obiger Datei mit der Deny-Regel liegen:

~]# cat <<EOF >/etc/fapolicyd/rules.d/69-trusted-ansible-scripts.rules
> allow perm=any exe=/usr/bin/python3.9 trust=1 : dir=/home/tronde/.ansible/tmp/ trust=0
> EOF

~]# fagenrules --check
/sbin/fagenrules: Rules have changed and should be updated

~]# fagenrules --load
~]#

Anschließend führe ich zum Test folgende Kommandos aus:

1. Auf host.example.com: fapolicy --debug-deny
2. Auf meinem Ansible Control Node: $ ansible -i inventory host.example.com -m ping

Ich bestaune das gewünschte Ergebnis:

host.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Nun beende ich den Debug-Modus und starte fapolicyd.service. Fehleranalyse und Entstörung sind damit beendet.

Für welche Anwendungsfälle diese Lösung funktioniert

Die obige Lösung sorgt dafür, dass Python-Skripte unterhalb des Verzeichnisses /home/tronde/.ansible/tmp/, welche eine Python-Shebang beinhalten, mit dem Python-Interpreter /usr/bin/python3.9 ausgeführt werden können.

Diese Lösung funktioniert nicht

• Für andere unprivilegierte User außer tronde
• Für andere Python-Interpreter wie z.B. /usr/bin/python3 oder /usr/bin/python3.11

Hinterher ist man immer schlauer

Jetzt, wo ich weiß, wonach ich suchen muss, finde ich auch direkt mehrere Treffer in den Red Hat Solutions:

• Why do I get unexpected “Operation not permitted” errors when trying to access files
• No FANOTIFY event seen in the audit log despite fapolicyd blocking operations
• Fapolicyd : Configure ansible automation execution for non-root users
• [AAP] Ansible job callback get „PermissionError“ „Operation not permitted“ due to fapolicyd deny rule

Dokumentation findet sich neben der Manpage fapolicyd(8) z.B. auch im RHEL 9 Security Hardening Guide ab Kapitel 12. Mit RHELDOCS-20981 – Improve section „Deploying fapolicyd“ in RHEL Security Hardening Guide – habe ich zudem einen Verbesserungsvorschlag eingereicht.

Fazit

Dieser Text hat an einem konkreten Beispiel gezeigt, wie eine strukturierte Fehleranalyse durchgeführt wird. Diese führt über die Problembeschreibung sowie das Formulieren von Hypothesen und deren Falsifizierung/Verifizierung nach endlich vielen Schritten zu einer Lösung.

Die Länge des Textes zeigt, wie aufwändig eine Fehleranalyse werden kann. Wenn man keinen direkten Zugriff auf das betroffene System hat und mit jemandem ausschließlich über ein Ticket-System kommunizieren kann, wird schnell klar, dass sich ein Fall über mehrere Tage und Wochen hinziehen kann.

Ich war irgendwann geistig erschöpft und hatte keine Lust mehr allein weiterzumachen, da mir die Ideen ausgingen. In diesem Fall hilft es, sich einen frischen Geist zur Unterstützung zu holen. Gemeinsam mit meiner Kollegin Michi konnte die Ursache (fapolicyd) identifiziert werden.

Mit Hilfe der Dokumentation war ich dann auch in der Lage, das Problem zu lösen. Ich kann nun Ansible-Playbooks auf dem Zielsystem ausführen.

Der Dienst fapolicyd überzeugt mich nicht. Meine Gedanken dazu werde ich in einem Folgeartikel mit euch teilen.

In einem weiteren Folgeartikel werde ich darüber schreiben, was Hilfesuchende und Supporter tun können, damit beide Seiten eine möglichst gute Support-Erfahrung haben.

Ich freue mich nun über ein gelöstes Problem und schreibe an meinem Ansible-Playbook weiter.

In diesem Beitrag berichte ich über mein Wochenend-Projekt „Ansible Collection tronde.opencloud“, welche ihr seit dem 4. Mai 2025 in Version 1.0.0 auf Ansible Galaxy sowie bei Codeberg.org findet.

Ich habe die Collection mit den folgenden Zielen erstellt:

• Deployment von OpenCloud mittels Ansible in einer rootless Podman-Umgebung
• Backup der OpenCloud und Speicherung des Backups auf dem Ansible Control Node
• Restore der OpenCloud aus einem zuvor erzeugten Backup

Aktuell läuft eine OpenCloud-Instanz auf einem meiner Server unter Debian Bookworm.

Nicht so schnell! Was sind Ansible, OpenCloud und Podman?

Derjenige, dem diese Begriffe bereits geläufig sind, kann direkt zum Abschnitt Motivation springen. Für alle anderen gibt es hier eine knappe Erklärung mit Verweisen zu weiteren Informationen, um sich mit der Materie vertraut zu machen.

Ansible

Ansible hat sich zu einem beliebten Schweizer Taschenmesser für Automation, Konfigurations-Management, Deployment und Orchestrierung entwickelt. Über folgende Links findet ihr reichlich informationen dazu:

• Ansible – IT-Automation für Jedermann
• Ansible Community Documentation (Englisch)
• Ansible in der deutschsprachigen Wikipedia
• Meine Vorträge und englischsprachigen Artikel rund um Ansible

OpenCloud

OpenCloud ist die Filesharing & Kollaborations-Lösung der Heinlein Gruppe.

Durch intelligentes Datei-Management und eine starke Open Source-Community werden Dateien zu wertvollen Ressourcen – effektiv strukturiert und langfristig nutzbar.

Quelle: https://opencloud.eu/de

Links zu weiteren Informationen:

• Webseite des Projekts
• Projektseite auf GitHub (Englisch)
• Vortrag während der Chemnitzer LInux-Tage 2025: OpenCloud: Exzellentes File-Management

Podman

Podman ist ein Werkzeug zur Erstellung von Linux-Containern und der Verwaltung des gesamten Container-Lebenszyklus. Links mit Informationen zu Podman:

• Webseite (Englisch)
• What is Podman? (Englisch)
• Podman in der englischsprachigen Wikipedia
• Diverse Verweise in meiner Linksammlung

Motivation

Ich betreibe und nutze privat eine Nextcloud, um Dateien über mehrere Geräte zu synchronisieren, mit anderen zu teilen und um Backups verschiedener Geräte und Dienste darin abzulegen. Dazu betreibe ich neben dem Reverse Proxy (NGINX) einen Container mit einer MySQL-Datenbank und einen Anwendungscontainer mit Nextcloud selbst. Nextcloud verfügt über ein reichhaltiges Plugin-Ökosystem zur Erweiterung der Funktionalität, welche ich persönlich allerdings nicht benötige.

OpenCloud ist wie Nextcloud ein Fork von OwnCloud. Siehe dazu den Bericht: Opencloud forkt Owncloud — neue Wendung bei den freien Speichercloud-Versionen im Linux-Magazin vom 22. Januar 2025.

Mir gefällt, dass OpenCloud ganz ohne Datenbank auskommt und sich auf die Synchronisation und das Teilen von Daten fokussiert. Dies entspricht genau meinem Anwendungsfall. Wenn ich dadurch einen Dienst weniger betreiben kann (MySQL), ist das umso besser.

Nur passt der gewählte Technologie-Stack nicht zu meiner persönlichen Vorliebe. Während OpenCloud auf die Verwendung von Docker Compose mit Traefik als Reverse Proxy setzt, bevorzuge ich, Container mit Podman zu betreiben und verwende (noch) NGINX als Reverse Proxy.

Um OpenCloud etwas kennenzulernen, habe ich beschlossen, analog zu meiner Ansible Collection tronde.nextcloud eine Collection tronde.opencloud zu erstellen, um OpenCloud deployen und verwalten zu können.

Ob sich der Aufwand lohnt, werde ich mit der Zeit sehen. Wenn es mir zuviel wird oder ich den Gefallen daran verliere, werde ich dieses Wochenendprojekt wieder einstellen bzw. gern in die Hände motivierter Menschen geben, die es weiterführen möchten.

Informationen zur Collection

Das Wichtigste zu dieser Collection habe ich bereits zu Beginn dieses Textes geschrieben. Neben den für Ansible Collections und Roles typischen README.md-Dateien habe ich auch ein paar Zeilen Dokumentation erstellt:

• Get Started
• Backup and Restore

Die Collection steht unter einer freien Lizenz und ich gebe keinerlei Garantie oder Gewähr, dass euch deren Verwendung nicht direkt in den Untergang führt. ;-)

Die Collection kann (noch) nicht viel. Das Wenige scheint jedoch robust zu funktionieren. Wenn ihr neugierig seid, probiert sie gerne aus. Auch euer konstruktives Feedback ist mir stets willkommen.

Für mich ist dies ein Wochenend-Projekt, das mit etlichen anderen Themen um meine Zeit konkurriert. Erwartet daher keine schnellen Entwicklungsfortschritte. Wenn ihr gern daran mitwirken möchtet, bin ich dafür offen. Werft einen Blick in den kurzen Contribution Guide und legt los. Falls ihr Fragen habt oder euch mit mir über die Collection austauschen möchtet, könnt ihr

• eure Frage als Issue mit dem Label „Question“ im Repository stellen oder
• in den Matrix-Raum #My-IT-Brain posten.

Erster Eindruck von OpenCloud

Das noch recht junge Projekt macht einen aufgeräumten Eindruck. Die Benutzeroberfläche ist nicht überladen und ich finde mich schnell darin zurecht. Das Entwicklerteam antwortet bereitwillig auf Fragen und kümmert sich in angemessener Zeit um Issues. Dies ist zumindest mein subjektiver Eindruck.

Einziger Wermudstropfen ist wie so oft die Dokumentation, welche mit der Entwicklung offenbar nicht Schritt halten kann. Diese lässt leider noch viele Fragen offen, welche über GitHub Discussions oder Suche im Quelltext geklärt werden können/müssen. Ich empfinde dies etwas ermüdend und es drückt die Motivation.

Nun werde ich OpenCloud erstmal einige Zeit nutzen und ein paar Versions-Upgrades hinter mich bringen. Anschließend werde ich dann einen Meinungsartikel schreiben, wie es mir gefällt.

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.

https://de.wikipedia.org/wiki/Lint_(Programmierwerkzeug)

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.

Wie wird Ansible Lint installiert?

Die Dokumentation beschreibt verschiedene Installationsverfahren. Ich habe ansible-lint als Bestandteil der Ansible Development Tools (ADT) installiert. Dies ist ein Werkzeugkasten mit weiteren Programmen wie z.B. `ansible-core` und Ansible Molecule, welche ich für die Entwicklung meiner Ansible Collection nutze.

Auf meiner Fedora Workstation habe ich die ADT wie folgt installiert:

~]$ mkdir venv
~]$ cd venv
venv]$ ]$ python -m venv adt
venv]$ source adt/bin/activate
(adt) venv]$ pip install pip --upgrade
Requirement already satisfied: pip in ./adt/lib64/python3.12/site-packages (23.3.2)
Collecting pip
  Using cached pip-24.2-py3-none-any.whl.metadata (3.6 kB)
Using cached pip-24.2-py3-none-any.whl (1.8 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 23.3.2
    Uninstalling pip-23.3.2:
      Successfully uninstalled pip-23.3.2
Successfully installed pip-24.2
(adt) venv]$  pip install ansible-dev-tools
Collecting ansible-dev-tools
  Using cached ansible_dev_tools-24.7.2-py3-none-any.whl.metadata (11 kB)
… Ausgabe gekürzt
(adt) venv]$ adt --version
ansible-builder                          3.1.0
ansible-core                             2.17.3
ansible-creator                          24.7.1
ansible-dev-environment                  24.7.0
ansible-dev-tools                        24.7.2
ansible-lint                             24.7.0
ansible-navigator                        24.8.0
ansible-sign                             0.1.1
molecule                                 24.8.0
pytest-ansible                           24.8.0
tox-ansible                              24.8.0

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:

• Quoting von Strings
• Einrückung von Kommentaren

Als Nächstes sehe ich mir die übrigen Fehler der Reihe nach an. Die Dokumentation beinhaltet eine Übersicht mit Beschreibungen der einzelnen Regeln. Dies ist nützlich, wenn der kurze Text in der Ausgabe von ansible-lint nicht ausreichend ist.

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.

 41     - name: Import tarball contents into an existing podman volume
 42       ansible.builtin.command:
 43         cmd: |
 44           podman volume import
 45           {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
 46       loop:
 47         - "{{ NC_HTML }}"
 48         - "{{ NC_APPS }}"
 49         - "{{ NC_CONFIG }}"
 50         - "{{ NC_DATA }}"
 51         - "{{ MYSQL_DATA }}"
 52            
 53 # I need to use the command module as the volume module lacks the functionality
 54 # to export podman volumes.
 55 - name: Export podman volumes to tarballs
 56   ansible.builtin.command:
 57     cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
 58   loop:    
 59     - "{{ NC_HTML }}"
 60     - "{{ NC_APPS }}"
 61     - "{{ NC_CONFIG }}"
 62     - "{{ NC_DATA }}"
 63     - "{{ MYSQL_DATA }}"
 64   tags:    
 65     - never
 66     - backup

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:

 41     - name: Import tarball contents into an existing podman volume
 42       ansible.builtin.command:
 43         cmd: |
 44           podman volume import
 45           {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
 46       register: __import_tar_output
 47       changed_when: __import_tar_output.rc == 0
 48       failed_when: __import_tar_output.rc != 0
 49       loop:
 50         - "{{ NC_HTML }}"
 51         - "{{ NC_APPS }}"
 52         - "{{ NC_CONFIG }}"
 53         - "{{ NC_DATA }}"
 54         - "{{ MYSQL_DATA }}"
 55  
 56 # I need to use the command module as the volume module lacks the functionality
 57 # to export podman volumes.
 58 - name: Export podman volumes to tarballs
 59   ansible.builtin.command:
 60     cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
 61   register: __import_tar_output
 62   changed_when: __import_tar_output.rc == 0
 63   failed_when: __import_tar_output.rc != 0
 64   loop:
 65     - "{{ NC_HTML }}"
 66     - "{{ NC_APPS }}"
 67     - "{{ NC_CONFIG }}"
 68     - "{{ NC_DATA }}"
 69     - "{{ MYSQL_DATA }}"
 70   tags:
 71     - never
 72     - backup

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:

nextcloud]$ cat .ansible-lint-ignore 
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml var-naming[pattern]
roles/backup_restore_nextcloud/defaults/main.yml var-naming[pattern]

Zweiter Durchgang mit ansible-lint

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.

Quellen und weiterführende Links

• Ansible Lint Documentation
• Ansible Lint Rules
• Ansible Lint Profiles
• Ansible Development Tools (ADT)
• Ansible Molecule

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:

• Ansible Content Collections
• Using Ansible collections
• Developing collections

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.

Die Entwicklung der hier beschriebenen Collection könnt ihr auf Codeberg.org verfolgen. Die Repo-URL lautet: https://codeberg.org/Tronde/nextcloud

Motivation

Für mein Wochenendprojekt „Nextcloud im Container“ habe ich eine Ansible-Rolle entwickelt und auf Github veröffentlicht, die dem Zweck dient, Nextcloud mit einer MariaDB in einer rootless Podman-Umgebung zu installieren.

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:

]$ python -m venv adt
]$ . adt/bin/activate
(adt) ]$ pip install --upgrade pip
(adt) ]$ pip install ansible-dev-tools
(adt) ]$ pip install molecule-podman
(adt) ]$ adt --version
ansible-builder                          3.1.0
ansible-core                             2.17.1
ansible-creator                          24.7.0
ansible-dev-environment                  24.7.0
ansible-dev-tools                        24.7.1
ansible-lint                             24.7.0
ansible-navigator                        24.7.0
ansible-sign                             0.1.1
molecule                                 24.7.0
pytest-ansible                           24.7.0
tox-ansible                              24.7.0

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:

extensions]$ cat molecule/default/converge.yml 
---
- name: Converge
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Test collection role deploy_nextcloud_with_mariadb_pod
      ansible.builtin.import_role:
        name: tronde.nextcloud.deploy_nextcloud_with_mariadb_pod

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:

1. Den Pod ˋnc_podˋ inkl. aller darin enthaltenen Container stoppen
2. Alle zum Setup gehörenden Podman Volumes in Tarballs exportieren
3. Diese Tarballs vom managed Node auf den Control Node sichern
4. Den ˋnc_podˋ wieder starten

Die Wiederherstellung läuft sinngemäß andersherum ab:

1. Die Tarballs werden vom Control Node auf den Managed Node kopiert
2. Der Pod ˋnc_podˋ inkl. aller darin enthaltenen Container wird gestoppt
3. Die Podman Volumes aus Schritt 1 werden importiert
4. Der nc_pod wird wieder gestartet
5. 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:

ansible_collections]$ tree -L 2 tronde/nextcloud/roles/backup_restore_nextcloud/
tronde/nextcloud/roles/backup_restore_nextcloud/
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

9 directories, 8 files

Den aktuellen Entwicklungsstand könnt ihr unter dieser URL einsehen: https://codeberg.org/Tronde/nextcloud/src/branch/main/roles/backup_restore_nextcloud

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.

Wo Variablen definiert werden können und welche Präzedenz diese besitzen, kann in der offiziellen Doku nachgelesen werden: Variable precedence: Where should I put a variable?

Zusammenfassung

Eine Ansible-Rolle ohne Plug-ins in eine Ansible Collection zu überführen, ist mit dem kurzen Abschnitt aus der Dokumentation schnell erledigt.

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

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.