Eine Leap-Micro-Installation bringt auf Containerbasis bereitgestellte Anwendungen aus Ubuntu, Fedora oder dem OpenSuse Build Service ins Heimnetz.

Im Oktober 2025 macht nicht nur OpenSuse Leap den Major-Versionssprung auf Version 16. Auch Leap Micro (Abbildung 1) erscheint im selben Monat in Version 6.2 mit denselben Softwareversionsständen wie Leap 16. Leap Micro [2] ist als reine Laufzeitumgebung für Container und virtuelle Maschinen ausgelegt (Abbildung 2). Software, die über dieses Einsatzgebiet hinausgeht, wie eine grafische Umgebung oder gar Desktop-Programme, fehlt. Das Konzept dieses Minimalsystems besteht darin, dass jegliche Nutzsoftware (“Payload”) isoliert vom Grundsystem in Containern oder virtuellen Maschinen abläuft.

Abbildung 1: Die Produktseite von Leap Micro, bei Redaktionsschluss noch auf Versionsstand 6.1, preist diese OpenSuse-Spielart als besonders zuverlässig und leichtgewichtig an.

Abbildung 2: Während virtuelle Maschinen das gesamte Linux-System duplizieren, greift containerisierte Software auf die Systemressourcen des Hosts zurück. Der Container enthält daher nur die Nutzsoftware samt Abhängigkeiten.

Sowohl Container als auch virtuelle Maschinen isolieren die in ihnen laufende Software vom Grundsystem. Als zusätzlicher Schutz ist das Root-Dateisystem nur lesbar eingehängt. Aktualisierungen funktionieren auf Basis von Snapshots im – unter Suse schon lange üblichen – Dateisystem Btrfs. Das System spielt die Updates ohne Zutun des Anwenders ein, der nächste Neustart aktiviert sie. Dabei prüft das Tool Health-Checker, ob das System wieder den normalen Betriebszustand erreicht, und kehrt andernfalls zum letzten als funktionierend bekannten Zustand zurück.

Die remote im Browser aufrufbare Benutzeroberfläche Cockpit (Abbildung 3) gestattet eine einfache, grafische Handhabung der Container, virtuellen Maschinen und des gesamten Systems im Browser. MicroOS ist für ein Remote-Management prädestiniert und kann dabei in weiten Bereichen sogar auf die Konsole verzichten.

Abbildung 3: Die Containerverwaltung ist das wichtigste Modul von Cockpit unter Leap Micro, doch das webbasierte Management-Frontend administriert noch etliche weitere Aspekte des Systems.

Der von OpenSuse nicht sehr deutlich kommunizierte Unterschied zwischen Leap Micro und OpenSuse Micro besteht in der Basis: hier Leap, da Tumbleweed. Erstere garantiert einen störungsfreien Betrieb mit seltenen Aktualisierungen beim schmalen System aus wenigen Paketen.

Insgesamt unterscheidet sich Leap Micro 6.2 bis auf erneuerte Versionen der eingesetzten Software wenig vom Vorgänger 6.1. Die auffälligste Änderung ist die Anpassung der Cockpit-Management-Konsole an die OpenSuse-Farben. Die wichtigste Neuerung ist aber der auf zwei Jahre aufgestockte Support-Zeitraum [3].

Heimvorteil

Die Stärken von Containern wie Distributionsunabhängigkeit, Kapselung, Effizienz sowie ein Versions- und Instanzenmanagement haben ihnen in der Unternehmens-IT einen festen Platz gesichert. Viele der dort geschätzten Vorteile erweisen sich im heimischen Umfeld ebenfalls als wertvoll. Zum Testen einer Software aus einem experimentellen Build-Service-Repository, das grundlegende Systembibliotheken auf instabile Versionen auffrischt, können Sie mit wenigen Klicks einen Container mit einem Leap- oder Tumbleweed-Testsystem einrichten (Abbildung 4).

Abbildung 4: Community- oder Testpakete liefern oft aktuellere oder fehlende Pakete für Leap, wie hier das Fotobearbeitungsprogramm Rawtherapee. Der Test per Container klappt gefahrlos.

Vielleicht möchten Sie auch nur bestimmte Programme in der neueren Tumbleweed-Version nutzen oder peilen den Einsatz einer Software an, die es nur für Ubuntu gibt, nicht aber für OpenSuse. Dann hilft es, ein schlankes Container-Image der gewünschten Distribution einzurichten, das praktisch nur den Paketmanager enthält. Für alle gängigen Linux-Derivate findet sich ein solches direkt über die Suchfunktion von Cockpit.

Installieren Sie dann noch OpenSSH und Xauth (oder Waypipe, das Wayland-Pendant zum altbekannten Remote-X.org) in den Container (Abbildung 5), lassen sich die dort vorgehaltenen Desktop-Programme mit grafischer Benutzeroberfläche im ganzen Heimnetz nutzen.

Abbildung 5: Via Waypipe lässt sich Gimp aus dem Container auf dem Leap-Micro-Server (IP-Adresse 192.168.178.68, Port 2722) remote verwenden.

Ausgelagert

Haben Sie einen ausrangierten, noch halbwegs leistungsfähigen PC in Reserve, installieren Sie Leap Micro darauf, ohne Bildschirm und Tastatur. Erforderlich sind dann zwei USB-Sticks: Auf den ersten, von dem der neue Server booten muss, schreiben Sie per Suse-Image-Writer das Self-Install-ISO-Image für MicroOS [4].

Auf den zweiten übertragen Sie auf demselben Weg das von einem von OpenSuse online bereitgestellten Konfigurationsgenerator [5] erzeugte Konfigurations-Image. Das laden Sie über den Button unterhalb von Convert to Ignition-Combustion-Ready Filesystem IMG in the Browser herunter. Den Quellcode des von OpenSuse herausgegebenen Generators, der auch Passwörter verarbeitet, sehen Sie bei Interesse in seinem Github-Account ein [6].

Die vollautomatische Installation startet nach dem Einschalten des Rechners mit beiden eingesteckten Sticks nach mindestens zweimaligem Drücken der Eingabetaste. In vielen Fällen dürfte es aber die einfachere Lösung sein, Display und Tastatur anzuschließen. Findet MicroOS nach dem ersten Start keinen Konfigurationsdaten-USB-Stick, fragt ein Wizard die wenigen Daten am Bildschirm ab (Abbildung 6).

Abbildung 6: Ist kein Ignition-Konfigurations-Stick am System angeschlossen, fragt der MicroOS-Installer die wenigen einzugebenden Daten am Bildschirm ab.

Nach einigen Minuten steht Leap Micro zum Hinzufügen von Software bereit, die für den Anwender nützlich ist. Als Beispiel dafür dient hier ein leichtgewichtiger Tumbleweed-Container, in den sich mit dem Kommandozeilen-Tool Zypper beliebige GUI-Anwendungen aus den OpenSuse-Repos oder dem Build Service installieren lassen. Sie stehen remote per SSH über X.org oder dessen Wayland-Pendant Waypipe für jeden Rechner im Heimnetz zur Verfügung.

MicroOS enthält ausschließlich Leap-Pakete. Seine Container-Laufzeitumgebung lässt sich in identischer Form auch unter Leap (Listing 1, erste zwei Zeilen) und Tumbleweed installieren und die Libvirt-Verwaltungsumgebung für virtuelle Maschinen scharfschalten (letzte Zeile).

$ sudo zypper in -t pattern cockpit
$ sudo zypper in libvirt cockpit-podman
$ systemctl enable libvirtd.socket --now

Benutzen Sie einen separaten MicroOS-Server, dann loggen Sie sich dort per SSH ein. Bei angeschlossenem Bildschirm sehen Sie die benötigte IP-Adresse am Login-Prompt. Ansonsten lässt sie sich über den heimischen Router herausfinden. Aktivieren Sie nach der Anmeldung den Cockpit-Dienst mit sudo systemctl enable cockpit.socket --now

Dann rufen Sie unter https://<I>Rechner-IP<I>:9090 die für die Administration zuständige Benutzeroberfläche von Cockpit auf. Eine Zertifikatswarnung im Browser lässt sich dabei nicht vermeiden, denn ein akzeptiertes Zertifikat müssten Sie kostenpflichtig bei einer dem Browser bekannten Zertifizierungsstelle bestellen oder per Let’s Encrypt beziehen. Bei Rechnern im Heimnetz ist das nicht ohne Weiteres möglich ist.

Für das Cockpit-Login verwenden Sie ein systemweites Benutzerkonto, die Webkonsole läuft zunächst mit limitierten Rechten. Ein Klick auf Turn on administrative access behebt das nach Eingabe des Root-Passworts für diese und alle folgenden Sitzungen.

Ladung aufnehmen

Öffnen Sie zum Einrichten des angesprochenen Tumbleweed-Containers den Menüpunkt Podman-Container. Images beziehen Sie über die Schaltfläche Neues Abbild herunterladen am rechten Rand der gleichnamigen Rubrik. Abbildung 7 zeigt den Vorgang für Leap.

Abbildung 7: Die Suchfunktion nach Auswahl des Menüpunkts Neues Abbild herunterladen findet das offizielle Leap-Image direkt vom Anbieter OpenSuse.

In unserem Fall führt der Text “opensuse tumbleweed” für Suchen nach zum gewünschten Official openSUSE Tumbleweed image des Anbieters opensuse. Das Label (deutsche Übersetzung: Etikett) latest sorgt dafür, dass nur die neuesten Versionen als Suchergebnis unter Abbilder anzeigen erscheinen. Mit von der Partie ist der Button Container erstellen, der laufende Instanzen der im Image verpackten Software erstellt.

Ein Klick darauf öffnet einen Dialog, in dem Sie dem Container einen Namen geben. Klicken Sie nun auf Erstellen und ausführen. Daraufhin erscheint in der Rubrik Container ein Eintrag, der den Zustand als Läuft ausweist. Klappen Sie die zugehörige Zeile mit der Pfeiltaste nach rechts aus und öffnen Sie den Reiter Konsole. Das bringt innerhalb des Containers ein Root-Terminal zum Vorschein.

Hier installieren Sie einen SSH-Server (Listing 2, erste Zeile) und erstellen dafür einen Host-Schlüssel (zweite Zeile). Um später grafische Programme per SSH remote ausführen zu können, installieren Sie noch das Tool Xauth und – falls sie die entfernten Programme von einer Wayland-Session aus aufrufen möchten – Waypipe. Der automatische Start des SSH-Daemons erfordert ein Bash-Skript, zu dessen Anlegen Sie einen Konsolen-Editor wie Nano benötigen. Sie installieren das Trio mit dem Kommando aus der dritten Zeile und legen dann mit Nano (letzte Zeile) das Startskript aus Listing 3 an.

Es startet den SSH-Daemon, der ohne Aufrufparameter in den Hintergrund verschwindet, ohne das Skript zu blockieren, sowie eine Login-Shell. Der Start der Shell am Ende stellt sicher, dass der Reiter Konsole weiter funktioniert, wenn beim Containerstart der Aufruf dieses Skripts erfolgt.

$ sudo zypper in openssh
$ sudo ssh-keygen -A
$ sudo zypper in xauth waypipe nano
$ sudo nano /etc/startup

/usr/sbin/sshd
/bin/bash -l

Datentausch

Um Anwendungen remote zu nutzen, brauchen Sie eine Möglichkeit zum Austausch von Dateien. Das gelingt über ein in den Container eingebundenes Verzeichnis aus dem MicroOS-Gastsystem, das dieser wiederum per NFS als Netzwerk-Volume exportiert. Dazu eignet sich ein Ordner im Home eines Benutzer-Accounts (/home/User/shared/, denn das Root-Dateisystem ist nur zum Lesen eingehängt.

Erstellen Sie dazu via sudo nano /etc/exports in der dafür vorgesehenen Konfigurationsdatei die Zeile /home/User/shared/ 192.168.0.0/16(rw), die das Verzeichnis im Heimnetz bereitstellt. Starten und aktivieren Sie dann mit systemctl enable nfs-server.service --now den NFS-Server des Gastsystems.

Nun sollte sich das geteilte Verzeichnis beschreibbar im lokalen Verzeichnis /mnt einhängen lassen (Listing 4). Klappt das, ergänzen Sie /etc/fstab und die Zeile aus Listing 5. Sie hängt das Verzeichnis so ein, dass der Bootvorgang des Rechners nicht hängenbleibt, falls er den MicroOS-Server nicht erreicht.

$ mount 192.168.0.X:/home/User/shared /mnt

192.168.0.X:/home/User/shared /mnt/ nfs noauto,x-systemd.automount,nofail 0 0

Der eben erstellte Container ist nicht für den direkten Einsatz gedacht, sondern als Basis für weitere Container, in denen Sie schließlich beliebige Software installieren, die sich dann remote per SSH ausführen lässt. Stoppen Sie den Container also über den entsprechenden Menü-Button am Ende der Zeile. Dann wählen Sie im selben Menü den Eintrag Comitten aus, der aus dem gegenwärtigen Zustand ein Image als Basis für neue Container erstellt.

Geben Sie einen Abbildnamen aus Kleinbuchstaben und ohne Leerzeichen ein. Ersetzen Sie außerdem den beim Starten des Containers ausgeführten Befehl /bin/bash durch /bin/bash /etc/startup, also durch den Aufruf des eben erstellten Skripts, das den SSH-Server und eine Bash-Instanz startet.

Nach Klick auf Comitten erscheint in Cockpit unter Podman-Container | Images ein neuer Eintrag. Auf der Basis dieses Abbilds entstehen neue Container, die bereits alle Vorbereitungen für die Remote-Ausführung grafischer Programme enthalten (Abbildung 5). Diese Container müssen den Netzwerk-Port 22 des SSH-Servers im Container auf einen freien Port des MicroOS-Gastsystems weiterleiten.

Das gelingt im Dialog Container erstellen über den Reiter Integration mit einem Klick auf Port-Zuordnung hinzufügen. Lassen Sie in der danach erscheinenden Zeile die IP-Adresse leer, wählen Sie für den Host-Port die 22 und für Container-Port zum Beispiel 2022. Das Protokoll belassen Sie auf TCP. Da sich ein Port nur einmal belegen lässt, verwenden Sie als Container-Port für weitere Container die 2122, 2222 und so weiter.

Um das per NFS geteilte Verzeichnis /home/User/shared/ im Container verfügbar zu machen, klicken Sie auf Volume hinzufügen. Hier tragen Sie bei Host-Pfad /home/User/shared/ ein. Als Container-Pfad, an dem die Daten für die im Container laufenden Anwendungen erscheinen, dient ein ansonsten nicht belegter Ordner direkt im Stammverzeichnis wie /shared.

Aufmachen!

Sind die Portzuordnungen und das Einbinden des externen Verzeichnisses erledigt, legt Erstellen und ausführen den Container an und startet ihn (Abbildung 8). Klappen Sie die zum Container gehörige Zeile in der Rubrik Container auf und setzen Sie in der Konsole zunächst das Root-Passwort per passwd. Legen Sie dann mit useradd User einen Benutzer an und vergeben Sie für ihn ein Passwort mit passwd User.

Abbildung 8: Vor dem Erzeugen eines Containers sind die relevanten Netzwerk-Ports, hier der SSH-Port 22, einem freien Port des Gastsystems zuzuordnen.

Dann gelangen Sie von jedem Linux-Rechner im Netzwerk mit dem Aufruf aus der ersten Zeile von Listing 6 zum Container. Den Port im Parameter -p passen Sie an den vom Container genutzten Port an. Er lässt sich im laufenden Container nach Ausklappen der Informationen im Reiter Integration herausfinden. Bei 192.168.0.X handelt es sich um die IP des MicroOS-Gastsystems. Als Root (zweite Zeile) installieren Sie via Zypper Programme, die Sie im Container nutzen möchten (dritte Zeile). In der Regel müssen Sie zusätzlich Schriften installieren, zum Beispiel über das Paket bitstream-vera-fonts.

$ ssh User@192.168.0.X -X -p 2022
$ su
$ zypper install Paket

Es gibt Programme, , wie den Bitmap-Editor Gimp, deren interaktive Reaktion über Remote-X quälend langsam ausfällt. Hier sorgt dann der Aufruf aus Listing 7 von einem Wayland-Desktop aus für eine deutlich flüssigere Arbeitsweise. Zuvor müssen Sie der Datei /home/User/.bashrc im Container die Zeile export XDG_RUNTIME_DIR=/home/User für das zum Remote-Login genutzte Benutzerkonto hinzufügen.

$ waypipe ssh -p 2022 User@192.168.0.X Programm

Komplettpaket

Es gibt immer noch Anwendungsfälle, die nur virtuelle Maschinen abdecken: Manchmal möchte man ein ganzes Linux-System begutachten, nicht nur einzelne Anwendungen. Nicht-Linux-Systeme oder -Anwendungen sind ebenfalls auf virtuelle Maschinen angewiesen (Abbildung 9), in Containern funktionieren sie nicht.

Abbildung 9: Um Fremdsysteme auszuführen, müssen Sie das schwerere Geschütz der virtuellen Maschine auffahren, ein Container genügt nicht.

Dem trägt MicroOS Rechnung, indem es neben der Container-Laufzeitumgebung auch eine Verwaltung für virtuelle Maschinen mitbringt. In der Cockpit-Rubrik Virtuelle Maschinen laden Sie nicht nur gängige Distributionen wie Ubuntu, Fedora, Debian oder OpenSuse herunter, sondern erstellen auch virtuelle Maschinen. Alternativ lässt sich ein per Netzwerk-Share auf den Server übertragenes ISO-Image als Installationsbasis nutzen.

Nach der Einrichtung der VM startet der Installer direkt in einem Unterfenster im Browser (Abbildung 10). Cockpit beherrscht grundlegende Verwaltungsoperationen wie das Bearbeiten von Festplatten und das Anlegen von Snapshots oder mit dem Host-System geteilten Verzeichnissen.

Abbildung 10: Nach dem Anlegen einer VM lässt sich die Installation in der VNC-Konsole im Webfrontend Cockpit erledigen.

Prinzipiell lassen sich virtuelle Maschinen zudem nach der Installation per Unterfenster im Browser bedienen. Doch komfortabel ist das nicht. Deshalb sollte Cockpit eigentlich das Programm Desktop Viewer starten können, einen Remote-Betrachter für virtuelle Maschinen. Das funktionierte im Test allerdings nicht.

Das stört nicht weiter, denn mit der Einrichtung virtueller Maschinen auf dem MicroOS-Server hat die browserbasierte Managementsoftware ihre Schuldigkeit getan. Im Virt-Viewer, einer verbreiteten Managementsoftware für virtuelle Maschinen, gelingt es leicht, eine SSH-basierte Remote-Verbindung zur unter MicroOS laufenden Libvirt-Instanz aufzubauen: Datei | Neue Verbindung öffnet den entsprechenden Dialog. Dort aktivieren Sie die Option mit dem entfernten Rechner über SSH verbinden und tragen den Benutzernamen sowie die IP-Adresse oder den Hostnamen des entfernten Rechners ein.

Der Virt-Manager startet und stoppt virtuelle Maschinen. Er zeigt ihren Bildschirm in einem Fenster an, auf Wunsch auch in der Vollbildansicht, in der sich die virtuelle Maschine kaum von einem lokal installierten System unterscheiden lässt. Er erstellt auf Wunsch Snapshots, und seine Management-Funktionen für virtuelle Hardwarekomponenten sind deutlich leistungsfähiger als die von Cockpit (Abbildung 11).

Abbildung 11: Der Virt-Manager bietet zwar keine komfortable Einrichtungsfunktion für Distributionen, jedoch eine leistungsfähige Konfigurationsfunktion für virtualisierte Hardwarekomponenten bestehender Maschinen.

Bei der unter MicroOS eingerichteten Netzwerkverbindung für virtuelle Maschinen per NAT ist es nicht möglich, per SSH auf die virtualisierten Systeme zuzugreifen. Diese Einschränkung lässt sich leicht beheben. Öffnen Sie dazu in Cockpit die Rubrik Netzwerk und klicken Sie auf Bridge hinzufügen. Wählen Sie dann das Netzgerät enp1s0. Nach dem Hinzufügen erhält der Rechner schnell wieder seine bisherige IP-Adresse. Das aktive Netzgerät des Rechners heißt dann ab sofort bridge0.

In diese Netzwerk-Bridge kann sich ein virtuelles Netzwerkgerät einklinken, das sich von allen Rechnern im Heimnetz erreichen lässt. Allerdings beherrscht Cockpit das Anlegen von virtuellen Schnittstellen von Typ Bridge nicht. Das Anlegen per Hand verursacht jedoch keinen großen Aufwand. Klicken Sie zunächst in der Rubrik den Link 1**Netzwerk links oben an und löschen Sie dort über den Menü-Button am Ende der entsprechenden Zeile das Netzwerk default.

Legen Sie dann die Datei /tmp/network.xml mit dem Inhalt aus Listing 8 an. Der Befehl virsh net-define network.xml erzeugt daraus ein neues Netzwerk für das Gerät bridge0, als Weiterleitungs-Modus dient Bridge. Das prüfen Sie an derselben Stelle in Cockpit, an der Sie das alte Netzwerk gelöscht haben.

Aktivieren Sie dort das Bridge-Netzwerk und wählen Sie nach dem Aufklappen der Zeile ganz unten Starten, wenn der Host hochfährt. Nun lassen sich Konsolen- und grafische Programme auf der virtuellen Maschine von allen entsprechend vorbereiteten Geräten im Heimnetz aus starten. Dort muss der SSH-Server laufen, der Firewall-Port 22 offenstehen und für Anwender eines Wayland-Desktops das Paket waypipe installiert sein.

<network>
  <name>default</name>
  <forward mode="bridge" />
  <bridge name="bridge0" />
</network>

Fazit

Das schlanke und dank Read-only-System robuste Leap Micro 6.2 bootet in wenigen Sekunden, das Basissystem mit laufendem Cockpit-Verwaltungsdienst belegt weniger als 700 MByte RAM. Wollen Sie experimentelle Software testen, andere Distributionen ausprobieren oder Anwendungen von einem zentralen Server im Heimnetz aus zur Verfügung stellen, nutzen Sie dazu komfortabel im Webfrontend administrierte Container mit minimalem Ressourcen-Overhead.

Bevorzugen Sie virtuelle Maschinen, finden Sie selbst dafür eine handliche Verwaltung in Leap Micro. Übrigens baut Leap Micro ausschließlich auf Leap-Paketen auf. Egal, ob Leap oder Tumbleweed: Im Arbeitssystem selbst lassen sich Container und virtuelle Maschinen auf dieselbe Weise verwalten. Leap belegt allerdings mehr Systemressourcen, die der virtualisierten Anwendung dann nicht zur Verfügung stehen. (uba/jlu)