Suse ohne YaST – das ist ungewohnt, aber zeitgemäß, denn mit Cockpit steht in Leap 16.0 ein würdiger Nachfolger bereit. Sonst ändert sich bei der neuen Leap-Major-Version weniger als befürchtet.

Sieben Jahre nach dem Release von OpenSuse Leap 15.0 erscheint nach derzeitiger Planung Anfang Oktober die nächste Hauptversion 16.0 (Abbildung 1). Das Konzept dieser OpenSuse-Spielart, aktuelle Anwendungen mit einem aus der Enterprise-Distribution SLES abgeleiteten stabilen Systemkern zu kombinieren, sagt vielen Anwendern zu [1]. Zwischen den jährlichen Distributions-Upgrades bleiben lange Phasen, in denen sich weder Anwendungen noch System in Bedienung und Funktion verändern. Probleme nach Aktualisierungen treten bei deren konservativer Natur selten auf.

Abbildung 1: Systemadministration per Web-Frontend, Myrlyn statt YaST Software sowie ein KDE-6-Wayland-Desktop als Standard: Leap 16.0 bringt Veränderungen, behält aber das Grundkonzept “stabiler Kern plus aktuelle Anwendungen” bei.

Abgewürgt

Die Meldung, dass die Enterprise-Sparte von Suse ihr bisheriges Hauptprodukt SLES, die Hauptquelle von Leap-Paketen, nicht fortführt [2], hätte das Ende von Leap bedeuten können. Die Zahl der Pakete, die OpenSuse-Entwickler dann nicht mehr aus dem kommerziellen Angebot hätten beziehen können, wäre drastisch angestiegen. Die zu geringe Anzahl der für diese Aufgabe verfügbaren Freiwilligen schien den Fortbestand von Leap infrage zu stellen [3].

Jetzt dürfen Leap-Anhänger aufatmen: Leap 16 gilt als praktisch fertig und lag Anfang August als Release-Candidate vor. Die stabile Veröffentlichung soll laut Plan am 1. Oktober erfolgen. Die Enterprise-Sparte ist hinsichtlich der Einstellung von SLES zurückgerudert und veröffentlicht SLES 16, die Basis für Leap 16, nun parallel zum einst als Nachfolger auserkorenen Suse Linux Micro [4].

Die Systemarchitektur von Leap bleibt unverändert: Leap wandelt sich nicht zum Immutable-System wie Fedora Silverblue oder zum containerbasierten System wie OpenSuse Aeon. Der Softwarebestand liegt mit gut 36 300 Paketen über dem im Januar in den OpenSuse-Tipps für die Alpha-Version von Leap 16 gezählten 32 400 Paketen, allerdings immer noch deutlich unter den 44 600 in OpenSuse Leap 15.6. Der Mangel an freiwilligen Helfern und die schmalere Basis der von der Enterprise-Sparte beigesteuerten Pakete dürften hier Spuren hinterlassen haben.

Mit Rawtherapee und Darktable entfallen gleich zwei beliebte und für die Verbreitung von Linux wichtige Fotoaufbereitungsprogramme. Die IDE Eclipse und die Virtualisierungslösung Virtualbox fehlen gleichfalls, genau wie das führende freie CAD-Programm FreeCAD. Andererseits zeigen sich manche Pakete, die die Entwickler die ganze Leap-15-Serie hindurch nicht aufgefrischt haben, endlich in einer zeitgemäßen Version, darunter Audacity und Blender.

Vertrauensfrage

Wie schwerwiegend ein Anwender die Lücken im Softwarebestand empfindet, hängt davon ab, wie er zu distributionsübergreifenden Flatpak-Paketen steht: Fast alle Linux-Anwendungen stehen inzwischen auf dem zentralen Flatpak-Repository Flathub [5] zur Auswahl. Das Flathub-Repository müssen Sie nur noch über den Befehl aus der ersten Zeile von Listing 1 aktivieren, alles andere ist unter OpenSuse vorbereitet.

$ sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak remote-add --if-not-exists --subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo

Die Webseite listet für jedes Programm den Konsolenbefehl zur Installation, der sich aus dem Aufruf von flatpak install flathub gefolgt von der eindeutigen Kennung der Software zusammensetzt. Alternativ richten Sie die Anwendungen bequem über die grafischen Paketmanager von KDE und Gnome (Abbildung 2) ein.

Abbildung 2: Die App-Stores von KDE und Gnome verwalten unter OpenSuse lediglich Flatpak-Pakete, nicht aber native OpenSuse-RPMs.

Auf halbwegs leistungsfähigen Rechnern unterscheiden sich als Flatpak installierte Programme kaum von via OpenSuse-Paket eingespielten. Allerdings fällt die Menge der herunterzuladenden Daten oft sehr viel größer aus.

Bezüglich der Sicherheit gilt es zu bedenken, dass jeder auf Flathub Pakete veröffentlichen kann. Den Status Verfizierte App (Abbildung 3) gewährt die Plattform jedoch nur Entwicklern, die sich als Eigentümer des Quellcode-Repos der Anwendung ausweisen können. Dass die Projektverantwortlichen dann in ein Flatpak-Paket Schadcode zulasten des Rufs ihrer mit viel Mühe kostenfrei bereitgestellten Software einschmuggeln, ist unwahrscheinlich.

Abbildung 3: Das Darktable-Paket auf Flathub stammt von unabhängigen Drittentwicklern, während das Gimp-Paket vom Gimp-Team selbst stammt und daher den Status verified tragen darf.

Wer das Risiko minimieren will, filtert das Flathub-Repository. Das Kommando aus der zweiten Zeile von Listing 1 erstellt ein flathub-verified-Repository mit nur von den Originalentwicklern veröffentlichten Paketen.

Ciao, YaST!

Die prominenteste in Leap 16.0 fehlende Anwendung ist kein Grafik- oder 3D-Programm, sondern YaST. Das über Jahrzehnte als Alleinstellungsmerkmal von Suse gehandelte grafische Konfigurations-Frontend ist nicht mehr vorinstalliert, liegt aber noch in den Repos. Unvoreingenommen betrachtet gilt YaST schon seit Jahren nicht mehr als Zugpferd für OpenSuse. Immer weniger seiner Module gelten in der heutigen Linux-Welt noch als nutzbringend einsetzbar.

Diese Einschränkung gilt aber nicht für das nach wie vor hervorragende Modul Software. Die Entwickler lösten es daher aus YaST heraus und stellen es unter dem Namen Myrlyn als separates Programm in Version 0.97 bereit. Obwohl es noch nicht ganz zur Versionsnummer 1.0 reicht, zeigt sich das Tool funktional mit dem früheren YaST-Modul auf Augenhöhe.

Lediglich die Liste für Community-Repositorys zum vereinfachten Hinzufügen bestimmter, von OpenSuse empfohlener Repos steht im Moment noch leer. Das liegt daran, dass das wichtigste davon, das Packman-Repository für unbeschnittene Multimedia-Codecs, noch kein Leap-16-Repo eingerichtet hat. Man darf aber getrost davon ausgehen, dass sich das bis zum endgültigen Release im Oktober ändert.

Eingewebt

Als Ersatz für YaST preisen seine Entwickler die webbasierte Systemmanagementsoftware Cockpit an (Abbildung 4). Etwas merkwürdig mutet es an, dass sie standardmäßig nicht vorinstalliert ist und – schlimmer noch – ihre Einrichtung an einem Dateikonflikt mit dem Paket busybox-hostname scheitert. Allerdings enthält das in Konflikt stehende Paket lediglich simple Links im Dateisystem, die das Auslesen und Setzten des System-Hostnames mit dem Kommando hostname ermöglichen. Cockpit enthält diese Funktion selbst.

Abbildung 4: Die Rubrik Konten ist ein Beispiel dafür, dass Cockpit das optisch altbackene YaST mehr als würdig vertritt.

Die Installation lässt sich also gefahrlos mit Option 1 (busybox-hostname deinstallieren) in der Softwareverwaltung vornehmen. Dass ein derartiger Fehler an einer solchen Schlüsselposition noch im Release-Candidate auftaucht, einer als “vorläufig fertig” deklarierten Version, wirft die Frage auf, ob bei Leap 16.0 im Vergleich zum Vorgänger nicht bloß die Paketausstattung gelitten hat, sondern auch die Qualitätskontrolle.

Um den vollen Funktionsumfang von Cockpit zu nutzen, installieren Sie alle Pakete, deren Namen mit cockpit beginnen, außer cockpit-tukit. Dabei handelt es sich um eine Unterstützung für transaktionale beziehungsweise unveränderliche Systeme wie Aeon oder Kalpa. Unter Leap mit normaler Systemarchitektur legt dieses Modul die Paketverwaltung in Cockpit lahm.

Nach der Installation müssen Sie den Cockpit-Dienst noch mit sudo systemctl enable cockpit.socket aktivieren. Dann lässt sich die Administrationssoftware im Browser über die URL http://localhost:9090 nach Authentifizierung mit einem normalen Benutzerkonto öffnen. Der Eingeschränkte Zugang mit reinen Benutzerrechten verschwindet nach einem Klick auf den entsprechenden Button in der Kopfleiste und erneuter Eingabe des Benutzerpassworts.

Für die hardwarebezogenen YaST-Module bietet Cockpit keinen Ersatz. Auch die Reparatur oder Konfiguration des Bootloaders ist nicht mehr vorgesehen. Doch dabei handelt es sich gerade um die YaST-Module, die in einem modernen Linux-System eigentlich überflüssig sind, da der Kernel die Hardware längst ohne händische Konfiguration erkennt. Das Modul Bootloader konfrontierte den Anwender ohnehin mit kryptischen Optionen der Datei /etc/default/grub, die man nun direkt dort editieren muss, sofern Durchschnittsanwender sich überhaupt mit dem Bootloader befassen.

Auf der Habenseite von Cockpit finden sich zahlreiche nützliche Funktionen. Der Viewer in der Kategorie Logs bereitet das Systemprotokoll für Anwender auf, denen die Bedienung des Kommandozeilen-Werkzeugs Journalctl zu kompliziert erscheint. Die Sparte Services zeigt den Status der Systemdienste, startet oder beendet sie und listet deren Log-Ausgaben. Accounts verwaltet, wie der Name schon sagt, Benutzerkonten.

Bei der Benutzerauthentifizierung gibt es unter Leap 16.0 eine kleine, aber, falls nicht beachtet, gefährliche Änderung: Vom Installer angelegte Benutzer dürfen via Sudo mit ihrem eigenen Passwort Root werden, während unter Leap 15.6 dafür noch das Root-Passwort gefragt war. Ubuntu handhabt das schon immer so, ein eigenes Root-Passwort existiert dort gar nicht.

Um bestimmten Anwendern den Root-Zugriff mit dem eigenen Passwort zu verwehren, entziehen Sie ihnen im Cockpit-Modul Konten die Mitgliedschaft in der Gruppe wheel, die unter Unix historisch für einen Zugriff auf administrative Aufgaben steht. Um allen Anwendern den Root-Zugang zu sperren, kommentieren Sie in der per Visudo zu öffnenden Sudo-Konfigurationsdatei die Zeile @includedir /usr/etc/sudoers.d aus.

In der Rubrik Speicher fasst Cockpit RAM und Massenspeicher zusammen. Das Monitoring umfasst die Besonderheiten des unter Suse genutzten Btrfs-Dateiformats wie Subvolumes und Snapshots. Außerdem partitioniert die Software neue Speichergeräte und kann dabei RAIDs [6] und LVMs [7] anlegen. Auch das Einbinden von NFS-Network-Shares gehört zum Funktionsumfang.

Fertigbauteil

Als YaST entstand, waren Container und selbst die viel älteren virtuellen Maschinen unter Heimanwendern noch kein Thema. Das modernere Cockpit verwaltet sowohl Podman-Container als auch per Libvirt [8] administrierte virtuelle Maschinen.

Seine besondere Stärke liegt darin, dass es zahlreiche Linux-Systeme und containerisierte Serverdienste mit wenigen Klicks herunterlädt und einrichtet. Benötigen Sie zum Beispiel eine LAMP-Umgebung zum Testen einer Webanwendung, finden Sie auf Docker Hub schnell eine Lösung. Die Onlinesuchfunktion und das automatische Setup machen es auch mit Virtualisierungstechnik weniger erfahrenen Anwendern leicht, unterschiedlichste Distributionen auszuprobieren (Abbildung 5).

Abbildung 5: Cockpit richtet VMs für viele Distributionen auf bloße Eingabe des Namens ein (Inlay rechts oben) und zeigt deren Benutzeroberfläche eingebettet im Browserfenster an.

Installieren Sie die Libvirt und aktivieren den Libvirt-Daemon mit sudo systemctl enable libvirtd.socket, können Sie sofort loslegen. Alles funktioniert einwandfrei, solange Sie sich mit der im Browser eingebetteten Anzeige der virtuellen Maschine zufriedengeben. Wenn Sie aber ein Linux-System intensiver testen möchten, dürften Sie kaum auf eine Anzeige in einem eigenständigen Fenster außerhalb des Browsers oder im Vollbild verzichten wollen. Dazu startet Cockpit das externe Programm Virt-Viewer, das Sie über das gleichnamige Paket installieren. Allerdings schlägt der Start unter OpenSuse fehl, denn Virt-Viewer hat in Leap 16.0 die Unterstützung für das standardmäßig eingesetzte Spice-Protokoll verloren.

Der beste Workaround besteht darin, Cockpit nur zum Einrichten und Verwalten der virtuellen Maschinen zu nutzen, wofür es gute Dienste leistet. Für den eigentlichen Start der VMs eignet sich Virt-Manager besser (Abbildung 6). Nach Installation der Pakete virt-manager und spice-gtk funktioniert alles out of the box über das angesprochene leistungsoptimierte Spice-Protokoll. Die separaten Programmfenster der virtuellen Maschinen lassen sich auch zur Vollbildansicht wandeln.

Abbildung 6: Virt-Manager öffnet die in Cockpit eingerichteten virtuellen Maschinen in einem eigenen Fenster, das sich zum Vollbild vergrößern lässt.

In der bei Leap mitgelieferten Version unterstützt Cockpit zudem die Suse-Softwareverwaltung. Es lassen sich neue Pakete einspielen (Rubrik Packages), Repositories hinzufügen (Rubrik Repositories) und Aktualisierungen einspielen.

Die leistungsfähige Netzwerk-Verwaltung in Cockpit ermöglicht das Einrichten von VPNs, Network-Bonding, Bridging und Segmentierungen. Auch die Firewall lässt sich hier anpassen. Zu guter Letzt integriert Cockpit noch ein Konsolenfenster, das es überflüssig macht, parallel zur Cockpit-Session eine SSH-Verbindung aufzubauen.

Die Cockpit-Webseite ist in der Standardeinstellung von außerhalb des Rechners zu erreichen und nach Freigabe der administrativen Rechte nur durch ein Benutzerpasswort geschützt. Falls Ihnen das missfällt, schließen Sie den zugehörigen Port 9090 der Firewall. Das erledigen Sie in Cockpit im Modul Netzwerk in Firewall | Regeln und Zonen bearbeiten nach einem Klick auf das Dreipunkte-Icon am Ende der Zeile cockpit.

Übertragbar

Nicht nur für die Administration eines bestehenden Systems gibt es in der aktuellen Leap-Version ein webbasiertes, Remote-taugliches Frontend. Schon die Installation mit dem neuen Installer Agama (Abbildung 7) basiert auf einem auch über das Netzwerk erreichbaren Webfrontend. So lässt sich die Installation auf allen Geräten im Heimnetz bequem von einem zentralen Arbeits-PC aus vornehmen, auch auf solchen ohne Bildschirm und Tastatur. Das setzt lediglich einen eingesteckten USB-Stick oder eine eingelegte DVD mit dem Leap-Installationsmedium voraus, von dem der Rechner für die Leap-Installation bootet.

Abbildung 7: OpenSuse Leap 16 nutzt erstmals den neuen, übersichtlichen und vor allem remote bedienbaren Installer Agama (hier die Ansicht für die Auswahl der zu installierenden Software).

Verfügt der einzurichtende Rechner über Bildschirm und Tastatur, genügt es, mit [Strg]+[Alt]+[F1] auf ein Konsolenterminal zu wechseln, um IP-Adresse, Root-Passwort und die URL für den Remote-Aufruf des Installers im Browser eines anderen Rechners zu erfahren. Fehlt ein Bildschirm, setzt das Suse-spezifische Tool Tagmedia ein bekanntes Passwort.

Installieren Sie dafür, egal ob unter Leap 15.6, 16.0 oder Tumbleweed, das Paket checkmedia und führen Sie dann das Kommando aus Listing 2 aus. Der Aufruf fragt nach einem Passwort, das er in das ISO-Image einbettet. Das modifizierte ISO-Abbild schreiben Sie am einfachsten mithilfe des Suse-Tools Studio Image Writer (Paket imagewriter) auf einen USB-Stick oder brennen es als DVD. Die IP-Adresse des Zielrechners finden Sie in Ihrem Router heraus (Abbildung 8).

$ tagmedia --add-tag "live_password=$((openssl passwd -6) | base64 -w 0)" /Pfad/zum/Install.iso<C>

Abbildung 8: Nach dem Booten eines Agama-Installers erscheinen per Netzwerkkabel angeschlossene Rechner unter ebendiesem Hostnamen im Router. Die dort auslesbare IP lässt sich auf jedem Rechner im Heimnetz im Browser aufrufen, um die Installation auszuführen.

Der neue Installer wirkt in seiner aktuellen Form durchdacht und übersichtlich. Er erzwingt nicht mehr wie die alte YaST-basierte Routine das Durchklicken aller Schritte. Ein Ausrufezeichen auf der Schaltfläche Installieren zeigt, dass es noch Einstellungen vorzunehmen gilt, bevor die Installation startet. Ein Klick auf den Button zeigt eine explizite Liste der noch auszuführenden Schritte.

Ansonsten können Sie sich frei durch die nur sechs Rubriken bewegen, um die Partitionierung der Festplatten (Rubrik Speicherung), die Auswahl der Software (insbesondere der Desktop-Umgebung) oder das Anlegen von Benutzerkonten und Passwörtern vorzunehmen. Die Umstellung der Lokalisierung erfolgt praktischerweise bereits, wenn Sie rechts oben für die Sprache des Installers eine Auswahl treffen.

In die Röhre

Die für Leap 16.0 bei der Installation wählbaren Desktop-Umgebungen unterstützen allesamt Wayland. Kritiker betrachten es als das größte Defizit des X-Window-Nachfolgers, dass er von sich aus nicht netzwerktransparent arbeitet. Grafische Programme lassen sich daher nicht länger direkt per SSH remote ausführen.

Doch es wäre paradox, wenn ein per Netzwerk administrierbares und sogar installierbares System mit Standard-Wayland-Desktop keine Remote-Ausführung von grafischen Anwendungen mehr gestatten würde. Das ist auch nicht der Fall: Das simpel zu benutzende Tool Waypipe aus dem gleichnamigen Paket bietet unter Wayland dank eingebauter Videokompression längst eine bessere Performance für remote aufgerufene Programme als X.org. Dessen archaischen Mechanismen zur Bandbreitenreduktion können aktuelle Qt- oder GTK-Programme ohnehin nicht mehr nutzen.

Voraussetzung für den Einsatz von Waypipe ist, dass die GUIs beider Rechner unter Wayland laufen und auf beiden Waypipe installiert ist. Läuft remote ein X-Server, lokal aber Wayland, funktioniert die alte Methode des X-Forwardings per SSH mit dem Parameter -X noch, denn Wayland enthält stets eine X-Kompatibilitätsschicht. Für Wayland-zu-Wayland-Verbindungen rufen Sie schlicht waypipe ssh Remote-IP Programm auf. Scheitert der Start am lokal vorhandenen, remote aber fehlenden Vulkan-Support, hilft der Aufruf von Waypipe mit dem Parameter -n weiter.

Die weitaus meisten Gnome- und KDE-Programme funktionieren unter Wayland problemlos, denn die von ihnen genutzten Toolkits GTK und Qt sind längst dafür gerüstet. Es gibt allerdings Ausnahmen, wie das CAD-Programm FreeCAD und PrusaSlicer sowie von ihm abgeleitete 3D-Drucker-Slicer. Bei solchen Anwendungen, die in der Regel auf die 3D-Beschleunigung der Grafikkarte zugreifen, bleibt das Programmfenster unter Wayland schwarz (Abbildung 9). Auch dafür bietet die X-Kompatibilitätsschicht von Wayland einfache Abhilfe. Es genügt, Qt-Programme mit einem vorangestellten QT_QPA_PLATFORM=xcb auf der Konsole zu starten, für GTK-Programme hilft GDK_BACKEND=x11. Die Performance leidet nicht merklich, der Workaround eignet sich selbst für Spiele.

Abbildung 9: Einige wenige Programme wie hier der Slicer OrcaSlicer zeigen unter Wayland eine leere 3D-Vorschau. Sie funktionieren aber durch Voranstellen einer bestimmten Umgebungsvariablen einwandfrei im X-Kompatibilitätsmodus.

Fazit

Die Klippe ist umschifft, Leap 16 liegt in gewohntem Aufbau vor. Die beliebte Spielart der Distribution wird allen Unkenrufen zum Trotz weder eingestellt noch mutiert sie zum containerbasierten Immutable-System à la Fedora Silverblue. Das bewährte Grundkonzept bleibt unangetastet: Nach wie vor ergänzen von der Community beigesteuerte aktuelle Anwendungen einen stabilen Systemkern auf Basis des Suse-Enterprise-Systems SLES.

In Sachen Software hat Leap allerdings Federn lassen müssen, die Zahl der mitgelieferten Pakete ist um rund 25 Prozent geschrumpft. Es fehlen beliebte Anwendungen wie Darktable, Rawtherapee, Eclipse und FreeCAD, für die sich allerdings Ersatz in Form von Flatpak-Paketen beschaffen lässt.

Auch das jahrzehntelang als Suse-Alleinstellungsmerkmal gehandelte YaST ist Geschichte. Es existiert zwar noch, wird aber weder vorinstalliert noch weiterentwickelt. Die Entwickler empfehlen mit Blick auf die Zukunft das webbasierte Cockpit als Ersatz. (uba/jlu)