SUSE Multi-Linux Manager 5.2: erste Linux-Clients produktiv onboarden

Ziel dieser Anleitung

Dieser Beitrag ordnet SUSE-Plattform praktisch ein und zeigt, welche Entscheidungen für eine belastbare Umsetzung wichtig sind. Am Ende soll klar sein, was vorbereitet werden muss, woran du einen funktionierenden Stand erkennst und welcher nächste Schritt sinnvoll ist.

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

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.

Nach der Installation wird SUSE Multi-Linux Manager erst dann wertvoll, wenn echte Systeme angebunden sind. Diese Anleitung zeigt Schritt für Schritt, wie du einen SLES-16-Client produktiv vorbereitest, per Activation Key registrierst, den Salt-Key akzeptierst und den Client im Manager prüfst.

Die Beispiele verwenden neutrale Hostnamen. Übertrage sie auf deinen echten Manager-FQDN, dein Zertifikatsmodell und deine Netzwerkstruktur.

SUSE-Serie: vom Server zur verwalteten Linux-Flotte

Dieser Beitrag ist der dritte Teil der Serie. Du startest nach der SLES-16-Basis und nach der Installation des Managers, damit der erste Client reproduzierbar im System landet.

• 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
• 3. Erste Linux-Clients produktiv onboarden - /de/tech/suse-multi-linux-manager-5-2-clients-onboarden - dieser Beitrag.
• 4. Patch- und Lifecycle-Management - ist als nächster Schritt der Serie vorgesehen.
• 5. Mixed Linux verwalten - ist als nächster Schritt der Serie vorgesehen.
• 6. Produktiven Betrieb härten - ist als nächster Schritt der Serie vorgesehen.

Zielbild

Am Ende kennt der Manager den Client als Salt-System, der Client verwendet den Manager-Kanal statt direkter SCC-Repositories, die Zeit ist synchron, die Verbindung über HTTPS und Salt funktioniert, und erste Patches beziehungsweise Paketabweichungen sind sichtbar.

Client-Onboarding ist der Moment, in dem aus einem installierten Manager eine echte Betriebsplattform wird. Der Manager muss nicht nur ein System in der Liste anzeigen, sondern den Client korrekt erkennen, passenden Channels zuordnen, Salt-Kommunikation herstellen und Paket- beziehungsweise Patchzustand zuverlässig melden.

app.example.com

Voraussetzungen

Prüfe vor jedem Onboarding Zeit, DNS, Namensauflösung, Firewall und HTTPS-Erreichbarkeit. Abweichende Uhrzeiten oder falsche FQDNs erzeugen später Fehler, die wie Salt-, Zertifikats- oder Repository-Probleme aussehen, obwohl die Ursache in der Basis liegt.

• SUSE Multi-Linux Manager 5.2 ist installiert, über FQDN erreichbar und im Web-UI nutzbar.
• Die benötigten Produkte und Channels sind aus dem SCC Product Catalog synchronisierbar.
• Der Client erreicht den Manager per HTTPS sowie die Salt-Ports 4505 und 4506.
• DNS oder interne Namensauflösung funktioniert in beide Richtungen sinnvoll.
• NTP ist auf Manager und Client aktiv.
• Du hast Adminzugriff auf Manager und Root- beziehungsweise sudo-Zugriff auf den Client.

Beispieltopologie

• Manager: <mlm-fqdn>
• Client: <client-fqdn>
• Netz: internes Servernetz
• Rollen: Manager synchronisiert Channels, Client registriert sich per Bootstrap und Salt

Verwende in Produktion keine temporären Namen aus dem Artikel, sondern deinen echten internen FQDN. Der FQDN muss für Client, Manager, Zertifikate und Web-UI konsistent sein.

1. Produkt und Channel vorbereiten

Öffne im Manager den Product Catalog und wähle den passenden Basis-Channel für die Distribution, Architektur und Version deines Clients. Für diesen Test ist das SLES 16.0 für x86_64.

Ein Client kann nur sauber registriert werden, wenn sein Basiskanal und die passenden Client Tools verfügbar sind. Bei SUSE-Systemen kommen die Channels aus SCC. Bei Debian, Ubuntu, Rocky oder Alma hängt der genaue Weg vom unterstützten Produktkatalog und den synchronisierten ManagerTools ab.

app.example.com

Der gleiche Schritt ist auch per CLI möglich. Für produktive Umgebungen solltest du Channel-Entscheidungen dokumentieren, weil sie später Patch-Management, Lifecycle und Reporting beeinflussen.

mgr-sync add --no-optional --no-recommends --no-sync channel sle-product-sles-16.0-x86_64
spacewalk-repo-sync --channel sle-product-sles-16.0-x86_64 --type yum --non-interactive

2. Bootstrap-Repository erzeugen

Der Bootstrap-Prozess installiert auf dem Client den passenden Salt-Minion und registriert das System anschließend am Manager. Dafür muss der Manager ein Bootstrap-Repository für die Zielplattform bereitstellen.

mgr-create-bootstrap-repo -l
mgr-create-bootstrap-repo -c SLE-16.0-x86_64

Wenn der Bootstrap später mit 404 auf `/pub/repositories/.../bootstrap` scheitert, fehlt dieses Repository oder der Channel-Sync war noch nicht vollständig.

3. Activation Key anlegen

Ein Activation Key bündelt die Registrierungseigenschaften für Clients: Base Channel, optionale Child Channels, Gruppen, Add-ons und weitere Vorgaben. Verwende pro Distribution, Version, Architektur und Betriebsrolle sprechende Keys statt eines unspezifischen Default-Keys.

Activation Keys sind der kontrollierte Übergabepunkt zwischen Betriebskonzept und Client. Sie definieren Organisation, Base Channel, Child Channels, Systemgruppen und optionale Parameter. Für produktive Umgebungen legst du Keys nach Rolle, Distribution und Lifecycle-Ziel an, nicht als universellen Sammelschlüssel.

app.example.com

spacecmd -q -u admin -p '[PASSWORD]' activationkey_create -- \
  -n 'sles16-x86_64-prod' \
  -d 'SLES 16 x86_64 production onboarding key' \
  -b sle-product-sles-16.0-x86_64

Der finale Key kann im Manager je nach Organisation mit einer Organisations-ID als Präfix angezeigt werden. Verwende im Bootstrap den Key genau so, wie ihn der Manager anzeigt.

4. Client vorbereiten

Vor dem Bootstrap muss der Client einen stabilen Hostnamen haben, den Manager per FQDN auflösen können, eine synchronisierte Uhr besitzen und den Manager per HTTPS erreichen.

app.example.com

app.example.com

hostnamectl
timedatectl
getent hosts <mlm-fqdn>
curl -kI https://<mlm-fqdn>/rhn/Login.do

5. Bootstrap-Skript erzeugen

Das Bootstrap-Skript wird auf dem Manager erzeugt und unter `/srv/www/htdocs/pub/bootstrap/` bereitgestellt. Der Client lädt es per HTTPS herunter.

mgr-bootstrap \
  --activation-keys='[ORG]-sles16-x86_64-prod' \
  --hostname=<mlm-fqdn> \
  --script=bootstrap-sles16-client01.sh \
  --force

6. Bootstrap auf dem Client ausführen

Führe das Skript als root oder mit sudo auf dem Client aus. Der erfolgreiche Lauf erkennt die Distribution, lädt das Bootstrap-Repository, installiert den venv-Salt-Minion, registriert das System und startet den Minion.

Das Bootstrap-Skript verbindet den Client mit dem Manager, installiert die benötigten Werkzeuge, setzt Repository-Informationen und bereitet Salt vor. Danach ist der Client noch nicht fachlich abgenommen: Erst Salt-Key, Systemdetailseite, Channel-Zuordnung und erster Check-in zeigen, ob das Onboarding wirklich fertig ist.

curl -kfsS https://<mlm-fqdn>/pub/bootstrap/bootstrap-sles16-client01.sh \
  -o /root/bootstrap-sles16-client01.sh
chmod 700 /root/bootstrap-sles16-client01.sh
/root/bootstrap-sles16-client01.sh

Erwartetes Ergebnis:

• CA-Zertifikat wird vom Manager geholt
• SLE 16.0 wird erkannt
• Bootstrap-Repository wird verwendet
• venv-salt-minion wird installiert
• System wird registriert
• venv-salt-minion wird aktiviert und gestartet
• bootstrap complete

7. Salt-Key akzeptieren

Nach dem Bootstrap wartet der Minion normalerweise mit einem unaccepted Key auf dem Manager. Akzeptiere nur Keys, deren Hostname und Herkunft du eindeutig zuordnen kannst.

salt-key -L
salt-key -a <client-fqdn> -y
salt <client-fqdn> test.ping --out=txt

Ein erfolgreiches `test.ping` liefert `True`. Damit ist die Salt-Kommunikation technisch hergestellt.

8. Client im Manager prüfen

Öffne Systems -> System List -> All. Der Client sollte mit System Type Salt, Base Channel, Last Check-In sowie Paket- und Patchinformationen sichtbar sein.

app.example.com

9. Ersten Patch- und Paketstatus ansehen

Nach dem ersten Check-in kann der Manager Paket- und Patchinformationen bewerten. Der eigentliche Patchlauf gehört in den nächsten Artikel, aber an dieser Stelle muss sichtbar sein, ob der Client verwaltbar ist.

app.example.com

Troubleshooting aus dem realen Test

• Bootstrap-Repository fehlt: Wenn der Client das Bootstrap-Repository nicht findet, zuerst den passenden Channel synchronisieren und `mgr-create-bootstrap-repo -c ...` ausführen.
• Großer Channel-Sync bricht ab: Prüfe RAM, Storage und Swap. Für produktive Installationen empfiehlt SUSE ausreichend schnelle persistente Volumes und 8 bis 12 GB Swap.
• Salt-Key bleibt unaccepted: Key-Liste prüfen, Hostname validieren und anschließend gezielt akzeptieren.
• Client nutzt noch alte Repositories: Repository-Liste prüfen. Nach erfolgreicher Registrierung sollte der Manager-Kanal aktiv sein.
• Namensauflösung ist instabil: FQDN, Reverse DNS, `/etc/hosts` in kleinen Labs und Firewall-Regeln sauberziehen, bevor du erneut bootstrappst.

Produktionscheck vor dem nächsten Schritt

• Manager-FQDN ist stabil und per Zertifikat sauber erreichbar.
• SLES-16-Channel ist synchronisiert und Bootstrap-Repository ist vorhanden.
• Activation Key ist eindeutig benannt und dokumentiert.
• Client-Zeit ist synchronisiert.
• HTTPS, 4505 und 4506 sind vom Client zum Manager erreichbar.
• Salt-Key wurde bewusst akzeptiert.
• Client erscheint in der Systemliste mit korrektem Base Channel.
• Paket- und Patchinformationen werden sichtbar.

Nächster Teil: Patch- und Lifecycle-Management

Der nächste Artikel baut auf diesem Zustand auf: Updates bewerten, Patches klassifizieren, Wartungsfenster planen, Testgruppen nutzen und den ersten kontrollierten Patchlauf ausführen.

Quellen

• SUSE Multi-Linux Manager 5.2 Dokumentation: Client-Onboarding
• SUSE Multi-Linux Manager 5.2 Dokumentation: Registrierungsmethoden
• SUSE Multi-Linux Manager 5.2 Dokumentation: Activation Keys
• SUSE Multi-Linux Manager 5.2 Dokumentation: Server Deployment und Systemanforderungen

Abnahme mit mehreren Distributionen

Im realen Test wurden SLES 16, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10 und AlmaLinux 10 als Salt-Clients registriert. Für alle fünf Systeme lieferte `test.ping` erfolgreich `True`; die Systeme erschienen in der Systemliste mit aktuellem Check-in.

app.example.com

app.example.com

Wichtige Unterschiede beim Onboarding

Multi-Linux bedeutet nicht, dass jede Distribution identisch behandelt wird. SLES und SL Micro folgen dem SUSE-Entitlement- und Channel-Modell, Debian und Ubuntu haben eigene Paket- und Security-Streams, RHEL-kompatible Systeme brauchen passende Content- und Support-Entscheidungen. Der Manager vereinheitlicht Betrieb und Sichtbarkeit, aber er löscht die Unterschiede der Distributionen nicht aus.

• ManagerTools gehören zur jeweiligen Distribution. Ein Base Channel allein reicht für das Bootstrap nicht zuverlässig aus.
• Das Bootstrap-Repository wird erst nach vollständigem Content- und ManagerTools-Sync erzeugt.
• Product-Catalog-Labels im eigenen Manager prüfen; Rocky Linux 10 war im Test mit `rockylinux-10-x86_64` nutzbar, obwohl Dokumentationsbeispiele anders aussehen können.
• Ubuntu braucht ein bewusstes sudo/root-Modell, weil ein direkter Root-Login häufig nicht vorgesehen ist.
• Oracle Linux muss vor dem Rollout besonders auf Repository-Modell, Kernel-Variante und Bootstrap-Unterstützung geprüft werden.

• 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
• 3. Erste Linux-Clients produktiv onboarden: /de/tech/suse-multi-linux-manager-5-2-clients-onboarden - dieser Beitrag.
• 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.

Multi-Distro-Onboarding: geprüfte Clients

Im Test waren fünf unterschiedliche Client-Familien erfolgreich angebunden: SLES 16, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10 und AlmaLinux 10. Der Manager sieht sie als Salt-Minions, liest OS-Grains aus und kann Paket- beziehungsweise Patchinformationen zentral darstellen.

app.example.com

salt '*client01.lab.example' test.ping --out=txt
salt '*client01.lab.example' grains.item os osrelease osfinger --out=json

Was Activation Keys leisten

Activation Keys verbinden Registrierung, Base Channel, Child Channels, Systemgruppen und Kontaktmethode. Für Produktion solltest du pro Distribution, Umgebung und Verantwortungsbereich eigene Keys nutzen, statt einen universellen Schlüssel für alles einzusetzen.

• SLES-Clients bekommen SUSE-Channels und direkten SCC-/SLES-Lifecycle.
• Debian und Ubuntu bleiben apt-basierte Systeme und brauchen passende Bootstrap- und Repository-Logik.
• Rocky und AlmaLinux folgen dem RHEL-kompatiblen Paketmodell, sind aber eigene Distributionen.
• Oracle Linux ist grundsätzlich ein Ziel, benötigt aber saubere Repository- und Support-Abgrenzung.
• SL Micro eignet sich für Appliance-, Edge- und Containerhost-Szenarien; transactional updates müssen im Betrieb verstanden werden.

Abnahme nach dem Onboarding

1. Client erscheint in Systems -> System List -> All.
2. Last Check-In ist aktuell.
3. Salt test.ping liefert True.
4. OS-Grains zeigen erwartete Distribution und Version.
5. Base Channel und Systemgruppe passen zur Distribution.
6. Patch- oder Paketstatus ist sichtbar.
7. Ein Testkommando über den Manager läuft erfolgreich.