Das auf die Erstellung von Multimedia-Inhalten spezialisierte AV Linux (AVL) und MX Moksha (MXM) 25 wurden laut Entwickler Glen MacArthur nach einer langen und mühsamen Entwicklungsphase…

Die neuen Versionen von Gitlab enthalten wichtige Fehlerbehebungen und Sicherheitskorrekturen.

Falls euch ein drehender Cursor nach dem Start des GNOME-Desktops nervt, könnte dieser Artikel Abhilfe schaffen.

Canonical hat den ersten Snapshot von Ubuntu 26.04 veröffentlicht. Damit beginnt eine Serie von fünf monatlichen Entwicklungsständen bis April 2026. Ziel ist es, die neue LTS Version mit automatisierten Builds und Tests zu erproben. Die Snapshots erscheinen für alle Ubuntu Flavours und nicht nur die Hauptausgabe mit GNOME. Sie sind Momentaufnahmen des Entwicklungsstands und werden […]

Der Beitrag Ubuntu 26.04 startet mit erstem Snapshot in die Entwicklung erschien zuerst auf fosstopia.

Die Arbeiten an Plasma 6.6 schreiten sichtbar voran und die Entwickler geben einen Vorgeschmack auf das kommende Desktop Erlebnis. Der finale Veröffentlichungstermin ist für Februar 2026 angesetzt, doch schon jetzt werden viele Details bekannt. Eine besonders interessante Funktion erlaubt das gezielte Ausschließen einzelner Fenster bei Bildschirmaufnahmen. Diese Einstellung lässt sich direkt über Titelleiste, Task Manager […]

Der Beitrag KDE Plasma 6.6 zeigt spannende Neuerungen vor dem großen Release erschien zuerst auf fosstopia.

Viele Sprachmodelle bezeichnen sich als Open Source, segeln aber unter falscher Flagge. Wer strenge Anforderungen erfüllen muss, sollte genauer hinschauen.

In unserem neuen Mitgliederinterview stellt sich die credativ GmbH vor: Geschäftsführer David Brauner spricht über digitale Souveränität als fundamentalen Wert, die Bedeutung von Herstellerunabhängigkeit und transparentem Quellcode sowie die Rückkehr zur OSBA. Nach dem Management-Buyout startet credativ mit voller Energie in die Open-Source-Zukunft und möchte seine langjährige Expertise in die gemeinsamen Arbeitsgruppen einbringen.

Quelle

Open-Source-Anbieter Adfinis wurde auf dem IONOS Summit 2025 als Consulting Partner of the Year ausgezeichnet. Der Preis wurde im Rahmen der IONOS Partner Awards am 4. November in Berlin verliehen. Die Auszeichnung würdigt den Erfolg von Adfinis bei der Bereitstellung robuster und sicherer Cloud-Native-Plattformen in Partnerschaft mit IONOS.

Quelle

Die Desktopumgebung KDE hat angekündigt, ab Plasma 6.8 vollständig auf Wayland zu setzen und die Unterstützung für X11 einzustellen. Mit dem Erscheinen dieser Version Anfang 2027 endet damit dort nach rund 30 Jahren die Ära des klassischen X-Fenstersystems.

KDE folgt damit anderen großen Projekten wie GNOME oder Distributionen wie Fedora, die X11 bereits zugunsten von Wayland aufgegeben haben. Erste technische Vorbereitungen erfolgten bereits mit Plasma 6.4, als die X11- und Wayland-Releases von KWin separiert wurden.

Ein kurzer Überblick

Wayland wird seit 2008 entwickelt und verfolgt das Ziel, den in die Jahre gekommenen X-Server abzulösen. Unter X11 versteht man sowohl das zugehörige Netzwerkprotokoll als auch dessen Referenzimplementierung. Als Fenstersystem implementiert X11 eine vollständige Client-Server-Architektur für die Verwaltung grafischer Objekte, die Synchronisation von Eingaben und die Aushandlung von Rendering-Pfaden, wobei es als Bindeglied zwischen Anwendungen, Grafiktreibern und der eigentlichen Display-Hardware fungiert. Das System blickt auf eine über 40-jährige Geschichte zurück und entstand in einer Zeit, in der grafische Unix-Desktops noch kaum verbreitet waren.

Diese historische Last führte zu hoher Komplexität im Protokoll und einer sehr großzügigen Vertrauensarchitektur: Viele Komponenten dürfen ohne separate Berechtigungsprüfung auf Eingabe- und Ausgabedaten zugreifen. Genau dieses Modell ist heutzutage ein Sicherheitsrisiko, etwa weil Malware unter X11 vergleichsweise leicht Tastatureingaben auslesen kann.

Wayland setzt deshalb auf ein strengeres Sicherheitsmodell und eine klare Trennung der Zuständigkeiten. Funktionen wie Screencasts oder globale Hotkeys, die Zugriff auf Bildschirm- oder Tastaturdaten benötigen, müssen unter Wayland explizit und prüfbar autorisiert werden. Das macht die Plattform sicherer, aber bringt auch einen Migrationsaufwand für Anwendungen mit sich.

Programme können entweder nativ auf Wayland portiert werden oder die Kompatibilitätsschicht Xwayland nutzen, die X11-Anwendungen unter Wayland lauffähig macht. Beide Wege sind in der Praxis jedoch mit Einschränkungen verbunden, sodass bestimmte Funktionen noch nicht vollständig abgebildet werden. Diese technische Herausforderung erklärt, warum der Wechsel zu Wayland bereits seit über zehn Jahren andauert.

Praktische Auswirkungen

Bei mir ist es speziell die Anwendung OBS für Screencasts, weshalb ich die letzten Jahre bei X11 geblieben bin. Aber auch hier hat sich die Unterstützung für Wayland verbessert.

Die KDE-Entwickler möchten jetzt ihre Arbeit auf Wayland konzentrieren und die doppelte Codebasis der beiden aktuell unterstützten Fenstersysteme reduzieren. Das wird sicherlich gelingen, es wird aber auch eine Umstellung sein, die aufgrund der vielen Sonderfälle ähnlich tiefgreifend wie der Wechsel zu systemd werden kann. Bis dahin ist aber noch gut ein Jahr Zeit.

Das brandneue InfinityBook Max 15 erweitert die beliebte InfinityBook-Pro-Reihe um grafisch leistungsstarke und gleichzeitig sehr dünne, leichte und mobile Businessnotebooks für Work & Play. Ausgestattet mit AMD Ryzen AI Prozessoren und NVIDIA GeForce RTX Grafikkarten der schnellen Mittelklasse, bietet das InfinityBook Max 15 starke Rechenpower für Softwareentwicklung, anspruchsvolle Mediengestaltung und Gaming. Kombiniert mit bis zu massiven 128 GB Arbeitsspeicher und einem maximal […]

Quelle

Um der kritischen strategischen Notwendigkeit der digitalen Souveränität in Europa gerecht zu werden, kündigt Red Hat, der weltweit führende Anbieter von Open-Source-Lösungen, „Red Hat Confirmed Sovereign Support“ für die 27 Mitgliedstaaten der Europäischen Union an. Dieses neue Support-Angebot wurde speziell entwickelt, um dedizierten, von EU-Bürgern gestützten technischen Support innerhalb der EU für Software-Subskriptionen von Red Hat bereitzustellen. Damit soll ein neues Maß an überprüfbarer lokaler Kontrolle über kritische IT-Vorgänge ermöglicht werden.

Quelle

Der langjährige Open-Source-Anbieter Adfinis gibt mit der Ernennung von zwei neuen C-Level-Führungskräften wichtige Änderungen in der Geschäftsleitung bekannt. Dies ist Teil einer strategischen Weiterentwicklung der Führungsstruktur, die den Wachstumskurs des Unternehmens unterstützt.

Quelle

Neue ISOs für EndeavourOS und CachyOS stehen zum Download bereit. AMD nutzt für seine Radeon Software Mesa als Basis. Die Online-Office-Suite Collabora bringt eine neue Offline-App. Valve hat in Zusammenarbeit mit AMD die Color-Pipeline-API finalisiert, welche für bessere Hardwarenutzung und einheitliche Farbdarstellung sorgt.

Am 29.11.2025 hat Solus mit Version 4.8 Opportunity eine neue Veröffentlichung geschafft.

Das Ende unserer Black Week naht: Sichert euch noch 25 Prozent Rabatt auf Workshops (z. B. Keycloak, Intune, Web Security), 50 Prozent auf E-Learnings und 25 Prozent auf Stellenanzeigen im Golem-Stellenportal. (Golem Karrierewelt, Linux)

Die Docker Engine 29 unter Linux unterstützt erstmals Firewalls auf nftables-Basis. Die Funktion ist explizit noch experimentell, aber wegen der zunehmenden Probleme mit dem veralteten iptables-Backend geht für Docker langfristig kein Weg daran vorbei. Also habe ich mir gedacht, probiere ich das Feature einfach einmal aus. Mein Testkandidat war Fedora 43 (eine reale Installation auf einem x86-Mini-PC sowie eine virtuelle Maschine unter ARM).

Inbetriebnahme

Das nft-Backend aktivieren Sie mit der folgenden Einstellung in der Datei /etc/docker/daemon.json:

{ 
  "firewall-backend": "nftables"
}

Diese Datei existiert normalerweise nicht, muss also erstellt werden. Die Syntax ist hier zusammengefasst.

Die Docker-Dokumentation weist darauf hin, dass Sie außerdem IP-Forwarding erlauben müssen. Alternativ können Sie Docker anweisen, auf Forwarding zu verzichten ("ip-forward": false in daemon.json) — aber dann funktionieren grundlegende Netzwerkfunktionen nicht.

# Datei /etc/sysctl.d/99-docker.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

sysctl --system aktiviert die Änderungen ohne Reboot.

Die Docker-Dokumentation warnt allerdings, dass dieses Forwarding je nach Anwendung zu weitreichend sein und Sicherheitsprobleme verursachen kann. Gegebenenfalls müssen Sie das Forwarding durch weitere Firewall-Regeln wieder einschränken. Die Dokumentation gibt ein Beispiel, um auf Rechnern mit firewalld unerwünschtes Forwarding zwischen eth0 und eth1 zu unterbinden. Alles in allem wirkt der Umgang mit dem Forwarding noch nicht ganz ausgegoren.

Praktische Erfahrungen

Mit diesen Einstellungen lässt sich die Docker Engine prinzipiell starten (systemctl restart docker, Kontrolle mit docker version oder systemctl status docker). Welches Firewall-Backend zum Einsatz kommt, verrät docker info:

docker info | grep 'Firewall Backend'

 Firewall Backend: nftables+firewalld

Ich habe dann ein kleines Compose-Setup bestehend aus MariaDB und WordPress gestartet. Soweit problemlos:

docker compose up -d

  [+] Running 2/2
  Container wordpress-sample-wordpress-1  Running   0.0s 
  Container wordpress-sample-db-1         Running   0.0s 
  Attaching to db-1, wordpress-1


docker compose ps

  NAME                           IMAGE             ...   PORTS
  wordpress-sample-db-1          mariadb:latest          3306/tcp
  wordpress-sample-wordpress-1   wordpress:latest        127.0.0.1:8082->80/tcp

Firewall-Regeln

Auch wenn ich kein nft-Experte bin, wollte ich mir zumindest einen Überblick verschaffen, wie die Regeln hinter den Kulissen funktionieren und welchen Umfang sie haben:

# ohne Docker (nur firewalld)
nft list tables

  table inet firewalld

nft list ruleset | wc -l

    374

# nach Start der Docker Engine (keine laufenden Container)
nft list tables

  table inet firewalld
  table ip docker-bridges
  table ip6 docker-bridges

nft list ruleset | wc -l

    736

Im Prinzip richtet Docker also zwei Regeltabellen docker-bridges ein, je eine für IPv4 und für IPv6. Die zentralen Regeln für IPv4 sehen so aus (hier etwas kompakter als üblich formatiert):

nft list table ip docker-bridges

table ip docker-bridges {
  map filter-forward-in-jumps {
    type ifname : verdict
      elements = { "docker0" : jump filter-forward-in__docker0 }
  }
  map filter-forward-out-jumps {
    type ifname : verdict
      elements = { "docker0" : jump filter-forward-out__docker0 }
  }
  map nat-postrouting-in-jumps {
    type ifname : verdict
      elements = { "docker0" : jump nat-postrouting-in__docker0 }
  }
  map nat-postrouting-out-jumps {
    type ifname : verdict
      elements = { "docker0" : jump nat-postrouting-out__docker0 }
  }
  chain filter-FORWARD {
    type filter hook forward priority filter; policy accept;
    oifname vmap @filter-forward-in-jumps
      iifname vmap @filter-forward-out-jumps
  }
  chain nat-OUTPUT {
    type nat hook output priority dstnat; policy accept;
    ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output
  }
  chain nat-POSTROUTING {
    type nat hook postrouting priority srcnat; policy accept;
    iifname vmap @nat-postrouting-out-jumps
      oifname vmap @nat-postrouting-in-jumps
  }
  chain nat-PREROUTING {
    type nat hook prerouting priority dstnat; policy accept;
    fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output
  }
  chain nat-prerouting-and-output {
  }
  chain raw-PREROUTING {
    type filter hook prerouting priority raw; policy accept;
  }
  chain filter-forward-in__docker0 {
    ct state established,related counter packets 0 bytes 0 accept
      iifname "docker0" counter packets 0 bytes 0 accept comment "ICC"
      counter packets 0 bytes 0 drop comment "UNPUBLISHED PORT DROP"
  }
  chain filter-forward-out__docker0 {
    ct state established,related counter packets 0 bytes 0 accept
      counter packets 0 bytes 0 accept comment "OUTGOING"
  }
  chain nat-postrouting-in__docker0 {
  }
  chain nat-postrouting-out__docker0 {
    oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade comment "MASQUERADE"
  }
}

Diese Tabelle richtet NAT-Hooks für Pre- und Postrouting ein, die über Verdict-Maps (Datenstrukturen zur Zuordnung von Aktionen) später dynamisch auf bridge-spezifische Chains weiterleiten können. Für das Standard-Docker-Bridge-Netzwerk (docker0, 172.17.0.0/16) sind bereits Filter-Chains vorbereitet, die etablierte Verbindungen akzeptieren, Inter-Container-Kommunikation erlauben würden und nicht veröffentlichte Ports blocken, sowie eine Masquerading-Regel für ausgehenden Traffic von Containern, damit diese über die Host-IP auf das Internet zugreifen können. Die meisten Chains sind vorerst leer oder inaktiv (nat-prerouting-and-output, raw-PREROUTING, nat-postrouting-in__docker0). Wenn Docker Container ausführt, interne Netzwerk bildet etc., kommen weitere Regeln innerhalb von ip docker-bridges hinzu.

Zusammenspiel mit libvirt/virt-manager

Vor ca. einem halben Jahr bin ich das erste Mal über das nicht mehr funktionierende Zusammenspiel von Docker mit iptables und libvirt mit nftables gestolpert (siehe hier). Zumindest bei meinen oberflächlichen Tests klappt das jetzt: libvirt muss nicht auf iptables zurückgestellt werden sondern kann bei der Defaulteinstellung nftables bleiben. Dafür muss Docker wie in diesem Beitrag beschrieben ebenfalls auf nftables umgestellt werden. Nach einem Neustart (erforderlich, damit alte iptables-Docker-Regeln garantiert entfernt werden!) kooperieren Docker und libvirt so wie sie sollen. libvirt erzeugt für seine Netzwerkfunktionen zwei weitere Regeltabellen:

nft list tables

table inet firewalld
table ip docker-bridges
table ip6 docker-bridges
table ip libvirt_network
table ip6 libvirt_network

Einschränkungen und Fazit

• Die Docker-Dokumentation weist darauf hin, dass das nftables-Backend noch keine Overlay-Regeln erstellt, die für den Betrieb von Docker Swarm notwendig sind. Docker Swarm funktioniert also aktuell nicht, wenn Sie Docker auf nftables umstellen. Für mich ist das kein Problem, weil ich Docker Swarm ohnedies nicht brauche.

• Ich habe meine Tests nur unter Fedora durchgeführt. (Meine Zeit ist auch endlich.) Es ist anzunehmen, dass RHEL plus Klone analog funktionieren, aber das bleibt abzuwarten. Debian + Ubuntu wären auch zu testen …

• Ich habe nur einfache compose-Setups ausprobiert. Natürlich kein produktiver Einsatz.

• Meine nftables- und Firewall-Kenntnisse reichen nicht aus, um eventuelle Sicherheitsimplikationen zu beurteilen, die sich aus der Umstellung von iptables auf nftables ergeben.

Losgelöst von den Docker-spezifischen Problemen zeigt dieser Blog-Beitrag auch, dass das Zusammenspiel mehrerer Programme (firewalld, Docker, libvirt, fail2ban, sonstige Container- und Virtualisierungssysteme), die jeweils ihre eigenen Firewall-Regeln benötigen, alles andere als trivial ist. Es würde mich nicht überraschen, wenn es in naher Zukunft noch mehr unangenehme Überraschungen gäbe, dass also der gleichzeitige Betrieb der Programme A und B zu unerwarteten Sicherheitsproblemen führt. Warten wir es ab …

Insofern ist die Empfehlung, beim produktiven Einsatz von Docker auf dem Host möglichst keine anderen Programme auszuführen, nachvollziehbar. Im Prinzip ist das Konzept ja nicht neu — jeder Dienst (Web, Datenbank, Mail usw.) bekommt möglichst seinen eigenen Server bzw. seine eigene Cloud-Instanz. Für große Firmen mit entsprechender Server-Infrastruktur sollte dies ohnedies selbstverständlich sein. Bei kleineren Server-Installationen ist die Auftrennung aber unbequem und teuer.

Quellen/Links

• https://kofler.info/dockers-nft-inkompatibilitaet-wird-zunehmend-zum-aergernis/
• https://docs.docker.com/engine/release-notes/29/
• https://docs.docker.com/engine/network/firewall-nftables/
• https://docs.docker.com/engine/network/firewall-nftables/#migrating-from-iptables-to-nftables
• https://docs.docker.com/engine/daemon/
• https://docs.docker.com/engine/security/#docker-daemon-attack-surface

Macht mit bei unserem Weihnachts-Gewinnspiel. Wer es bis Level 10 schafft, kann tolle Preise gewinnen. Dieses Mal erwartet euch eine Schnitzeljagd im Internet.

SonicWall hat mehrere Sicherheitslücken in Email Security und SonicOS SSLVPN geschlossen. Im Ernstfall ist eine komplette Systemkompromittierung möglich.

Der Linux Coffee Talk ist das entspannte Monatsformat bei fosstopia. Hier fassen wir die spannendsten Ereignisse und Entwicklungen der letzten Wochen für Euch zusammen und ordnen es ein. Also schnappt euch einen Kaffee, Tee oder Euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den November Revue passieren. In dieser Ausgabe blicken wir auf die […]

Der Beitrag Linux Coffee Talk 11/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 und ordnen sie bestmöglich ein. Also schnappt euch einen Kaffee, Tee oder Euer Lieblingsgetränk, macht es euch gemütlich und lasst uns den November Revue passieren.

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

Neue Forks müssen Vertrauen in die Person des Maintainers und den Code schaffen. Beides wurde beim aktuellen Fork von Syncthing for Android sträflich vernachlässigt.

Der Raspberry Pi eignet sich für vieles: Opencloud-Host, Selbstbau-NAS oder als OpenWRT-Router. Die Vorteile davon und wie das geht, erklären wir in c’t uplink.

Das Hufeisenschema suggeriert, dass es Gemeinsamkeiten zwischen Linksextremen und Rechtsextremen gibt. Das ist falsch und schadet der Demokratie. Aber ...

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.