© wirestock / 123rf.com

Anfang November 2025 erschienen SUSE Linux Micro 6.2 und SUSE Linux Enterprise 16. Die scheidende Version 15 SP7 erhält noch bis 2037 Support – um die teils radikalen, aber notwendigen Veränderungen für wechselunmutige Kundschaft zu portionieren.

Eine der auffälligsten allgemeinen Änderungen dürfte sein, dass nun Minor-Releases wie 16.0 zum Einsatz kommen. Damit gehören Service Packs der Vergangenheit an. Nebenversionen veröffentlicht man weiterhin jährlich, wobei das Unternehmen jede Version zwei Jahre lang mit Updates versorgt, gegen Aufpreis sind weitere drei Jahre möglich. In Summe plant SUSE, SLES 16 [1] bis ins Jahr 2035 zu unterstützen. Für besonders migrationsunwillige Kunden bietet der Distributor zusätzlichen Support bis 2038 (LTS) oder 2041 (LTS Core) an. Das verlängert den Zeitraum insgesamt auf irrwitzige 16 Jahre [2]. Einen Überblick über die Wartungszeiträume für SLE 16 liefert die gleichnamige Tabelle.

Darüber hinaus haben die Entwickler die Vielfalt an Modulen zusammengestrichen. Doch die Pakete sind keineswegs verschwunden, sondern Bestandteil des Hauptprodukts geworden. Lediglich die High Availability Extension und das Package Hub stehen weiterhin als separate Module zur Verfügung.

SLE 16 liefert derzeit knapp 36 000 Pakete aus, von denen 28 000 aus dem maßgeblich von der Community gepflegten Package Hub kommen. Für sie gibt es keinen L3-Support von SUSE – kritische Programmfehler und Sicherheitslücken werden jedoch behoben, um den Betrieb im Zusammenhang mit SLES zu gewährleisten.

Nach Aussage des Unternehmens  [3] ist SLE 16 die erste Enterprise Distribution, die vollständig als Reproducible Build erstellt wird. Lückenlose SBOMs (Software Bill of Materials) helfen dabei, die Herkunft eingesetzter Software nachzuvollziehen.

Cockpit statt YaST

Abbildung 1: Der aufgeräumte Web-Installer Agama weiß zu überzeugen.

Für langjährige User kommt es vielleicht etwas unerwartet, dass YaST nun der Vergangenheit angehört. Das in die Jahre gekommene Ruby-Framework weicht Fedoras Cockpit-Projekt, das bereits in anderen Linux-Distributionen zum Einsatz kommt. Statt einer Desktop-Anwendung starten Sie lediglich einen gängigen Webbrowser. Das Einbinden ins Betriebssystem übernimmt der neue Agama-Installer (Abbildung 1). Er bedient sich ebenfalls aus der Cockpit-Codebasis und bringt optisch frischen Wind.

Als Kiosksitzung gestartete Installationen verfolgen Sie so komfortabel in einem Webbowser von anderer Stelle weiter – VNC oder eine Remote Konsole braucht es nicht mehr. Der Funktionsumfang von Cockpit lässt sich über nachinstallierbare Module (Abbildung 2) erweitern – beispielsweise, um die Firewall zu konfigurieren oder virtuelle Maschinen und Podman-Container (Abbildung 3) zu verwenden.

Abbildung 2: Den grundsätzlichen Funktionsumfang ergänzen Sie mit unterschiedlichen Cockpit-Erweiterungen.

Abbildung 3: Mithilfe des passenden Moduls erreichen Sie in Cockpit beispielsweise die Konsole eines ausgeführten Podman-Containers.

Um unbeaufsichtigte Installationen kümmerte sich bisher das altersbedingt komplexe AutoYaST. In SLE 16 treten gleich drei unterschiedliche Tools die Nachfolge an: Ignition [4], Combustion [5] und das auch von anderen Linux-Distributionen verwendete cloud-init [6]. Statt XML kommen JSON (Ignition) und Bash (Combustion) zum Zug, um die Konfiguration zu vereinfachen. Combustion und cloud-init erledigen die rudimentäre System- und Netzwerkkonfiguration, während Ignition vor allem Speicher, Konfigurationsdateien und User vorbereitet.

Statt eines einzigen zentralen Werkzeugs gibt es ab sofort also drei kleinere mit enger abgestecktem Funktionsumfang. Zum einfacheren Einstellen der automatisierten Installation findet ein Webeditor Verwendung. Wer eine grafische Paketverwaltung sucht, wird mit dem auf Qt6-basierenden Myrlin fündig. Der Zypper-Paketmanager unterstützt fortan parallele Downloads, was die Wartezeiten bei größeren Patch-Installationen reduziert.

SELinux

Für den Serverbetrieb folgerichtig war SUSEs Entscheidung, AppArmor durch SELinux zu ersetzen. AppArmor steht zwar weiterhin als Alternative zur Verfügung, SELinux hat sich aber wegen der bedeutend größeren Verbreitung als sinnvoller Standard etabliert. Gegenüber AppArmor verfolgt es den Ansatz, alles zu verbieten, was nicht explizit erlaubt ist – AppArmor geht den umgekehrten Weg. Während darin für den Desktop eine denkbare Option besteht, wollen Server gewöhnlich grundsätzlich von der höchstmöglichen Sicherheit profitieren.

SUSE geht aufs Ganze und schaltet SELinux standardmäßig scharf – für den reibungslosen Betrieb von SAP-Anwendungen gibt es dokumentierte Booleans. Insgesamt stehen knapp 400 SELinux-Booleans und 450 SELinux–Module bereit – das lässt sich mit gängigen RHEL-Versionen vergleichen. Für Flatpak, K3s und SAP finden sich außerdem spezifische SELinux-Policies.

Wie auch für andere Distributionen reduziert SLE das Engagement für 32-Bit-Software. Dementsprechend existieren nur noch vereinzelte 32-Bit-Bibliotheken, beispielsweise für den Einsatz von Wine oder Steam. 32-Bit-Builds der Distro gehören seit SLE 12 ohnehin nicht mehr zum Angebot. Darüber hinaus gibt es jetzt einheitliche Installationsabbilder für SLES und SLES for SAP Applications (SLES4SAP).

Abbildung 4: GNOME 48 tritt an die Stelle von GNOME 45, hier mit gestartetem Terminal und Python-3-Interpreter.

Zu den weiteren technischen Updates unter der Haube zählt der Linux LTS-Kernel 6.12, der zusammen mit glibc 2.40 und systemd 257 die Basis für SLE 16 bildet – das unter SLES 15 SP7 zuletzt an Linux 6.4. X.Org genutzte gehört der Vergangenheit an. GNOME 48 (Abbildung 4) beerbt GNOME 45, weitere Desktops entfallen und lassen sich bestenfalls über die Community beziehen.

PipeWire tritt an die Stelle von PulseAudio, und IPTables muss NFTables weichen. OpenSSH springt von Version 9.6 auf 10.0, erlaubt standardmäßig keine Passwort-Logins für root mehr und gilt außerdem als für die Post-Quantum-Zeit gewappnet. SLE 16 versteht sich generell als Jahr 2038-kompatibel.

Für die Netzwerkkonfiguration verwendete SLE bisher das selbst entwickelte »wicked«-Framework. Mit Version 16 wechselt SUSE standardmäßig zum Defacto-Standard NetworkManager. MariaDB ist in Version 11.8 an Bord, und PHP wurde auf 8.4 aktualisiert. Trotz zwischenzeitlichen Zurückruderns der Softwarelizenz hat SUSE Redis durch Valkey ersetzt. KVM ist jetzt der einzig ausgelieferte und unterstütze Hypervisor.

Besonderes Augenmerk legten die Entwickler auf die Ablöse der bereits 2021 abgekündigten Python-Version 3.6. In SLE 16 setzen sie standardmäßig auf Python 3.13 – zahlreiche beliebte Module wurden paketiert, über »pip« steht die volle Auswahl weiterer Module aus dem Internet zur Verfügung.

Während in der Vergangenheit neuere zusätzliche Python-Versionen paketiert wurden (für SLES 15 SP7 stehen derzeit 3.11 und 3.13 zur Wahl), plant SUSE auch die mit dem Betriebssystem ausgelieferte Interpreterversion zu aktualisieren – eine Veränderung, über die sich vor allem Entwicklerinnen freuen dürften.

Predictable Network Names lassen sich ab der aktuellen Version nicht mehr über den Kernel-Bootparameter »net.ifnames=0« deaktivieren. Mit klassischen Gerätebezeichnungen wie »eth0« ist es damit endgültig vorbei, obgleich SUSE sie bereits in SLE 15 abgekündigt hatte. Für die Umbenennung von Netzwerkkarten empfehlen sich heutzutage systemd-Link-Units.

Neuzugänge

Neben zahlreichen Entfernungen gibt es einige Neuzugänge zu vermelden. Beispielweise hält der Systemprofiler TuneD Einzug in SLE 16. Sie greifen darauf zurück, um das System für unterschiedliche Einsatzzwecke zu optimieren, etwa hinsichtlich Energieeffizienz, verringerter Latenz oder leistungsstärkerer Server. Für die Authentifzierung mit Microsoft Azure Entra ID integrierte man das von SUSE unterstützte himmelblau-Projekt [7] – neben PAM spricht die Software NSS. Für SUSE Observability spielt das in die Paketierung aufgenommene Grafana Alloy eine interessante Rolle.

Der Legacy-BIOS-Support ist zwar abgekündigt, aber noch vorhanden. Wer Full-Disk-Encryption via TPM einsetzen möchte, ist auf UEFI angewiesen. Das Verzeichnis »/tmp« ist nicht mehr persistent. Zusätzlich bricht SLES 16 mit einer Tradition: Neu angelegte User erhalten ab sofort automatisch eine Primärgruppe mit ihrem Namen. Zuvor waren sie lediglich Primärmitglied der Gruppe »users«. Das führte dazu, dass unaufmerksam angelegte Dateien sich oft von anderen Usern der Gruppe lesen ließen. Systemd legt Standardkonfigurationen nun unterhalb von »/usr« statt von »/etc« ab. Um Abweichungen zu definieren genügt es, eine Konfigurationsdatei nach »/etc« zu kopieren und anzupassen.

Ansible

Die neue Hauptversion steht zudem für einen weiteren Kurswechsel: SUSE fokussiert sich neuerdings besonders auf Ansible. Während sich das Unternehmen früher vor allem für SaltStack starkmachte, sollen sich die eigene Produkte künftig besser mit dem Platzhirsch Ansible verwalten lassen. Salt spielt weiterhin im Zusammenhang mit SUSE Multi-Linux-Manager eine wichtige Rolle, da es dort die zentrale Kommunikation übernimmt.

Allerdings zeichnete sich hier schon im September 2021 ab, dass SUSE Ansible als weitere Option anbieten würde. Seit der Übernahme von SaltStack durch VMware im Jahr 2020 deutete sich ein Abwärtstrend an. Die Akquisition durch Broadcom 2023 verstärkte ihn massiv. Bisher lieferte SUSE stark veraltete Ansible-Versionen aus – inzwischen handelt es sich erfreulicherweise um Ansible 11.3 und ansible-core 2.18. Doch SUSE plant weiteres Engagement abseits der Paketierung der IaC-Software.

Über das Paket »ansible-linux-system-roles« werden einige Ansible-Module sowie eine Handvoll Rollen zur Konfiguration unterschiedlicher Systemdienste (unter anderem AIDE, Cockpit, Firewall, HA-Cluster, Podman) bereitgestellt. Die meisten dieser Rollen stammen aus dem linux-system-roles-Projekt [8]. Es bildet gleichzeitig die Basis für die seit 2018 in RHEL enthaltenen System Roles. Sie stellen niederschwellig nutzbare Vorlagen zur einfacheren Systemkonfiguration zur Verfügung.

SUSE paketiert nicht nur existierende Ansible-Rollen. Einige der Anpassungen – um sie auf SLES lauffähig zu machen – sind schon an die ursprünglichen Projekte zurückgeflossen. Während einer Präsentation auf der SUSECON 2025 in Orlando [9] erklärten Engineers, an weiteren Rollen arbeiten zu wollen und außerdem über eine eigene Registry nachzudenken. Das stoße eine spannende Bewegung im Ansible-Ökosystem an – Ansible Galaxy [10] wirkt darin bisher alternativlos. Mit der Semaphore UI Galaxy [11] existiert zwar eine weitere Registry. Allerdings ist sie relativ unbekannt und scheint derzeit lediglich die Inhalte des Vorbilds zu klonen.

KI-Themen finden sich ebenfalls in den Release Notes. Beispielsweise hat SUSE ein Agentic-AI-Framework [12] als technische Vorschau [13] in SLE 16 eingebaut. Konkret geht es dabei um das Paket »mcphost«. Es gestattet in Verbindung mit ausgeführten Anwendungen wie SUSE Multi-Linux Manager oder SAP Trento und einem frei wählbaren LLM kontextbezogene Kommunikation. Trainierte Modelle können so in Echtzeit über das Model Context Protocol (MCP) weitere Informationen erfragen, um Antworten zu konkretisieren.

openSUSE Leap

Die SLE-16-Neuerungen beeinflussen selbstverständlich das openSUSE-Leap-Projekt, mit dem SLE sich wie gewohnt die Codebasis teilt. Zukünftig existiert ausschließlich ein Software-Repository, das Community- und SLES-Pakete enthält. Das bisherige dedizierte SLES-Repository entfällt. Dementsprechend bestehen beide Linux-Distributionen aus dem gleichen Code – Unterschiede finden sich künftig vor allem beim Support. Er verlängert sich beim Upstream-Projekt auf 24 Monate. Bis dato wurden Service Packs 12 Monate mit einer Übergangszeit von sechs Monaten bei neueren Versionen unterstützt.

Während Leap 15.6 nach aktuellem Stand noch bis zum 30. April 2026 unterstützt wird, sieht die neue Hauptversion insgesamt sechs Minor-Releases bis zum Herbst 2031 vor. Die letzten beiden Nebenversionen sollen immerhin Maintenance Updates erhalten. Für Interessierte mit mehr Wartungsbedarf kommen SLES und SL Micro [14] infrage. Mit »opensuse-migration-tool« [15] hat SUSE darüber hinaus ein Skript vorgestellt, das Migrationen zwischen openSUSE Tumbleweed, Slowroll, Leap Micro und Leap erlaubt. Letzteres lässt sich zu einem vollwertigen SLES konvertieren.

SAP

Auch die Änderungen im SAP-Bereich stehen ganz im Zeichen längerer und flexiblerer Wartungen [16]. So bekommt nun jedes Minor-Release maximal fünf Jahre Support: zwei Jahre allgemein und drei in der LTS-Variante.

Den Platz des in die Jahre gekommenen »sapconf« nimmt »saptune« ein. Für SAP-HANA-Systemreplikationen gibt es ab sofort verbesserte Ressource-Agenten. Die neue Hauptversion 3.0 der Dashboard-Software Trento unterstützt fortan auch Operations – so sollen sich SAP-Systeme direkt starten und stoppen lassen. Erneut soll MCP-Support dabei helfen, LLMs einzusetzen. SELinux unterstützt man vollständig.

Zu den Eigenentwicklungen im Ansible-Bereich zählen unter anderem die Rollen »saptune« und »suseconnect«. Aus einer Kollaboration mit dem SAP LinuxLab entspringen mehrere SAP-Playbooks und -Rollen, die sich im Paket »ansible-sap-launchpad« finden.

SUSE Linux Micro 6.2

Die meisten der technischen Änderungen gelten genauso für das deutlich schlankere SUSE Linux Micro 6.2. Das liegt an den sich gleichenden Codebasen. Vorrangig für den Betrieb von Containern und virtualisierten Workloads ausgelegt, verfügt SUSE Linux Micro lediglich über eine stark reduzierte Paketauswahl. Von den knapp 36 000 SLE-16-Paketen haben es ungefähr 3000 in das SL-Micro-6.2-Angebot geschafft. Ein neu hinzugekommener Extras-Kanal ergänzt weitere Compiler und Bibliotheken. Rudimentäre Zusatzpakete wie alternative Shells und Monitoring-Dienste fehlen bislang. Auch einzelne Systemdienste wie Cron mussten leichtgewichtigeren Alternativen weichen, hier Systemd-Timer.

Zu den hinzugefügten Paketen zählen das im Kubernetes-Umfeld bekannte Helm und »podmansh«, das interaktive Shells und Volume-Zugriffe in Podman Quadlets ermöglicht. Die Entwickler ersetzten außerdem »crun« durch »runc« und entfernten »nerdctl«. Für yomi gibt es keinen Support mehr. Userspace Live Patching unterstützt SUSE jetzt auch mit transaktionalen Updates.

Fazit

Mit SLE 16 und SL Micro 6.2 macht SUSE viel richtig und bläst den lange erwarteten frischen Wind in die eigenen Enterprise Distros. Die neue Ansible-Marschrichtung dürfte für eine bedeutend bessere Adaption in bereits bestehenden Infrastrukturen sorgen – obwohl diese Entscheidung schon bedeutend früher hätte fallen können. Auch der Fokus auf SELinux dürfte sich positiv auf gesteigerte Security-Anforderungen der Kundschaft auswirken. Mit Cockpit gibt es endlich ein modernes Konfigurationswerkzeug für all jene, die eine grafische Oberfläche bevorzugen – die zahlreichen Plugins lassen kaum Wünsche offen. (csi)