SUSE Multi-Linux Manager 5.2: Mixed Linux produktiv verwalten

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.

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.

Viele gewachsene Linux-Landschaften bestehen nicht aus einer Distribution. Neben SLES laufen oft SL Micro, Debian, Ubuntu, Rocky Linux, AlmaLinux oder Oracle Linux. Genau hier spielt SUSE Multi-Linux Manager seine Stärke aus: zentrale Sichtbarkeit, nachvollziehbare Registrierung, Patch- und Paketstatus, Salt-basierte Steuerung und ein gemeinsames Betriebsmodell.

Wichtig ist die richtige Erwartung: Multi-Linux bedeutet nicht, dass alle Distributionen gleich werden. Paketmanager, Repository-Modelle, Supportzuständigkeit und einzelne Funktionen bleiben unterschiedlich. Der Mehrwert liegt darin, diese Unterschiede kontrolliert in eine gemeinsame Betriebsplattform zu bringen.

Zielbild für eine heterogene Flotte

Ein professioneller Multi-Linux-Betrieb trennt bewusst zwischen Standardisierung und Gleichmacherei. Standardisiert werden Inventar, Verantwortlichkeiten, Wartungsfenster, Patch-Auswertung und Reporting. Unterschiedlich bleiben Distribution, Paketformat, Release-Modell und Hersteller- beziehungsweise Community-Support.

Der stärkste Punkt von SUSE Multi-Linux Manager ist nicht, dass er nur SUSE-Systeme gut verwaltet. Der Mehrwert entsteht, wenn du SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux und weitere unterstützte Systeme in einem gemeinsamen Betriebsbild siehst, ohne ihre jeweiligen Paket- und Supportmodelle zu vermischen.

Client-Matrix

Eine produktive Matrix trennt drei Dinge: technisch onboardbar, fachlich supportet und betrieblich sinnvoll. Ein System kann im Manager sichtbar sein, aber trotzdem andere Patchquellen, andere Freigabeprozesse oder andere Supportverträge brauchen. Genau diese Unterscheidung macht Mixed-Linux-Betrieb belastbar.

Ein gemeinsamer Onboarding-Standard

Jede Distribution braucht eigene Channels und einen passenden Activation Key. Der Ablauf bleibt aber gleich: Produkt oder Repository vorbereiten, Bootstrap-Repository prüfen, Activation Key erstellen, Client mit sauberem Hostnamen und Zeitbasis vorbereiten, Bootstrap ausführen, Salt-Key akzeptieren und danach Paket- und Patchstatus prüfen.

Der gemeinsame Standard ist DNS, Zeit, HTTPS, Bootstrap, Activation Key, Salt, Systemgruppe, Channel-Zuordnung und erster Patchstatus. Die Unterschiede liegen darunter: Paketmanager, Advisory-Modell, Channel-Struktur, Hersteller-Support und Lifecycle-Ende.

Pro Distribution:

1. Channel/Repository vorbereiten
2. Bootstrap-Repository prüfen
3. Activation Key pro Version und Rolle erstellen
4. Client vorbereiten
5. Bootstrap ausführen
6. Salt-Key akzeptieren
7. Paket- und Patchstatus prüfen
8. Wartungsfenster und Reporting zuordnen

SLES 16

SLES 16 ist der sauberste Startpunkt, weil Produkt, Support, Channels und Lifecycle direkt aus dem SUSE-Ökosystem kommen. Für geschäftskritische Server ist das die Referenzplattform in dieser Serie.

SL Micro 6.2

SL Micro ist besonders für Containerhosts, Appliances und Edge-Szenarien interessant. Im Betrieb musst du transactional-update, Reboot-Planung und das immutable Betriebsmodell bewusst berücksichtigen.

Debian 13 und Ubuntu 24.04 LTS

Debian und Ubuntu bringen apt, andere Release-Modelle und andere Sicherheitsinformationen mit. Multi-Linux Manager hilft, Inventar, Zustände, Remote-Kommandos und Patchprozesse zentral sichtbar zu machen, ersetzt aber nicht die fachliche Bewertung des jeweiligen Distribution-Lifecycles.

Debian und Ubuntu bringen eigene Security- und Update-Streams mit. Im Manager werden sie operational sichtbar, aber die Bewertung bleibt distributionsspezifisch: Welche Repositories sind eingebunden, welche Security-Kanäle sind relevant und wie wird ein produktiver Rollout gegen Applikationsabhängigkeiten getestet?

Rocky Linux und AlmaLinux

Rocky und Alma sind für RHEL-kompatible Workloads relevant. Du arbeitest mit dnf, Enterprise-Linux-Repository-Strukturen und AppStream-/Modulthemen. In heterogenen Umgebungen ist wichtig, Lifecycle- und Supportentscheidungen nicht mit SLES zu vermischen.

Rocky und AlmaLinux sind für viele Umgebungen relevant, weil sie RHEL-kompatible Betriebsmodelle abbilden. Trotzdem müssen Content-Herkunft, Supportanspruch, GPG-Keys, Errata-Sicht und Lifecycle-Regeln bewusst dokumentiert werden. Der Manager hilft bei Standardisierung, ersetzt aber keine Supportentscheidung.

Oracle Linux

Oracle Linux ist in Oracle-nahen Workloads wichtig. Prüfe vor dem Rollout, ob du RHCK oder UEK betreibst, welche Repositories produktiv genutzt werden und wer für Support und Eskalation zuständig ist.

Was zentralisiert wird

Zentralisiert werden Sichtbarkeit, Gruppierung, Bootstrap, Salt-Kommunikation, Patchstatus, Aktionen und Reporting. Dezentral bleiben bewusst OS-spezifische Paketquellen, Herstellerverantwortung, Applikationsfreigaben und tiefere Troubleshooting-Pfade.

• Inventar und Systemstatus über Distributionen hinweg.
• Activation Keys, Gruppen und Rollen je Distribution.
• Patch- und Paketstatus als gemeinsamer Betriebsblick.
• Remote-Kommandos und Salt-basierte Automatisierung.
• Wartungsfenster, Freigaben und Reporting.
• Grundlage für Professional Services und betreibbare Linux-Standards.

Was bewusst getrennt bleibt

• Supportmodell je Distribution und Subscription.
• Paketmanager und Repository-Logik.
• Kernel- und Reboot-Verhalten.
• Security-Advisory-Quellen und CVE-Bewertung.
• Lifecycle-Ende, Extended Support und Migrationspfade.

Produktionscheck

• Für jede Distribution ist ein eigener Activation Key definiert.
• Channels und Repositories sind dokumentiert.
• Supportzuständigkeit ist je Plattform geklärt.
• Wartungsfenster unterscheiden geschäftskritische Systeme von Test- und Nebenrollen.
• Security-Patches werden zentral gesehen, aber distribution-spezifisch bewertet.
• Reporting trennt Compliance, Patchstand und Lifecycle-Risiko.

Im nächsten Teil geht es um die Betriebsbasis des Managers selbst: Backup, TLS, Monitoring, Admin-Rollen, Firewall, Storage-Wachstum, Channel-Sync und Restore-Überlegungen.

Real getesteter Multi-Linux-Stand

Der produktive Mehrwert entsteht durch eine gemeinsame Sicht auf unterschiedliche Plattformen. Im Test waren fünf Distributionen gleichzeitig als Salt-Systeme sichtbar und per Remote-Test erreichbar: SLES 16, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10 und AlmaLinux 10.

Was du daraus für den Betrieb ableitest

• Verwalte nicht alle Distributionen mit einem einzigen generischen Activation Key.
• Dokumentiere pro Distribution Base Channel, ManagerTools, Bootstrap-Repo, Supportmodell und Wartungsfenster.
• Nutze Gruppen für Rollen wie Produktion, Test, Plattformdienste oder Standort.
• Bewerte Advisory- und Patchinformationen distribution-spezifisch, auch wenn die Sicht zentral ist.
• Baue ein gemeinsames Reporting auf, das Compliance, Patchstand und Lifecycle-Risiko trennt.

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.

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.

Warum Mixed Linux mehr ist als eine lange Systemliste

Die Stärke von SUSE Multi-Linux Manager liegt darin, unterschiedliche Linux-Familien in ein gemeinsames Betriebsmodell zu bringen. Das ersetzt nicht das Wissen über jede Distribution, reduziert aber Medienbrüche zwischen Inventar, Patches, Konfiguration, Reports und Audit.

Getestete und eingeordnete Plattformen

• SLES 16: stärkste Integration mit SUSE-Support, SCC, zypper, SELinux, NetworkManager und SLES-Lifecycle.
• SL Micro 6.2: ideal für Appliance-, Edge- und Containerhost-Szenarien; transactional updates und Reboot-Verhalten müssen geplant werden.
• Debian 13: apt-basiert, im Betrieb gut sichtbar, aber mit eigenem Security- und Release-Modell.
• Ubuntu 24.04 LTS: LTS-Lifecycle, apt und eigene Security-Kommunikation; gut geeignet für verbreitete Serverrollen.
• Rocky Linux 10 und AlmaLinux 10: RHEL-kompatible Betriebslogik mit dnf/yum, SELinux und typischen Enterprise-Linux-Prozessen.
• Oracle Linux: unterstütztes Ziel, wenn Repository-, Kernel- und Supportmodell sauber entschieden sind.

Entscheidungsmodell für Kundenprojekte

In Projekten planen wir zuerst, welche Distributionen fachlich wirklich gebraucht werden. Danach entstehen getrennte Activation Keys, Gruppen, Channel-Strategien, Patchfenster und Reports. So bleibt die Plattform flexibel, ohne im Betrieb beliebig zu werden.

Eingebundene Distributionen und Channels sichtbar machen

Der Mehrwert von SUSE Multi-Linux Manager entsteht erst, wenn die Plattform nicht nur SLES sieht, sondern unterschiedliche Linux-Familien vergleichbar inventarisiert, aktualisiert und auswertet.

Die Channel-Ansicht muss dazu passend zeigen, welche Content-Quellen wirklich angebunden sind: SLES-16-Produktchannels, SL-Micro-6.2-Manager-Tools, Debian-13- und Ubuntu-24.04-Updates, Rocky-/AlmaLinux-ManagerTools sowie Oracle-Linux-Content, sofern dieser im Projekt genutzt und sauber lizenziert wird.

• SUSE-Systeme: stärkste Integration mit SCC, SUSEConnect, zypper, Salt und SUSE-Supportmodell.
• Debian und Ubuntu: nützlich für zentrale Sichtbarkeit, Paket- und Patchprozesse, aber mit eigenem Release- und Security-Modell.
• Rocky, AlmaLinux und Oracle Linux: hilfreich für RHEL-kompatible Flotten, aber immer mit klarer Support- und Repository-Abgrenzung.
• openSUSE und weitere Systeme: nur aufnehmen, wenn Lifecycle, Repository-Quelle und Verantwortlichkeit vorher geklärt sind.

https://mlm01.example.test/rhn/manager/systems/list/all

https://mlm01.example.test/rhn/activationkeys/List.do

https://mlm01.example.test/rhn/manager/systems/bootstrap

https://mlm01.example.test/rhn/groups/GroupDetail.do?sgid=13

• SLES 16: System-ID 1000010000, SLES-16-Base-Channel, relevante Security Advisory sichtbar.
• Debian 13: als Debian-Client registriert, Basis für apt-orientierte Flottenprozesse.
• Ubuntu 24.04 LTS: als Ubuntu-Client registriert, LTS-Systeme werden gemeinsam sichtbar.
• Rocky Linux 10 und AlmaLinux 10: RHEL-kompatible Systeme werden in denselben Betriebsraum aufgenommen.
• Oracle Linux 10: Channel-Content ist vorbereitet; produktive Nutzung wird nur bei passendem Support- und Repository-Modell empfohlen.

https://mlm01.example.test/rhn/software/channels/All.do

grommunio-Community-Repositories im Manager

Für grommunio wurde in dieser Umgebung bewusst nur das Community-Repository integriert. grommunio unterstützt Debian, Ubuntu und SUSE/openSUSE-basierte Paketwege; EL-Clients werden dafür nicht als Zielplattform eingeplant.

https://mlm01.example.test/rhn/channels/manage/repos/RepoList.do

https://mlm01.example.test/rhn/channels/manage/repos/RepoEdit.do?id=519

https://mlm01.example.test/rhn/channels/manage/repos/RepoEdit.do?id=520

https://mlm01.example.test/rhn/channels/ChannelDetail.do?cid=121

https://mlm01.example.test/rhn/channels/ChannelPackages.do?cid=121

https://mlm01.example.test/rhn/channels/ChannelDetail.do?cid=122

https://mlm01.example.test/rhn/channels/ChannelPackages.do?cid=122

https://mlm01.example.test/rhn/channels/ChannelDetail.do?cid=123

https://mlm01.example.test/rhn/channels/ChannelPackages.do?cid=123

Content Staging: gleiche Paketstände über Dev, UAT und Produktion

Der wichtigste Produktivnutzen von SUSE Multi-Linux Manager ist nicht, möglichst schnell überall die neuesten Pakete zu installieren. Entscheidend ist, dass du definierte Paketstände kontrolliert von Entwicklung über UAT bis Produktion führst und nachweisen kannst, welcher Stand wo freigegeben ist.

1. DEV erhält neue Paketstände zuerst, damit technische Kompatibilität, Service-Start, Migrationen und Rollback getestet werden.
2. UAT erhält nur den Paketstand, der in DEV technisch bestanden hat und fachlich abgenommen werden soll.
3. PROD erhält erst den exakt freigegebenen Stand aus UAT, nicht automatisch den neuesten Stand des Upstream-Repositories.
4. Activation Keys und Systemgruppen sorgen dafür, dass neue Systeme direkt in die richtige Stage und den passenden Channel fallen.
5. Reports, CVE-Audit und Scheduled Actions belegen, welcher Stand ausgerollt wurde und wo noch Abweichungen bestehen.

Für grommunio heißt das praktisch: Community- oder Subscription-Content wird zuerst in einen getesteten Channel synchronisiert, dann für DEV freigegeben, anschließend nach UAT promoviert und erst nach Abnahme für PROD verwendet. Damit kannst du neue grommunio-Pakete prüfen, ohne dass UAT oder Produktion unbeabsichtigt denselben neuen Stand bekommen.

SUSE-Serie: Teil 5