Erste Erfahrungen mit Uyuni- und SUSE Manager Podman-Images

Wie auf der diesjährigen SUSECON angekündigt, ist der neue containerisierte SUSE Manager 5.0 Mitte Juli erschienen. Das Uyuni-Projekt bietet seit Version 2023.10 zusätzlich Images für die Container-Variante an. Die zuletzt erschienene Version 2024.08 ist die letzte, die zusätzlich noch als klassische RPM-Version angeboten wird.

Immutable

Gegenüber der vorherigen Versionen kommen nun SLE Micro 5.5 bzw. openSUSE Leap Micro 5.5 zum Einsatz - zwei immtuable Distributionen aus den eigenen Reihen.

Das auffälligste Merkmal gegenüber konventionellen Distributionen dürfte die Paketverwaltung sein, die über das transactional-update-Kommando gesteuert wird. Änderungen werden stets in einen neuen Dateisystem-Snapshot gespeichert, der beim nächsten Boot geladen wird. Im Fehlerfall kann so leicht der alte Zustand gebootet und wiederhergestellt werden. Mit Ausnahme von einigen Verzeichnissen (z.B. /root, /var und /home) sind weite Teile des Betriebssystems read-only.

Die Paketauswahl ist sehr minimalistisch: rudimentäre Tools, wie tmux (immerhin gibt es screen) und yast2 fehlen - NetworkManager kommt standardmäßig ohne TUI. Beim ersten Boot wird die Netzwerkschnittstelle lediglich über DHCP korrekt konfiguriert. Es werden keine Parameter für statische Konfigurationen abgefragt - auch, wenn der Assistent etwas anderes suggeriert.

Die folgenden Befehle entfernen die DHCP-Konfiguration und nehmen eine statische IPv4-Konfiguration vor:

1# nmcli con del "Wired connection 1"
2# nmcli con add con-name "Homelab" ifname eth0 type ethernet ip4 xxx.xxx.xxx.xxx/24 gw4 xxx.xxx.xxx.xxx
3# nmcli con mod "Homelab" +ipv4.dns xxx.xxx.xxx.xxx
4# nmcli con mod "Homelab" +ipv4.dns xxx.xxx.xxx.xxx
5# nmcli con up "Homelab"

Alternativ kann das TUI-Werkzeug nachinstalliert werden:

1# transactional-update pkg install NetworkManager-tui
2# reboot

Volume Mounts und Installation

Von Uyuni und SUSE Manager persistierte Daten werden in Volume Mounts ausgelagert, die auch mithilfe des mgr-storage-server-Tools auf dedizierte Partitionen ausgelagert werden können. Leider unterstützt das Tool derzeit kein LVM - KB-Artikel und Feature Request existieren.

Die Installation der Applikation ist deutlich einfacher gegenüber früheren Versionen:

1. Repository hinzufügen (Uyuni) bzw. Extension aktivieren (SUSE Manager)
2. Installation einiger weniger Pakete (mgr{adm,ctl}{,-bash-completion} netavark)
3. mgradm install podman ausführen, um die benötigten Container Images bereitzustellen und zu konfigurieren

Die SUMA-Dokumentation ist nicht ganz korrekt, hier fehlt der Abschnitt über die Paketinstallation.

Automatisierte Bereitstellung

Freudigerweise akzeptiert das mgradm install podman-Kommando Konfigurationsparameter (wie z.B. SSL oder Organisationsdetails) auch via YAML-Dokument. Es werden sogar bedeutend mehr Parameter unterstützt, als die Dokumentation vermuten lässt - die Keys lassen sich aus dem Hilfemenü ableiten:

 1# Image settings
 2image: registry.opensuse.org/uyuni/server
 3tag: latest
 4
 5# SSL settings
 6ssl:
 7  city: Darmstadt
 8  country: Germany
 9  org: Homelab
10  ou: myserver.shittyrobots.loc
11  password: HurrDurr1337
12  state: Hessen
13
14# Organization name
15organization: Homelab
16
17# Email address sending the notifications
18emailFrom: simone@shittyrobots.loc
19
20# Administrators account details
21admin:
22  password: HurrDurr1337
23  login: admin
24  firstName: Antonia
25  lastName: Administratorin
26  email: admin@shittyrobots.loc

Software-Repositories hinzufügen

Zur Konfiguration externer Software-Repositories hat sich spacewalk-common-channels schon seit langem etabliert. Das Werkzeug muss zukünftig aber innerhalb des Podman-Containers ausgeführt werden, da es nicht extern als Paket zur Verfügung steht:

1$ podman exec -ti uyuni-server spacewalk-common-channels -a x86_64 almalinux9,almalinux9-appstream-almalinux9-uyuni-client

Migration

Eine direkte Migration auf eine neue Version der Lifecycle-Suite ist nicht möglich, da sich neben dem Anwendungsunterbau (Podman) auch das Betriebssystem ändert. Glücklicherweise gibt es mit dem mgradm migrate podman-Kommando einen Assistenten, der die Datenübernahme automatisiert. Der Prozess ist dokumentiert und erfolgt in mehreren Schritten:

1. Installieren eines neuen openSUSE Leap Micro 5.5- (Uyuni) bzw. SLE Micro 5.5 (SUSE Manager)-Systems
2. Installieren der benötigten Kommandozeilenwerkzeuge
3. Datenübernahme aus dem Altsystem via mgradm migrate podman
4. Abschalten des Altsystems.

Das Migrationswerkzeug kopiert neben den Paketdaten auch Datenbank-Inhalte, stoppt anschließend die Datenbank und fährt die Anwendung auf dem neuen System nach erfolgreicher Konvertierung wieder hoch. In der Uyuni-Version 2024.10 scheint es hier jedoch einen Bug zu geben, der die Datenbank zu früh stoppt.

Der Assistent bricht beim Konvertieren der Reporting-Datenbank mit einer Fehlermeldung ab:

1psql: error: connection to server at "localhost" (::1), port 5432 failed: FATAL:  Ident authentication failed for user "pythia_susemanager"

Per Zufall bin ich darauf gestoßen, dass das Problem umgangen werden kann, wenn die Quelldatenbank mittels smdba db-start wieder gestartet wird, während auf dem neuen System der Reindexing-Prozess läuft:

112:26PM ??? Reindexing database. This may take a while, please do not cancel it!
212:31PM ??? REINDEX

1uyuni-old # smdba db-start

Auf einigen Systemen, die ich bereits migriert habe, war auch die PostgreSQL-Konfigurationsdatei /var/lib/pgsql/data/pg_hba.conf inkorrekt und musste angepasst werden:

 1local reportdb  postgres  peer
 2local reportdb  all scram-sha-256
 3host  reportdb  all ::/0  scram-sha-256
 4host  reportdb  all 0.0.0.0/0 scram-sha-256
 5host  reportdb  all ::1/128 scram-sha-256
 6host  reportdb  all 127.0.0.1/32  scram-sha-256
 7local uyuni postgres  peer
 8local uyuni uyuni scram-sha-256
 9host  uyuni uyuni 127.0.0.1/32  scram-sha-256
10host  uyuni uyuni ::1/128 scram-sha-256
11local replication all peer
12host  replication all ::1/128 ident
13host  replication all 127.0.0.1/32  ident
14local all all peer
15host  all all ::1/128 ident
16host  all all 127.0.0.1/32  ident
17local replication postgres  peer
18host uyuni uyuni 10.89.0.8/16 scram-sha-256

Auf manchen Systemen fand ich nach der Migration doppelte Hostname-Definitionen in der Datei /etc/rhn/rhn.conf innerhalb des Containers - diese müssen entfernt bzw. auskommentiert werden, damit die Anwendung startet. Auch der Datenbankhost für die Reporting-Datenbank könnte falsch sein:

1# java.hostname = uiuiuiuyuni1337
2java.hostname = uiuiuiuyuni1337
3
4# report_db_host = uiuiuiuyuni1337
5report_db_host = localhost

Ein weiterer Bug in der Version 2024.10 scheint zu sein, dass die Anwendung beim Starten des Containers nicht automatisch gestartet wird. Ein Workaround ist es, diese manuell innerhalb des Containers zu starten:

1# mgtctl term
2# spacewalk-service start
3# exit

SUSE Manager 5.0 auf IBM POWER

Etwas intransparenter ist der Betrieb von SUSE Manager 5.0 auf der IBM POWER-Plattform. So gibt es im Download-Portal entsprechende zwar Dateien für u.a. für ppc64le - allerdings ist nicht ganz klar, was sich hinter dem Download verbrigt. Der entsprechende Abschnitt der Dokumentation ist hier nicht hilfreich, da dieser suggeriert, dass SLE Micro 5.5 auf POWER ausgeführt werden kann - aber das ist nicht der Fall. SLE Micro 5.5 und 6.0 sind nicht für die ppc64le-Plattform erhältlich - erst mit der kommenden Version 6.1 wird sich dies ändern.

Eine Nachfrage beim Support ergab, dass das Image innerhalb einer KVM-Instanz betrieben werden kann. In einem solchen Szenario würde SLE 15 nativ in einer LPAR installiert und dann das Image als Gast betrieben werden. Eine andere Option ist es, das Image mittels dd direkt auf die Festplatte einer LPAR zu schreiben. Beide Vorgehensweise werden vom Support abgedeckt.

Ich denke, dass diese Problematik mit dem nächsten SUSE Manager-Release behoben werden dürfte, da gerade SUSE Linux 6.1 mit offiziellem IBM POWER-Support erschienen ist.