Die offizielle Distribution für den Raspberry Pi basiert jetzt auf Debian 13 alias Trixie.

Die offizielle Distribution für den Raspberry Pi basiert jetzt auf Debian 13 alias Trixie.

Die in den letzten Monaten gestiegenen Preise für Arbeitsspeicher wirken sich jetzt auch auf den Raspberry Pi aus: Einige Modelle kosten ab sofort bis zu 10 US-Dollar mehr.

Die in den letzten Monaten gestiegenen Preise für Arbeitsspeicher wirken sich jetzt auch auf den Raspberry Pi aus: Einige Modelle kosten ab sofort bis zu 10 US-Dollar mehr.

Immich, die gefeierte Fotoverwaltung zum Selbsthosten, hat gerade nach über drei Jahren Entwicklung die erste stabile Version Immichv 2.0 freigegeben.

Das Fedora Projekt gehört zu den wichtigsten Säulen der Linux Welt. Es liefert eine moderne, gemeinschaftlich entwickelte Distribution und dient als Grundlage für Red Hat Enterprise Linux. Jetzt beschäftigt sich das Projekt mit einer aktuellen Herausforderung: Wie lassen sich KI Werkzeuge verantwortungsvoll in offene Entwicklungsprozesse integrieren? Nach einem Jahr intensiver Diskussion hat der Fedora Rat […]

Der Beitrag Fedora Projekt stellt Entwurf für KI-Richtlinien vor erschien zuerst auf fosstopia.

Immer mehr europäische Staaten ziehen Konsequenzen aus der Abhängigkeit von US-amerikanischen IT-Diensten. Nach Dänemark und Deutschland hat nun auch Österreich reagiert. Das Bundesheer hat im September alle seine 16.000 Arbeitsplätze von Microsoft Office auf LibreOffice umgestellt. Damit folgt das österreichische Militär einem wachsenden Trend hin zu offenen, souveränen Lösungen im öffentlichen Sektor. Die Entscheidung fiel […]

Der Beitrag Österreichs Bundesheer setzt auf LibreOffice: Ein Schritt zur digitalen Unabhängigkeit erschien zuerst auf fosstopia.

openSUSE Leap 16.0 ist ab sofort verfügbar. Nach einem Jahr Entwicklung bringt die neue Version zahlreiche Neuerungen. Sie basiert auf dem aktuellen Linux Kernel 6.12 und richtet sich an private wie professionelle Nutzer. Die Beta erschien im April, der Release Candidate folgte im August. Nun ist die stabile Version offiziell freigegeben. Leap 16 bleibt eng […]

Der Beitrag openSUSE Leap 16.0 veröffentlicht: Moderne Technik und klare Ausrichtung erschien zuerst auf fosstopia.

Die UBports Foundation hat das neue Update für Ubuntu Touch veröffentlicht. Version OTA 10 bringt viele kleine Verbesserungen und erweitert die Geräteunterstützung. Das System basiert weiterhin auf Ubuntu 20.04 und richtet sich an Nutzer, die freie Software auch auf dem Smartphone schätzen. Im Zentrum des Updates steht ein neuer Upgrader. Dieses Werkzeug soll künftig den […]

Der Beitrag Ubuntu Touch OTA 10: Neue Geräte, stabile Basis für die Zukunft erschien zuerst auf fosstopia.

Kurz notiert: in den letzten beiden Tagen gab es einige Nachrichten vom Linux-Kernel.

Zuallererst wurde der Kernel in Version 6.17 veröffentlicht. Die Änderungen führen einerseits bessere Steueroption zur Auswahl von Prozessormitigationen, Live-Patching auf 64-Bit Arm sowie einige Verbesserungen an Dateisystemen wie ext4 und Btrfs ein. Die historische Sonderbehandlung von Einprozessorsystemen (ohne SMP) wird rückgebaut. Wer an allen Änderungen im Detail interessiert ist, kann einen Blick in die entsprechenden LWN Artikel oder bei LinuxNews werfen.

Apropos Dateisysteme: das jüngst aufgenommene bcachefs, um das sich vor und während seines Aufenthaltes im Mainline-Zweig viele kontroverse Diskussionen ergaben, wird Mainline im nächsten Release (6.18) voraussichtlich wieder verlassen. Torvalds kündigte im Commit zur Entfernung an, dass es als DKMS-Paket ausgeliefert werden soll.

Damit endet allerdings sicherlich auch die Maßgabe, dass die Module, von denen bcachefs abhängig ist, auf das Dateisystem abgestimmt werden. Hier gab es genau Streit, weil die Änderungen, die Kent Overstreet erwartet hatte, von den zuständigen Maintainern äußerst kritisch aufgenommen wurden. Ob die Änderungen in den anderen Modulen nun wieder zurückgesetzt werden, bleibt abzusehen.

Stackable, der Hersteller einer weltweit genutzten Open Source Data Platform, feiert 5-jährigen Geburtstag. Am 30.September 2020, mitten im Corona-Lockdown, haben Lars Francke und Sönke Liebau das Unternehmen gegründet. U.a. gibt es zum Jubiläum am 23. Oktober ein Anwendertreffen in München.

Quelle

25 Jahre X-Net - stolz blicken wir auf eine lange und erfolgreiche Firmengeschichte zurück. Zu diesem Anlass lud die X-Net zu einer Pressekonferenz zum Thema - Regionalität und Innovation stärken Digital-Standort Oberösterreich - Datensouveränität und IT-Know-how vor Ort entscheidende Faktoren - mit prominenten Teilnehmern aus der Politik und Wirtschaft ein.

Quelle

Mozilla hat Firefox 143.0.3 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion. Auch mehrere Sicherheitslücken wurden behoben.

Download Mozilla Firefox 143.0.3

Mozilla hat Firefox 143.0.3 für Windows, macOS und Linux veröffentlicht. Firefox 143.0.2 wurde für diese Plattformen übersprungen, da diese Versionsnummer einem Android-Update vorbehalten war.

Mit dem Update auf Firefox 143.0.3 behebt Mozilla zwei Sicherheitslücken.

Die Verzögerung, um einen Tab per Drag and Drop an den linken Rand der Tableiste anzuheften, wurde standardmäßig von 350 auf 500 ms erhöht, um die Wahrscheinlichkeit für versehentliches Anheften zu reduzieren, und kann außerdem ab sofort via about:config angepasst werden (browser.tabs.dragDrop.pinInteractionCue.delayMS).

Die Option dom.webgpu.enabled in about:config kann jetzt auch in finalen Firefox-Versionen aktiviert werden, um den WebGPU-Standard zu aktivieren. Die Implementierung ist zwar noch nicht vollständig, aber durch die kürzliche Aktivierung in Safari ist ein erhöhter Bedarf für Entwickler entstanden, das Feature auch in Firefox testen zu können.

Das Aktualisieren mancher Erweiterungen via about:addons war nicht mehr möglich. Außerdem konnte das Öffnen der Einstellungen einer Erweiterung über den Dialog, der nach dessen Installation erschien, dazu führen, dass manche Browser-Funktionen wie beispielsweise Tastatur-Befehle bis zum Neustart des Browsers nicht mehr im gleichen Fenster funktionierten. Ebenfalls in Zusammenhang mit Erweiterungen steht die Korrektur eines Problems, bei dem die gespeicherten Daten einer Erweiterung einen Firefox-Absturz bei Programmstart verursachen konnten.

Ein Performance-Problem beim Laden mancher Websites wurde behoben, welches auftreten konnte, wenn man mit einem Netzwerk verbunden ist, welches UDP-Verbindungen blockiert.

Auf dem Bildschirm Firefox View war es nicht länger möglich, einzelne Bereiche einzuklappen.

Bereits in Firefox 143.0.1 wurde eine injizierte DLL-Datei der Sicherheits-Software von Trend Micro in einer bestimmten Version blockiert, weil diese Firefox-Abstürze verursachte. Aufgrund fehlender Rückmeldung von Trend Micro wurden jetzt auch alle zukünftigen Versionen blockiert. Außerdem wurde eine DLL-Datei der Meta Quest Link App blockiert, weil diese Abstürze bei der Verwendung von WebRTC verursachte.

Dazu kommen eine Korrektur für Nutzer vertikaler Tabs, Korrekturen für vier weitere potenzielle Absturzursachen sowie mehrere Verbesserungen, die in Zusammenhang mit einem geplanten VPN-Experiment stehen und eine Verbesserung für ein geplantes Experiment für einen verbesserten Algorithmus der Adressleisten-Vorschläge.

Der Beitrag Mozilla veröffentlicht Sicherheits-Update Firefox 143.0.3 erschien zuerst auf soeren-hentzschel.at.

In den letzten zwei Jahrzehnten hat Open Source die Art und Weise, wie Software entwickelt wird, revolutioniert. Jede moderne Anwendung, egal ob sie in Java, JavaScript, Python, Rust, PHP oder anderen Sprachen geschrieben ist, braucht öffentliche Paket-Registries wie Maven Central, PyPI, crates.io und open-vsx, um Abhängigkeiten abzurufen, zu verbreiten und zu validieren. Diese Registries sind zu einer grundlegenden digitalen Infrastruktur geworden – nicht nur für Open Source, sondern für die gesamte globale Software-Lieferkette.

Quelle

In unserem Nachbarland Luxembourg gibt es schon seit vielen Jahren eine starke Bewegung im Open Source Bereich. Früh wurde erkannt, welche enormen Vorteile es mit sich bringt, wenn man auf dieses Entwicklungsmodell mit seinen freien Lizenzen setzt. Auch von staatlicher Seite gab es reichliche Unterstützung. Und so ist es nicht verwunderlich, dass sich viele große Akteure zu einer Konferenz treffen.

Quelle

Die Heinlein Gruppe, Anbieter der souveränen Kommunikationslösungen mailbox, OpenTalk und OpenCloud, erweitert ihre Geschäftsführung: Jutta Horstmann übernimmt ab dem 15. September 2025 die Rolle der Co-CEO an der Seite von Unternehmensgründer Peer Heinlein. Mit der neuen Doppelspitze verstärkt die Heinlein Gruppe ihre strategische Ausrichtung als aktiver Gestalter technologischer Resilienz und digitaler Unabhängigkeit für Deutschland und Europa.

Quelle

mailbox.org, ein führender deutscher Anbieter für sichere digitale Kommunikation, präsentiert sich nach einem umfassenden technischen und visuellen Relaunch als ganzheitlicher digital souveräner Arbeitsplatz. Aus dem bekannten und sicheren E-Mail-Service ist unter dem vereinfachten Namen „mailbox“ eine integrierte Plattform entstanden, die alle Aspekte moderner Kommunikation im Arbeitsalltag vereint und dabei konsequent auf europäische Datenschutzstandards und digitale Souveränität setzt.

Quelle

Adfinis, ein führender Dienstleister für Open-Source-IT-Lösungen, feiert sein 25-jähriges Jubiläum. Das Management-Team von Adfinis hat aus einem kleinen Schweizer Start-up ein internationales Unternehmen mit Präsenz in sechs Ländern entwickelt. Es fordert eine stärkere Fokussierung auf offene Technologien und digitale Souveränität. Dies sind entscheidende Bausteine, um Vertrauen in die kommende Welle digitaler und KI-nativer Produkte zu schaffen.

Quelle

Die Digitalisierung setzt sich auch in Deutschland weiter durch – langsam, manchmal stockend, aber unaufhaltsam. Mit ihr steigt nicht nur die Effizienz, sondern auch die Verwundbarkeit. Allein 2024 zählte das Bundeskriminalamt über 130.000 Fälle von Cybercrime. Für Banken und Versicherungen kann ein erfolgreicher Angriff binnen Stunden Schäden in Milliardenhöhe verursachen. Der Finanzsektor gilt deshalb als kritische Infrastruktur. Und genau hier greift die neue EU-Verordnung DORA – der Digital Operational Resilience Act. Vor allem die darin enthaltenen Regularien zu Exit-Strategien sind sehr anspruchsvoll. Dabei können diese ein Weg zu größerer Souveränität sein.

Quelle

Auf großer Bühne wurden auf dem Sovereign Cloud Stack Summit am 24. September 2025 feierlich die ersten Zertifikate verliehen. Die ausgezeichneten Unternehmen beweisen, dass Marktbegleiter gemeinsam Standards für hochmoderne, offene und digital souveräne Cloud-Lösungen entwickeln können, von denen alle gleichermaßen profitieren.

Quelle

Der Linux-Kernel 6.17 ist offiziell erschienen. Linus Torvalds selbst hat die Veröffentlichung angekündigt. Das neue Release bringt zahlreiche Neuerungen mit sich. Besonders im Bereich Hardware-Unterstützung wurde viel getan. Zu den technischen Highlights zählt unter anderem der Support für ARM BRBE. Auch AMDs Hardware Feedback Interface wird jetzt unterstützt. Intel-Prozessoren wie Wildcat Lake und Bartlett Lake-S […]

Der Beitrag Linux 6.17 ist da: Neuer Kernel bringt starke Verbesserungen erschien zuerst auf fosstopia.

Es ist soweit. System76 hat die Beta von Pop! OS 24.04 LTS vorgestellt und gibt damit erstmals einen Blick auf die nächste langfristig unterstützte Version. Im Mittelpunkt steht der neue COSMIC Desktop, der nun in einer funktionsfertigen Fassung getestet werden kann. Die Beta bringt aktuelle Technik mit. Pop! OS 24.04 läuft auf dem Linux Kernel […]

Der Beitrag System76 veröffentlicht Pop!_OS 24.4 Beta und COSMIC Desktop Beta erschien zuerst auf fosstopia.

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

„Wie führe ich eine Laufwerksdiagnose mit einem Linux-USB-Stick durch und wie komme ich Schritt für Schritt dahin?“ Das zeigt Community-Mitglied rollmoped in seinen zwei Leserartikeln. Im ersten wird erklärt, wie man unter Windows einen bootbaren USB-Stick mit Linux erstellt und im zweiten die Diagnose und Reparatur.

Der Linux Coffee Talk ist unser entspanntes Monatsformat bei fosstopia. Hier fassen wir die spannendsten Ereignisse und Entwicklungen der letzten Wochen für euch zusammen. Also schnappt euch einen Kaffee, Tee oder euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den August Revue passieren. In dieser Ausgabe blicken wir auf die Highlights und wichtigsten News […]

Der Beitrag Linux Coffee Talk 9/2025 erschien zuerst auf fosstopia.