Ein Windows ohne Zwangs-Reboot – so könnte man überspitzt den potenziellen OpenSuse-Leap-Nachfolger Aeon beschreiben. Wir nehmen den Release Candidate unter die Lupe.

Momentan sieht es für die Zukunft von OpenSuse Leap nicht rosig aus. Die bisherige Systembasis, der Suse Linux Enterprise Server (SLES [1]) entsteht künftig in einer Form, bei der Leap die Kernpakete nicht mehr übernehmen kann. Die OpenSuse-Community aus ehrenamtlichen Helfern möchte zwar grundsätzlich Leap fortführen [2], doch momentan sieht es eher danach aus, dass das an mangelnder Manpower scheitert [3].

Alternativen wären entweder Slowroll [4], eine gebremste Version von Tumbleweed mit nur monatlichen oder zweimonatlichen Versions-Upgrades, oder das neue, auf dem MicroOS-Konzept aufbauende Aeon [5]. Dabei handelt es sich um ein Immutable-System mit nur lesbarem Root und dem distributionsübergreifenden Flathub [6] als Paketquelle. Eine finale Entscheidung steht noch aus. Wir sehen uns im Folgenden das bereits als Release Candidate vorliegende Aeon genauer an.

OpenSuse Aeon

Ein schlankes, selbstaktualisierendes, selbstheilendes Basissystem mit Flatpaks für grafische Programme plus Distrobox für einen simpel einzurichtenden Tumbleweed-Container: Das ist der Kurzsteckbrief des potenziellen Leap-Nachfolgers OpenSuse Aeon auf MicroOS-Architektur-Basis. Der Ende Mai eingeführte neue Name soll für eine klare Unterscheidung zum reinen Server-System MicroOS sorgen.

Für Aeon liefert Suse lediglich ein Basissystem mit der Desktop-Umgebung Gnome, dessen Root-Partition zur Sicherheit schreibgeschützt eingehängt ist. Anwendungen liefert das distributionsübergreifende Repository Flathub. Ein Hintergrunddienst installiert automatisch Updates des Kernsystems in einen neuen, verborgenen Snapshot, den erst ein Reboot aktiviert. Eine Rückkehr zum vorigen Zustand klappt bei Bedarf problemlos und erfolgt in der Regel ebenfalls automatisch.

Eine KDE-Fassung von Aeon (Kalpa [7]) befindet sich derzeit in Entwicklung, liegt aber erst in einem frühen Stadium vor. Das Gnome-basierte Aeon dagegen steht als praktisch fertiger Release Candidate bereit – Zeit für die OpenSuse-Tipps, die neue Systemarchitektur auf ihre Praxistauglichkeit hin zu testen.

Der von Suse gewählte Name MicroOS, der nun der Server-Spielart [8] vorbehalten bleibt, beschreibt die neue System-Architektur treffend, wie sie derzeit auch Fedora [9] und in technisch etwas anderer Form Ubuntu [10] testen: Die Distribution liefert nur einen minimalen Systemkern zur Hardwareunterstützung, eine fest integrierte Desktop-Umgebung sowie einen App-Store (Abbildung 1). Daraus installiert der Anwender distributionsübergreifende Flatpak-Pakete vom zugehörigen Repository Flathub. Dort liegen inzwischen gut 2300 Programmpakete auf Lager.

Abbildung 1: Wie das bei Ubuntu schon lang der Fall ist, dient der Gnome-App-Store nun auch bei Aeon als offizielles Programm für die Softwareinstallation.

Dabei sorgt statt der Distribution jedes Flatpak-Paket selbst für seine benötigten Abhängigkeiten. Das Rumpfsystem und die Anwendungen bleiben vollständig entkoppelt. Ein Upgrade des Kernsystems, zum Beispiel wegen einer Sicherheitslücke, tangiert die Anwendungen nicht. Umgekehrt lässt die Installation von Software den Systemkern gänzlich unberührt. Einzelne Programme sind ebenfalls vollständig von anderen abgeschirmt.

Suse ohne YaST

Ein System ohne Root-Rechte – das kennen Sie von Ihrem Android-Smartphone. Tatsächlich liegt dieser Vergleich nahe: Software-Store und Gnome-Systemeinstellungen sollen dem Aeon-Anwender genügen, um das System seinen Wünschen anzupassen (Abbildung 2). Wie unter Android ist die Systempartition schreibgeschützt eingehängt (Abbildung 3), was sie vor versehentlicher Beschädigung und Malware schützt. Unter OpenSuse Aeon ist anders als bei Android der Administrator-Account jedoch nicht gesperrt, vielmehr vergeben Sie bei der Installation wie bisher ein Passwort.

Abbildung 2: YaST gehört mit Aeon der Vergangenheit an. Seine Aufgaben übernehmen ein App-Store und die hier abgebildeten Gnome-Systemeinstellungen.

Abbildung 3: Eine der großen technischen Neuerungen von Aeon ist das nur-lesbar eingehängte Root-Dateisystem, das die Distribution unzerstörbar machen soll.

Doch während Sie im konventionellen Suse-System YaST jedes Mal als Root starten, soll nun der Root-Account nur noch in Sonderfällen zum Einsatz kommen: Software installieren Sie per Gnome Software Center mit Benutzerrechten. Aktualisierungen des Systemkerns spielt Aeon selbsttätig ein, und zwar in einen neuen Snapshot. Das nicht beschreibbar eingehängte System läuft bis zum nächsten Reboot unverändert weiter.

YaST ist nicht mehr an Bord, Zwangs-Reboots gibt es ebenso wenig wie gesperrte Root-Accounts: Eine Meldung weist darauf hin, das System bei nächster Gelegenheit neu zu starten (Abbildung 4). Dabei testet außerdem das CLI-Tool Health-checker [11], ob Aeon normal startet. Tut es das nicht, wechselt ein weiterer Neustart zum letzten als funktionierend bekannten Snapshot zurück.

Abbildung 4: Aeon sucht im Hintergrund laufend nach Aktualisierungen und installiert sie in einem Snapshot, den ein Reboot aktiviert.

Flatpak-Pakete sind ausschließlich für grafische Programme konzipiert, doch Desktop-Programme zu starten, ist nicht alles, wofür ein Linux-System taugt. Zum Glück gilt das auch für Aeon: Das Kernsystem liefert nicht nur den Gnome-App-Store für Desktop-Programme, sondern auch Distrobox [12], eine äußerst simpel zu bedienende Container-Verwaltung.

Per distrobox enter richten Sie ein vollwertiges Tumbleweed-Subsystem mit Zugriff auf das Home des Gastsystems ein (Abbildung 5). Kommandozeilenprogramme und grafische Anwendungen starten von dieser Kommandozeile aus ohne Weiteres. Dank Container-Technologie läuft anders als bei virtuellen Maschinen kein eigener Kernel, der CPU und Arbeitsspeicher belasten würde. Der Aufruf distrobox-export -a Programm an der Distrobox-Eingabeaufforderung richtet im Container sogar einen Programmstarter in der Gnome-Umgebung des Gastsystems ein (Abbildung 6). Ein passender Aufruf (Listing 1) spielt ein Ubuntu- oder Fedora-System und bei Bedarf viele weitere Distributionen [13] ein.

Abbildung 5: Sowohl Kommandozeilenprogramme als auch grafische Anwendungen installieren Sie dank Distrobox mit minimalem Aufwand.

Abbildung 6: Der Aufruf von Distrobox-export in der Distrobox-Shell legt für im Container installierte Programme einen Eintrag im Startmenü an.

$ distrobox create -i ubuntu:latest
$ distrobox create -i fedora:latest

So sehr die Möglichkeit fasziniert, mühelos Kommandozeilenumgebungen und grafische Programme vieler Linux-Distributionen ohne Reboot einzubinden: Es bleibt zu bedenken, dass es dabei jedes Mal gilt, ein eigenständiges Linux-System per Internet auf die Festplatte zu übertragen. Eine Tumbleweed-Distrobox ohne installierte Anwendungen hat ein Volumen von rund 4 GByte.

Theorie und Praxis

Wer neben per Flatpak installierten grafischen Programmen auch noch Distrobox benutzt, installiert also im Grunde drei Systeme auf seinem Rechner. Das Aeon-Basissystem belegt etwa 3 GByte. Schon um den bei der Installation eingerichteten Firefox starten zu können, kommt in der Flatpak-Laufzeitumgebung ein von der Gnome-Umgebung im Basissystem unabhängiges Runtime hinzu, das zusätzlich rund 3 GByte Plattenplatz in Anspruch nimmt.

Dabei ist der entscheidende Faktor gar nicht der Festplattenplatz: Da die Shared Libraries nun dreimal (bei Flatpak-Programmen sogar potenziell einmal pro installiertem Programm) in unterschiedlichen Versionen vorliegen, müssen sie mehrmals in den Arbeitsspeicher geladen werden. Die paketübergreifend genutzten Gnome- und KDE-Runtimes von Flatpak sorgen immerhin dafür, dass sich die Programme die speicherintensivsten Bibliotheken teilen können.

Nicht nur der RAM-Bedarf steigt, auch Sicherheitslücken lassen sich nicht mehr so verlässlich durch Austausch eines einzelnen Pakets ausbügeln wie bei klassischen Linux-Systemen. Zudem dürfte nicht jeder Autor eines Flatpak-Pakets in Sicherheitsfragen so kompetent sein wie ein Distibutions-Maintainer. Damit steigt die Gefahr, dass verwundbarer Code ins System einfließt. Andererseits ermöglichen Programmierfehler in grafischen Programmen ohne Internet-Zugriff kaum eine Übernahme des Rechners.

Wie so oft sieht das Bild in der Praxis dann doch etwas anders aus, als es die Theorie suggeriert: Nach dem Start des Gnome-Desktops und der drei Programme Firefox, Thunderbird und LibreOffice Writer belegt OpenSuse Leap 15.5 rund 2,3 GByte RAM, Aeon dagegen 2,6 GByte – kein sonderlich relevanter Unterschied. Einen neuen, leistungsfähigeren Rechner müssen Sie sich für den Umstieg von Leap oder Tumbleweed auf Aeon wohl nicht anschaffen.

Schwerer als die minimale Performance-Verschlechterungen wiegen Qualitätsmängel bei via Flathub ausgelieferten Flatpak-Paketen: Manche KDE-Anwendungen wie die Groupware Kontact starten ohne Icons (Abbildung 7), der Videoeditor Kdenlive verweigert in der aktuellen Version als Flatpak sogar grundsätzlich den Betrieb. Wie erwähnt erlaubt Flatpak, bei Problemen zu älteren Versionen zurückzukehren. Allerdings gestaltet sich ein Downgrade keineswegs komfortabel und klappt auch nicht über den grafischen Gnome-App-Store. Eine Anleitung auf Github [14] beschreibt die erforderlichen Schritte.

Abbildung 7: Bei einzelnen Anwendungen, wie der KDE-Groupware Kontact, passt die Optik des Flatpaks nicht zum Desktop.

In Distrobox funktioniert das Kdenlive aus Tumbleweed dagegen anders als die Installation per Flatpak auf Anhieb problemlos. Die nötige Umgebung schlägt allerdings mit rund 1 GByte Plattenplatz zu Buche, da sie eine KDE-Laufzeitumgebung umfasst.

Server-Dienste

Distrobox startet denkbar einfach Kommandozeilen- und grafische Programme aus vielen Distributionen, doch Server-Dienste lassen sich nicht ohne Weiteres installieren. Flathub ist prinzipiell auf grafische Programme beschränkt. Können Webentwickler also auf ihrem Aeon-System überhaupt einen Webserver installieren?

Tatsächlich klappt das sogar mit Distrobox. Das erfordert zwei Modifikationen am Standard-Tumbleweed-Container: Er muss als Root starten und außerdem Systemd einbinden, auf das Distrobox sonst verzichtet. Dazu legen Sie einen neuen Tumbleweed-Container an und betreten dann die Container-Umgebung (Listing 2, erste zwei Zeilen). Dann installieren Sie genauso wie in einem nativen Tumbleweed-System einen Webserver und aktivieren ihn (Zeile 3 und 4).

$ distrobox create --root --init Name
$ distrobox enter --root Name
$ sudo zypper in apache2
$ sudo systemctl enable apache2 --now
[...]
$ exit
$ distrobox stop -r Name

Nun erreichen Sie den Server unter http://localhost (Abbildung 8) und – da auf Aeon-Systemen im Moment keine Firewall läuft – auch von außerhalb. Sie verlassen Distrobox-Container wie eine normale Shell mit exit (Zeile 6). Root-Container sollten Sie zusätzlich mit anhalten (Zeile 7), bevor Sie Aeon herunterfahren, sonst hängt das System bis zu einem Timeout.

Abbildung 8: Mit den Optionen --root und --init angelegte Distrobox-Container können Sie auch Server-Dienste bereitstellen.

Kernregion

Bei der Installation des Nvidia-Grafik-Treibers ist dann ein Punkt erreicht, bei dem auch eine als Root gestartete Distrobox nicht weiterhilft: Nur eine Installation in das mit der Hardware interagierende Kernsystem kann die 3D-Beschleunigung aktivieren. Doch in ein System mit Read-only-Root lassen sich Pakte nicht wie gewohnt mit YaST oder dem Kommandozeilen-Werkzeug Zypper installieren.

Hier hilft ein beherzter Griff zum Kommandozeilenwerkzeug Transactional-update [15] weiter. Damit legen Sie einen neuen Snapshot an, in den Sie Pakete aus dem auch unter Aeon normal eingebundenen Tumbleweed-Repository installieren. Dazu binden Sie zunächst das von Suse bereitgestellte Nvidia-Repository ein (Listing 3, erste Zeile). Per Reboot wechseln Sie in den neu erstellten Snapshot und nehmen dann die eigentliche Treiberinstallation vor (Zeile 3). Nun steht erneut ein Reboot an.

$ transactional-update -i pkg install openSUSE-repos-NVIDIA
[... Reboot ...]
$ transactional-update -i pkg in nvidia-driver-G06-kmp-default nvidia-video-G06 nvidia-gl-G06 nvidia-compute-G06
[... Reboot ...]
$ transactional-update -i pkg in sane
[... Reboot ...]

Die ständigen Reboots erscheinen lästig. Tatsächlich gehört es zum Konzept von MicroOS/Aeon, immer nur eine Änderung in einen Snapshot zu verpacken. Erfreulicherweise lassen sich aber über die Option -c mit Transactional-update auch mehre Aktionen pro Reboot verketten.

Ein weiterer Kandidat für eine Paketinstallation ins Basissystem per Transactional-update ist die Scanner-Laufzeitumgebung Sane. Nach dem entsprechenden Aufruf (Listing 3, Zeile 5) funktionierte im Test ein angeschlossener Canon-Scanner mit der Standard-Gnome-Anwendung Document Scanner unter Aeon.

Mit transactional-update shell führen Sie zudem beliebige Kommandozeilenbefehle in einem neuen, nach einem Reboot aktiven Snapshot aus. Die Aeon-Wiki-Seite [5] empfiehlt dieses Vorgehen allerdings nur für die Fehlersuche, nicht für die aktive Administration.

Doch auch Aeon ist Linux: Als Root dürfen Sie hier alles. Stört es Sie, dass Sie beim Einsatz von Transactional-update die Auswirkung Ihrer administrativen Eingriffe auf das System immer erst nach einem Reboot sehen, dann hängen Sie mit mount -o remount,rw / die Systempartition beschreibbar ein und verändern die Konfigurationsdateien unter /etc direkt. Ein Reboot stellt anschließend den vorgesehenen Nur-Lesen-Zustand wieder her.

Damit dabei gegebenenfalls die Rückkehr zum Systemzustand vor den Änderungen gelingt, sollten Sie vor dem Aushebeln des MicroOS-Sicherheitsnetzes transactional-update shell direkt gefolgt von exit ausführen und dann neu booten. So legen Sie einen neuen Snapshot an, den Sie dank der Möglichkeit zur Systemwiederherstellung unbesorgt traktieren dürfen. Ob es sinnvoll ist, sich für ein System mit besonderen Schutzmechanismen zu entscheiden und diese dann (temporär) zu deaktivieren, steht auf einem anderen Blatt.

Die vorliegenden System-Snapshots prüfen Sie als Root mit snapper list. Außer zum Anzeigen dieser Übersicht ist Snapper unter Aeon tabu. Um manuell zu einem früheren Systemzustand zurückzukehren, benutzen Sie die Rollback-Funktion von Transactional-update. Damit kehren Sie entweder zum vorigen Snapshot zurück (Listing 4, erste Zeile) oder stellen einen von snapper list aufgeführten beliebigen Snapshot wieder her (zweite Zeile).

$ transactional-update rollback last
$ transactional-update rollback Nummer

Fazit

Die MicroOS-Architektur schnürt in der Desktop-Spielart Aeon (und später hoffentlich in der KDE-Fassung Kalpa) ein Gesamtpaket mit faszinierenden Möglichkeiten: Sie erhalten ein selbstaktualisierendes, im Fehlerfall automatisch zum letzten funktionierenden Zustand zurückkehrendes Basissystem. Hinzukommt, dass selbst ein erodiertes OpenSuse-Community-Team die Entwicklung eines solchen schmalen Rumpfsystems problemlos stemmen kann. (uba/jlu)