SUSE Multi-Linux Manager 5.2 produktiv installieren: SL Micro, Storage und erster Channel-Sync

Voraussetzungen

Du brauchst passende SUSE-Images, Entitlements, DNS, NTP, Storage, Netzwerkfreigaben und administrative Zugänge. Registrierungs- und Mirroring-Daten bleiben außerhalb von Screenshots, Git und öffentlichen Texten.

Kompletter Ablauf der Serie

Diese Reihe führt dich Schritt für Schritt durch den produktiven Aufbau: 1. SLES 16 produktiv installieren · 2. SUSE Multi-Linux Manager 5.2 installieren · 3. Erste Linux-Clients onboarden · 4. Patch- und Lifecycle-Management · 5. Mixed Linux verwalten · 6. OpenSCAP, Compliance und Audit · 7. Proxies für Standorte aufbauen · 8. SSO mit Keycloak integrieren · 9. Ansible neben Salt nutzen · 10. Reporting, Inventar und Audit · 11. Produktiv betreiben und härten

Ziel dieser Anleitung

SUSE Multi-Linux Manager ist die zentrale Lifecycle-Management-Plattform für Linux-Umgebungen. Du verwaltest damit Software-Channels, Patches, Activation Keys, Bootstrap-Prozesse, Salt-basierte Konfiguration, Systemgruppen, Compliance-Informationen und wiederkehrende Betriebsaufgaben an einer Stelle.

Der Mehrwert liegt vor allem dort, wo einzelne Server nicht mehr einzeln gepflegt werden sollen: SLES, SL Micro und ausgewählte andere Linux-Distributionen lassen sich kontrolliert registrieren, mit geprüften Paketquellen versorgen, patchen, gruppieren und nachvollziehbar betreiben. Aus manueller Serverpflege wird ein reproduzierbarer Plattformprozess.

Dieser erste Multi-Linux-Manager-Beitrag baut deshalb bewusst die Serverplattform auf. Clients, Patch-Staging, gemischte Distributionen und Härtung folgen danach in eigenen Teilen, damit jeder Schritt sauber nachvollziehbar bleibt.

Diese Anleitung zeigt, wie du SUSE Multi-Linux Manager 5.2 auf SL Micro 6.2 so aufsetzt, dass daraus eine belastbare Plattform für Linux-Lifecycle-Management wird. Am Ende ist der Manager installiert, registriert, mit separatem Storage vorbereitet, über die Weboberfläche erreichbar und der erste Channel erfolgreich synchronisiert.

Der Fokus liegt nicht auf einer schnellen Demo, sondern auf einem produktiven Aufbau: saubere DNS- und Storage-Entscheidungen, registrierter Content, nachvollziehbare Checks, kontrollierter erster Sync und eine klare Übergabe in den Betrieb.

SUSE Multi-Linux Manager ist die zentrale Lifecycle-Plattform für Linux-Umgebungen. Du steuerst damit Software-Channels, Updates, Security Advisories, Activation Keys, Bootstrap-Prozesse, Salt-basierte Verwaltung, Systemgruppen, Reporting und wiederkehrende Betriebsaufgaben über eine gemeinsame Oberfläche.

Der Nutzen entsteht nicht erst bei hunderten Systemen. Schon bei wenigen produktiven Servern hilft der Manager, Paketquellen, Patchstände, Verantwortlichkeiten und Wartungsfenster nachvollziehbar zu halten. Statt jeden Server einzeln zu pflegen, baust du ein reproduzierbares Betriebsmodell auf.

Vorbereitung für den produktiven Betrieb

SUSE Multi-Linux Manager ist ein zentrales System. Wenn er später Patches, Channels, Bootstrap-Repositories und Client-Konfigurationen steuert, müssen Netzwerk, Storage, Backup und Zugriff von Anfang an sauber geplant sein.

Plane den Manager wie eine zentrale Infrastrukturkomponente. Wenn der Manager ausfällt, verlieren Clients nicht sofort ihren laufenden Betrieb, aber Patchsteuerung, Reporting, Bootstrap und zentrale Aktionen sind eingeschränkt. Deshalb gehören DNS, NTP, Storage, Backup, Zertifikate und Monitoring vor dem ersten Client-Rollout zur Basis.

• FQDN und DNS: stabiler Hostname, Forward-/Reverse-DNS und Zertifikatsplanung.

• Ressourcen: ausreichend CPU/RAM für Web-UI, Datenbank, Repository-Sync und spätere Client-Zahl.

• Storage: separate Datenplatte für Manager-Volumes und Repository-Content, nicht nur die Systemdisk.

• Content-Zugriff: SUSE Customer Center oder freigegebene Mirroring Zugangsdaten; keine sicheres Geheimniss in Abbildungen oder Runbooks.

• Firewall: HTTPS, SSH, Salt-Ports und Cockpit bewusst freigeben, nicht pauschal alles öffnen.

• Betrieb: Backup, Monitoring, Patchfenster, Rollenmodell und Dokumentation vor dem Client-Rollout klären.

Image herunterladen und prüfen

Für diese Installation wurde das offizielle SUSE-Multi-Linux-Manager-Server-5.2-QCOW2-Image verwendet. Lade das Image nur aus SUSE Customer Center oder einem freigegebenen internen Mirror und prüfe die SHA-256-Summe gegen die offizielle Metadatei.

sha256sum SUSE-Multi-Linux-Manager-Server.x86_64-5.2.0-Qcow-GM.qcow2
# Ausgabe mit der offiziellen SUSE-Prüfsumme für genau dieses Image vergleichen.

Wenn zusätzlich eine Signaturdatei bereitsteht, prüfst du sie mit dem passenden SUSE Public Key. Die Prüfung muss in der internen Doku nachvollziehbar sein; öffentliche Artikel enthalten keine account-spezifischen Download-URLs oder Zugangsdaten.

VM produktiv anlegen

Der Manager läuft als Appliance auf SL Micro 6.2. Für den Aufbau wurde UEFI/OVMF, eine Systemdisk und eine separate Datenplatte verwendet. Die separate Datenplatte ist wichtig, weil Repository-Content und persistente Container-Volumes wachsen.

qemu-img create -f qcow2 -b SUSE-Multi-Linux-Manager-Server.x86_64-5.2.0-Qcow-GM.qcow2 -F qcow2 mlm52-system.qcow2
qemu-img create -f qcow2 mlm52-data.qcow2 300G

Plane produktiv größer als ein Minimal-Lab. Repository-Sync, Datenbank, Bootstrap-Repositories, Logs und Backups brauchen Reserve. Der erste Sync für SL Micro 6.2 belegte bereits deutlich messbaren Platz im Manager-Storage.

Firstboot und Basissystem prüfen

Beim ersten Start setzt du Hostname, Netzwerk und Admin-Zugang. Danach prüfst du, ob das Basissystem sauber läuft, bevor `mgradm` installiert. Diese Trennung ist wichtig: erst Appliance-Basis stabilisieren, dann den Manager-Stack deployen.

https://mlm01.example.test/

Firstboot der SUSE-Multi-Linux-Manager-Appliance mit neutralem Hostnamen.

hostnamectl
cat /etc/os-release
systemctl --failed
ip address
ip route

System registrieren und aktualisieren

Registriere das System mit der passenden SUSE-Subscription und prüfe den Status. Registrierungswerte werden nicht in Logs, Abbildungen oder öffentliche Dokumentation übernommen. Nach der Registrierung wird SL Micro über `transactional-update` aktualisiert und neu gestartet, wenn ein Reboot erforderlich ist.

sudo SUSEConnect --status-text
sudo transactional-update
sudo reboot

Manager-Storage vorbereiten

Für SUSE Multi-Linux Manager 5.2 werden persistente Podman-Volumes und Repository-Content auf separatem Storage abgelegt. In der geprüften Installation wurde die Datenplatte mit `mgr-storage-server` vorbereitet und als XFS-Volume für `/var/lib/containers/storage/volumes` genutzt.

Storage ist bei SUSE Multi-Linux Manager kein Detail. Channels, Paketmetadaten, Images, Logs und Datenbankinhalte wachsen mit jeder zusätzlichen Distribution. Trenne deshalb Systemdisk und Manager-Daten frühzeitig, dokumentiere Mountpoints und beobachte Kapazität, bevor der erste große Sync läuft.

lsblk
sudo mgr-storage-server /dev/vdb
findmnt /var/lib/containers/storage/volumes
df -h /var/lib/containers/storage/volumes

https://mlm01.example.test:9090/system/storage

Cockpit Storage zeigt die separate Datenplatte für Manager-Volumes und Repository-Content.

Manager mit mgradm installieren

Der primäre Installationsbefehl für diese geprüfte 5.2-Umgebung ist `mgradm install <fqdn>`. Der FQDN muss zum geplanten Servernamen passen, weil er später in Web-UI, Zertifikaten, Clients und Bootstrap-Konfigurationen sichtbar wird.

`mgradm` baut den containerisierten Manager aus den vorbereiteten Komponenten auf. Wichtig ist, dass du diesen Schritt nicht als Blackbox behandelst: Notiere FQDN, Zertifikatsentscheidung, Adminzugang, Containerstatus und Servicezustand. Danach muss die Weboberfläche erreichbar sein und die CLI muss den Zustand prüfen können.

sudo mgradm install mlm01.example.test
sudo mgradm status
sudo podman ps
systemctl status uyuni-server.service --no-pager
systemctl status uyuni-db.service --no-pager

Nach erfolgreicher Installation laufen der Server- und Datenbank-Container healthy. Wenn `mgrctl status` in deiner Umgebung nicht verfügbar ist, verwendest du `mgradm status`, systemd und Podman-Checks.

Weboberfläche öffnen und Admin-Login prüfen

Öffne die Manager-Weboberfläche über den finalen FQDN und melde dich mit dem eingerichteten Admin an. Für produktive Systeme sollte dieser Zugriff über TLS, Firewall-Regeln, Admin-Netze und Rollenmodell abgesichert werden.

https://mlm01.example.test/

Login zur SUSE-Multi-Linux-Manager-Weboberfläche über den geplanten FQDN.

https://mlm01.example.test/

Dashboard nach erfolgreichem Login mit sichtbarer Manager-Version 5.2.

Cockpit für Day-2-Betrieb prüfen

Cockpit ersetzt nicht das Lifecycle-Management im Manager, hilft aber bei Day-2-Aufgaben des Appliance-Hosts: Systemstatus, Netzwerk, Services, Storage und schnelle Diagnose. Das ist besonders wertvoll, bevor Clients angebunden werden.

https://mlm01.example.test:9090/system

Cockpit-Systemübersicht der installierten SL-Micro-basierten Manager-Appliance.

https://mlm01.example.test:9090/network

Netzwerkansicht in Cockpit zur Kontrolle der Management-Verbindung.

Setup Wizard starten

Nach dem technischen Deployment richtet der Setup Wizard die Content-Anbindung ein. Das ist der Punkt, an dem aus einem installierten Server eine nutzbare Manager-Plattform wird.

https://mlm01.example.test/

Navigation zum Setup Wizard in der Manager-Weboberfläche.

SCC Mirroring Zugangsdaten sicher eintragen

Die Mirroring Zugangsdaten gehören ausschließlich in das dafür vorgesehene Formular. Sie werden nicht in Abbildungen, Shell-History, Tickets oder Blogtexte geschrieben. Nach dem Speichern lädt der Manager den Product Catalog aus SUSE Customer Center.

https://mlm01.example.test/

Formular für Zugangsdaten ohne sichtbare Zugangswerte vor dem Speichern.

https://mlm01.example.test/

Geladener Product Catalog nach erfolgreicher SCC-Anbindung.

Erstes Produkt und ersten Channel synchronisieren

Starte nicht direkt mit allen Produkten. Für den ersten produktiven Sync wählst du ein klar begrenztes Zielprodukt, prüfst die Channels und synchronisierst kontrolliert. In der geprüften Umgebung wurde `SUSE Linux Micro 6.2 x86_64` verwendet, inklusive Manager-Tools-Channel.

Der erste Sync beweist, dass SCC-Zugangsdaten, Product Catalog, Channel-Auswahl, Storage und Hintergrundjobs zusammenspielen. Für produktive Umgebungen startest du bewusst klein: ein Produkt, ein klarer Ziel-Channel, danach Status prüfen. Erst wenn dieser Weg stabil ist, folgen weitere Produkte und Distributionen.

https://mlm01.example.test/

Product Catalog nach Filterung auf SL Micro 6.2.

https://mlm01.example.test/

Ausgewähltes SL-Micro-6.2-Produkt vor dem Hinzufügen der Channels.

https://mlm01.example.test/

Der erste Repository-Sync wurde geplant und gestartet.

https://mlm01.example.test/

Abgeschlossener Sync-Status für den ersten SL-Micro-6.2-Channel.

Repository-Sync auf der CLI prüfen

Die Weboberfläche zeigt den Sync-Status, aber für eine belastbare Abnahme prüfst du zusätzlich Logs, Channels und Storage-Verbrauch. Ausgaben mit temporär signierten Repository-URLs werden nicht ungefiltert weitergegeben.

sudo podman ps
sudo mgradm status
sudo journalctl -u uyuni-server.service -n 80 --no-pager
sudo du -sh /var/lib/containers/storage/volumes/var-spacewalk
df -h /var/lib/containers/storage/volumes

Firewall, Dienste und Health prüfen

Vor dem ersten Client-Rollout muss klar sein, welche Ports gewollt offen sind und welche Services laufen. HTTPS und Salt-Kommunikation sind für den Manager zentral; SSH und Cockpit sollten auf Admin-Netze begrenzt werden.

systemctl --failed
sudo ss -tulpn
sudo firewall-cmd --state || true
sudo firewall-cmd --list-all || true
sudo podman volume ls

Backup und Restore nicht auf später verschieben

Sobald der Manager Channels, Keys, Clients und Policies verwaltet, wird er kritisch. Richte Backup ein, bevor du produktive Clients registrierst. Prüfe außerdem, wo Datenbank, Repository-Content, Konfiguration und Zertifikate liegen.

sudo mgradm backup --help
sudo mgradm backup create --help

Produktions-Checkliste vor dem Client-Rollout

• FQDN, DNS, TLS und Admin-Zugriff sind final.

• System und Manager-Extension sind registriert.

• Separate Storage-Volumes sind eingerichtet und haben ausreichende Reserve.

• Manager-Container und systemd-Units sind healthy.

• Erster Repository-Sync ist erfolgreich abgeschlossen.

• Bootstrap-Repositories sind regeneriert.

• Backup, Monitoring, Logs und Patchfenster sind definiert.

• Rollenmodell und Zugriff auf Web-UI, SCC-Zugangsdaten und Clients sind geklärt.

• Erst danach werden Test-Clients und anschließend produktive Systeme angebunden.

Was als Nächstes kommt

Nach der Serverinstallation folgen die nächsten sinnvollen Schritte: Bootstrap eines SL-Micro- oder SLES-Clients, Channel- und Lifecycle-Strategie, Patch-Staging, Gruppen, Aktivierungsschlüssel, Compliance-Reports und später der Proxy-Betrieb für verteilte Standorte. Diese Themen gehören in eigene Anleitungen, damit der Installationsartikel klar bleibt.

Architektur: was der Manager wirklich bereitstellt

• SL Micro 6.2: stabiler Containerhost
• Podman + Netavark: Manager-Container und Netzwerk
• Persistente Podman-Volumes: Datenbank, Konfiguration und Repository-Content
• SUSE Customer Center Product Catalog: verfügbare Produkte und Channels
• Channel Sync: lokal verwalteter Content
• Linux-Clients: Registrierung, Salt, Patch- und Paketstatus

Wo finde ich was in SUSE Multi-Linux Manager 5.2?

• 1. SLES 16 produktiv installieren: /de/tech/sles-16-installieren
• 2. SUSE Multi-Linux Manager 5.2 produktiv installieren: /de/tech/suse-multi-linux-manager-5-2-sl-micro-installieren - dieser Beitrag.
• 3. Erste Linux-Clients produktiv onboarden: /de/tech/suse-multi-linux-manager-5-2-clients-onboarden
• 4. Patch- und Lifecycle-Management produktiv aufbauen: /de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management
• 5. Mixed Linux produktiv verwalten: /de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten

Betrieb und Validierung

Für den produktiven Betrieb reicht eine erfolgreiche Installation allein nicht aus. Prüfe Dienste, Logs, Netzwerk, Anmeldung, Updates, Backup und Wiederherstellung so, dass der Zustand wiederholbar und für andere Administratoren nachvollziehbar bleibt.

Quellen und weiterführende Dokumentation

Nutze für produktive Umsetzung zusätzlich die aktuelle Herstellerdokumentation, Release Notes, Sicherheitsmeldungen und die internen Betriebsstandards. ForgeOne ergänzt diese Quellen mit praktischer Projekterfahrung aus Planung, Umsetzung und Betrieb.

Produktionscheckliste

• Ziel, Scope und Verantwortlichkeiten sind dokumentiert.
• DNS, TLS, Netzwerk, Accounts und Berechtigungen sind geprüft.
• Installation oder Änderung wurde mit UI- und CLI-Signalen validiert.
• Backup, Monitoring, Updates und Rollback sind vor produktiver Nutzung geklärt.
• Lizenzen, Supportwege und Professional Services sind für den Betrieb eingeplant.

Funktionsumfang: was SUSE Multi-Linux Manager abdeckt

SUSE Multi-Linux Manager ist die zentrale Betriebsplattform für heterogene Linux-Flotten. Du verwaltest darüber Produkte und Software-Channels, registrierst Clients, steuerst Salt-basierte Konfiguration, bewertest Patches und CVEs, baust Content-Lifecycle-Umgebungen, planst Aktionen, erzeugst Reports und prüfst Compliance über OpenSCAP.

• Product Catalog und Channel-Sync aus SUSE Customer Center als Content-Basis.
• Activation Keys, Bootstrap und Salt Bundle für reproduzierbares Client-Onboarding.
• Systemlisten, Gruppen, Paketstatus und Patchstatus als tägliche Betriebsansicht.
• Content Lifecycle Management für Dev-, Test- und Produktionsfreigaben.
• OpenSCAP, CVE-Audit, Subscription Matching und Reports für Auditierbarkeit.
• Backup, Restore, Zertifikate, Monitoring, Rollen und Storage-Planung für den Dauerbetrieb.

Der Mehrwert liegt nicht darin, jede Distribution gleichzumachen. Der Mehrwert liegt darin, unterschiedliche Linux-Systeme sichtbar, wartbar und auditierbar in einem gemeinsamen Betriebsmodell zu führen.

app.example.com

Produktionscheck nach der Installation

1. Manager-FQDN löst intern und extern korrekt auf.
2. TLS-Zertifikat und Browser-Zugriff über HTTPS funktionieren auf Port 443.
3. Persistente Volumes liegen auf geplantem Storage und haben ausreichend Reserve.
4. SCC-Organisation ist angebunden, Zugangsdaten liegen nicht in Shell-History oder Dokumentation.
5. Product Catalog ist sichtbar und mindestens ein benötigter Channel wurde synchronisiert.
6. Admin-Konto, Rollenmodell, Backup-Ziel und Monitoring sind definiert, bevor produktive Clients angebunden werden.

Product Catalog, Channels und erster Sync als Betriebsgrundlage

Nach der Grundinstallation ist der Manager erst dann produktiv nutzbar, wenn der Product Catalog geladen ist und die benötigten Channels bewusst ausgewählt wurden. Genau daraus entstehen später Activation Keys, Bootstrap-Skripte, Patchstatus, CVE-Audit und Reports.

app.example.com

Für den Aufbau der Serie wurden die relevanten Channel-Familien für SLES 16, SL Micro 6.2, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10, AlmaLinux 10 und Oracle Linux 10 geprüft beziehungsweise eingeordnet. In Produktion dokumentierst du zusätzlich pro Channel: Zweck, Zielgruppe, Sync-Fenster, Retention, Verantwortlichkeit und zugehörigen Activation Key.

app.example.com