Hier lest ihr die Auswertung unserer Umfrage zur Anzahl der verwendeten Messenger. Wie viele sind es und welche wurden am häufigsten genannt? Es sind die üblichen Verdächtigen, wobei einer aus dem Rahmen fällt.

In der Woche, in der der SCS Summit 2025 in Berlin stattfand, wurde auch die 9. Version der SCS-Software fertiggestellt.

Wie gut läuft Borderlands 4 unter Linux statt Windows? ComputerBase hat nach einem Technik-Test zu Borderlands 4 unter Windows auch unter Linux mit AMD Radeon, GeForce RTX und Intel Arc genau nachgesehen und nachgemessen. Fazit: Zurzeit sieht es nicht gut aus.

Linux-Torvalds hat nach sieben Release-Kandidaten nun den Kernel 6.17 freigegeben. Zwei Distributionen – Fedora 43 und Ubuntu 25.10 – verwenden ihn bereits in ihren Beta-Versionen.

Cloudflare, ein globales Technologieunternehmen, hat die private Beta-Phase eines neuen KI-Index gestartet, der es Inhalteanbietern erleichtern soll, aufgefunden und auch entlohnt zu werden.

Ohne die horrenden Ausgaben für den Ausbau von KI-Rechenzentren befänden sich die USA bereits heute in einer Rezession, warnt die Deutsche Bank.

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.

Linus Torvalds hat Kernel 6.17 in stabiler Version freigegeben. Der neue Kernel liegt mit annähernd 12 000 Einreichungen im Rahmen üblicher Kernel-Zyklen.

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

Server-Platinen und Rechenzentrumssysteme von Supermicro sind derzeit von gravierenden Schwachstellen betroffen.

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

Die digitale Souveränität Europas steht unter Druck.

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.

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 aus dem September 2025.

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

Mozilla hat Version 2.31 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Außerdem steht das Mozilla VPN für Linux-Nutzer mittlerweile auch als Flatpak-Version via Flathub zur Verfügung.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.31

In den Einstellungen für ausgeschlossene Apps gibt es jetzt eine Checkbox, um System-Apps anzuzeigen. Ansonsten bringt das Update auf das Mozilla VPN 2.31 vor allem Fehlerbehebungen und Verbesserungen unter der Haube.

Mozilla VPN über Flathub erhältlich

Linux-Nutzer können das Mozilla VPN mittlerweile auch als Flatpak-Version über Flathub installieren.

Der Beitrag Mozilla VPN 2.31 veröffentlicht, jetzt auch via Flathub verfügbar erschien zuerst auf soeren-hentzschel.at.

In der Linux-Welt gibt es mehr Auswahl, als Umsteigern lieb ist. Deshalb ist es wichtig, klare Empfehlungen auszusprechen, auch wenn das manchmal nicht so einfach ist.

„HTML und CSS: Das umfassende Handbuch“ von Jürgen Wolf ist 2023 in der 5., aktualisierten und überarbeiteten Auflage im Rheinwerk Verlag erschienen und umfasst 1124 Seiten.

Das Buch „HTML und CSS: Das umfassende Handbuch“ vermittelt in insgesamt 26 Kapiteln sowohl Grundlagen als auch vertiefendes Wissen, kann aber aufgrund der Komplexität des Themas nicht jeden Bereich in Gänze beleuchten und auf manches auch gar nicht eingehen. Dennoch deckt es eine große Bandbreite an Themen ab und ist als Nachschlagewerk bestens geeignet.

Kapitel 1 – Einführung in das HTML-Universum geht zunächst darauf ein, was den Leser erwartet. Angesprochen werden sämtliche Zielgruppen: vom Einsteiger über den Entwickler bis hin zum Programmierer oder Blogger.

Kapitel 2 – Grundlegender Aufbau von HTML(-Dokumenten) befasst sich mit der grundlegenden Syntax und dem Aufbau von HTML als Auszeichnungssprache. Außerdem geht es um die einzelnen Bestandteile, aus denen ein klassisches HTML-Dokument besteht.

Kapitel 3 – Die Kopfdaten eines HTML-Dokuments konzentriert sich auf den Bereich zwischen <head> und </head>, in dem alle wichtigen Informationen und Daten über ein HTML-Dokument enthalten sind, die von Webbrowsern oder Suchmaschinen verwendet werden.

Kapitel 4 – Der sichtbare Bereich eines HTML-Dokuments thematisiert die darstellbaren HTML-Elemente, die zwischen <body> und </body> verwendet werden können. Der Leser lernt, dass das Gestalten von Webseiten nicht über HTML, sondern über CSS geschieht.

Kapitel 5 – Tabellen und Hyperlinks stellt weitere HTML-Elemente vor. Der Leser erfährt, wie er Tabellen und Hyperlinks erstellen und verwenden kann.

Kapitel 6 – Grafiken und Multimedia beschäftigt sich mit der Frage, wie dem HTML-Dokument Grafiken, Videos und andere multimediale Inhalte hinzugefügt werden können.

Kapitel 7 – HTML-Formulare und interaktive Elemente widmet sich dem Thema Web-Formulare. Als Beispiele nennt der Autor u. a. Umfrage-Formulare, in denen aus einer Liste von bestimmten Einträgen etwas ausgewählt werden kann.

Kapitel 8 – Einführung in Cascading Stylesheets (CSS) erläutert, was CSS genau ist, und stellt anhand von einfachen Beispielen dessen Anwendungsprinzip vor.

Kapitel 9 – Die Selektoren von CSS gibt Tipps für den praktischen Einsatz einer Vielzahl von Selektoren.

Kapitel 10 – Die Vererbung und die Kaskade beschäftigt sich mit einer Technik, die es ermöglicht, verschiedene CSS-Eigenschaften wie Farben, Schriftart und Schriftgröße einmalig an einer zentralen Stelle zu definieren, anstatt jedem einzelnen Element immer wieder dieselben Eigenschaften zuweisen zu müssen.

Kapitel 11 – Das Box-Modell von CSS widmet sich dem Positionieren von Elementen sowie dem Erstellen von Layouts, was beides mittels Box-Modell, auch Kastenmodell genannt, umsetzbar ist. Neben dem klassischen Box-Modell lernt der Leser auch das neue und intuitivere Box-Modell von CSS kennen.

Kapitel 12 – CSS-Positionierung vermittelt, wie man HTML-Elemente bzw. die Boxen mit CSS positionieren kann.

Kapitel 13 – Flexboxen richtet sich an Entwickler, die flexiblere und dynamischere Website-Layouts erstellen wollen, die auf verschiedenen Bildschirmgrößen und Geräten funktionieren. Elemente können innerhalb eines Container-Elements in einer einzigen Dimension angeordnet werden – entweder horizontal oder vertikal.

Kapitel 14 – Responsives Webdesign und Media Queries beschäftigt sich mit einer Gestaltungstechnik für Websites, bei der sich das Layout und die Inhalte automatisch an verschiedene Bildschirmgrößen und Geräte anpassen.

Kapitel 15 – CSS Grid befasst sich mit einer Technologie zur Erstellung komplexer und flexibler Designs, die auf verschiedene Bildschirmgrößen reagieren. Inhalte können in Raster- oder Gitterstrukturen platziert und Elemente präzise positioniert werden.

Kapitel 16 – Stylen mit CSS klärt die Frage, wie Texte, Listen, Tabellen und Bilder schöner oder lesbarer gemacht werden können, und knüpft an die Grundlagen wie die Selektoren, das Box-Modell, die Positionierung, die Flexboxen, die Media Queries und CSS Grid an.

Kapitel 17 – Der CSS-Präprozessor Sass und SCSS erklärt, wie immer wiederkehrende CSS-Schreibarbeiten vermieden werden können, und stellt Sass als CSS-Präprozessor näher vor.

Kapitel 18 – Eine kurze Einführung in JavaScript stellt die Programmiersprache JavaScript näher vor und thematisiert, dass sie im Zusammenhang mit der Webentwicklung häufig in einem Atemzug mit Ajax, Angular und React genannt wird.

Kapitel 19 – Arrays, Funktionen und Objekte in JavaScript beschäftigt sich mit Objekten, welche die Hauptdatentypen in JavaScript sind, sowie der objektorientierten Programmierung.

Kapitel 20 – Webseiten dynamisch ändern thematisiert DOM und die DOM-Manipulation (DOM = Document Object Model). Zusammen mit JavaScript lässt sich HTML damit dynamisch erzeugen.

Kapitel 21 – Einführung in die Web-APIs (Browser-APIs) erklärt, dass es eine Vielzahl von Browser-APIs gibt: für die Manipulation des DOM, für Netzwerkanfragen, für die Verwaltung des clientseitigen Speichers, für das Steuern von Audio oder Video und vieles mehr.

Kapitel 22 – Eine Einführung in Ajax und die Fetch-API beleuchtet das Konzept der asynchronen Datenübertragung mittels Ajax.

Kapitel 23 – Das Bootstrap-Framework einsetzen gibt einen kleinen und zugleich praktischen Einblick in die Verwendung des beliebten Frameworks.

Kapitel 24 – Einführung in die grundlegenden Konzepte von React setzt Kenntnisse in HTML, CSS und JavaScript voraus und stellt die JavaScript-Bibliothek React vor.

Kapitel 25 – Einführung in die grundlegenden Konzepte von Angular widmet sich dem Framework Angular, das für die Entwicklung von Web-Applikationen für den Desktop sowie den mobilen Bereich entwickelt wurde.

Kapitel 26 – Beispielprojekt erstellen, testen und optimieren demonstriert anhand eines einfachen Beispielprojekts, wie der Arbeitsablauf von der Idee bis hin zur eigenen Web-Präsenz aussehen könnte und wie sich die Website testen und optimieren lässt.

Beispiel-Code 1 (HTML): Textrichtung ändern

Manchmal ist es erforderlich, die Textrichtung zu ändern – etwa wenn Text von rechts nach links geschrieben werden soll (z. B. bei Hebräisch oder Arabisch). Das lässt sich mit dem bdo-Element umsetzen (bdo = bidirectional override).

Der folgende Code-Ausschnitt zeigt ein Palindrom, eingebettet zwischen <bdo> und </bdo>. Zunächst wird das globale HTML-Attribut dir verwendet. Anschließend wird die Textausrichtung mit dem Attributwert rtl (right to left) so geändert, dass der Text von rechts nach links verlaufen soll (ltr = left to right würde Text von links nach rechts schreiben).

<p><bdo dir="rtl">Ein Esel lese nie</bdo></p>

In der visuellen Ansicht sieht das dann wie folgt aus:

ein esel lesE niE

Beispiel-Code 2 (HTML mit CSS): Typselektoren

Das folgende Beispiel demonstriert, wie man HTML-Elemente mit dem Typselektor auswählt und mit CSS formatiert.

Folgende Zeilen zeigen den Typselektor im Einsatz in einer separaten CSS-Datei:

section { 
    width: 100%; 
    display: flex; 
    flex-direction: row; 
} 
article { 
    box-shadow: 0 4px 8px 0 
    rgba(0, 0, 0, 0.2);
    width: 30%; 
    margin: 10px; 
    padding: 5px; 
    font-size: 
    2.5vw; 
    text-align: 
    center; 
} 
img { 
    width: 100%; 
}

Zunächst wird definiert, dass sich ein section-Element um 100 Prozent ausbreiten darf. Die darin enthaltenen HTML-Elemente werden in eine Flexbox gepackt, in der die Elemente horizontal in der Reihe ausgerichtet sind.

Um das article-Element soll ein Rahmen in Form eines Schattens gezogen werden. Die einzelnen Artikel-Elemente dürfen sich innerhalb ihres übergeordneten Elements um 30 Prozent ausbreiten. Der Abstand zu den nächsten Elementen beträgt 10px, der innere Abstand 5px. Die Schriftgröße soll stets 2,5vw betragen und ist von der Breite des Viewports abhängig. Der Inhalt soll zentriert formatiert werden.

Mit dem img-Element wird angegeben, dass sich der Inhalt um 100 Prozent ausbreiten darf.

Anschließend wird diese CSS-Datei style.css per link-Element im Kopf des HTML-Dokuments hinzugefügt:

...
  <head>
  ...
   <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    <section>
        <article>
            <img src="./bilder/avatar.svg" alt="Avatar">
            <h4><b>Max Mustermann</b></h4>
            <p>Autor & Fotograf</p>
        </article>
        <article>
            <img src="./bilder/avatar-2.svg" alt="Avatar">
            <h4><b>Elisa Mustermann</b></h4>
            <p>Fullstack-Entwicklerin</p>
        </article>
    </section>
  </body>
...

Gemäß den CSS-Regeln werden die einzelnen HTML-Elemente mithilfe des entsprechenden Typselektors ausgewählt und nach den Deklarationen der Regel formatiert. Das Ergebnis sind im beschriebenen Beispielfall einfache Cards, also Karten, die in der visuellen Ansicht dann wie folgt aussehen:

Weiterführende Informationen

• Leseprobe
• Zusatzmaterialien

Fazit

„HTML und CSS: Das umfassende Handbuch“ von Jürgen Wolf ist das ideale Nachschlagewerk für alle, die (wieder) in das Thema HTML und CSS einsteigen, mehr über den Aufbau von Websites lernen sowie Quellcode lesen und verstehen wollen. Die Tatsache, dass HTML einerseits die Basissprache für die Website-Entwicklung ist und der Autor andererseits bei null anfängt, macht das Buch gerade für Anfänger interessant. Aber auch Wiedereinsteiger der „alten HTML-Schule“ werden angesprochen und können Neues zum aktuellen HTML5 lernen. Es wird auf die Abgrenzung zwischen HTML und CSS eingegangen und auch JavaScript als Web-Programmiersprache kommt nicht zu kurz. Als besonderes Highlight darf man sich auf viele praktische Code-Beispiele im Buch sowie auf der Verlagswebsite freuen.

Wichtig zu erwähnen ist, dass sich das Buch gezielt auf den Frontend-Bereich von Websites konzentriert. Wer sich also umfangreiches Wissen zum Backend und zur dafür benötigten Web-Programmiersprache PHP (oder Python, Rust, Java o. Ä.) erhofft, für den ist dieses Buch nicht geeignet, da PHP lediglich am Rande Thema ist.

Der Beitrag HTML und CSS: Das umfassende Handbuch erschien zuerst auf intux.de.

Ups, jetzt haben wir fast vergessen, auf eines der schönsten und grössten Community-Treffen im Vierländereck Deutschland/Österreich/Schweiz/Liechtenstein hinzuweisen.

Fünf fabelhafte Fakten der Woche, die es irgendwie nicht zu einer Meldung auf Linux-Magazin Online geschafft haben – und warum eigentlich nicht.

Fünf fabelhafte Fakten der Woche, die es irgendwie nicht zu einer Meldung auf Linux-Magazin Online geschafft haben – und warum eigentlich nicht.

Das Fedora-Projekt hat eine Policy zum Umgang mit KI in der Programmierung für das Projekt vorgeschlagen.

Das Berliner Startup Noxtua, gegründet 2017, das eine Software entwickelt, die mit Hilfe von KI juristische texte analysieren, Verträge prüfen und selbstständig Schriftsätze erstellen kann,…