# SUSE Multi-Linux Manager 5.2: Mixed Linux produktiv verwalten Source: https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten Language: de Published: 2026-09-12 Updated: 2026-10-18 Heterogene Linux-Flotten mit SLES, SL Micro, Debian, Ubuntu, Rocky, Alma und Oracle Linux kontrolliert betreiben. ## 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. | Plattform | Produktiver Fokus | Wichtige Unterschiede | | --- | --- | --- | | SLES 16 | Geschäftskritische Enterprise-Server | SUSE-Support, SCC, zypper, SLES-Lifecycle | | SL Micro 6.2 | Containerhost, Appliance, Edge und immutable Betrieb | transactional-update, Reboot- und Rollback-Modell | | Debian 13 | Community-Server und standardisierte Debian-Flotten | apt, Debian-Supportmodell, andere Advisory-Logik | | Ubuntu 24.04 LTS | LTS-Server, Cloud-Workloads und verbreitete Applikationsplattformen | apt, Ubuntu-LTS-Lifecycle, Ubuntu-spezifische Pakete | | Rocky Linux | RHEL-kompatible Community-Plattform | dnf, EL-Lifecycle, AppStream-/Moduldetails | | AlmaLinux | RHEL-kompatible Community- und Enterprise-Alternative | dnf, EL-Kompatibilität, eigene Signaturen und Repositories | | Oracle Linux | Enterprise-Linux mit Oracle-Ökosystem | dnf, UEK/RHCK-Entscheidungen, Oracle-Supportmodell | ## 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 [![Systemliste mit registriertem SLES-16-Client.](https://forgeone.solutions/media/suse-mlm-client-onboarding-05-system-list.png)](https://forgeone.solutions/media/suse-mlm-client-onboarding-05-system-list.png) ## 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. [![SUSE Multi-Linux Manager 5.2 Systemliste mit mehreren Distributionen.](https://forgeone.solutions/media/04-system-list-all.png)](https://forgeone.solutions/media/04-system-list-all.png) [![Systemgruppen in SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/09-system-groups.png)](https://forgeone.solutions/media/09-system-groups.png) | Distribution | Getestete Version | Status | Betriebsrelevanter Punkt | | --- | --- | --- | --- | | SLES | 16.0 | geprüft | stärkste Integration mit SUSE-Support, SCC, zypper und SLES-Lifecycle | | Debian | 13 | geprüft | apt-Modell, eigenes Security- und Release-Verständnis | | Ubuntu | 24.04 LTS | geprüft | apt, LTS-Lifecycle und sudo/root-Bootstrap beachten | | Rocky Linux | 10.2 | geprüft | RHEL-kompatibel, dnf, Product-Catalog-Label prüfen | | AlmaLinux | 10.2 | geprüft | RHEL-kompatibel, eigene Signaturen und Channels | | Oracle Linux | 10.1 | geprüft WITH LIMITATION | Content und Key möglich, Bootstrap-Codebase im Test nicht final verfügbar | | SL Micro | 6.2 | CONTENT READY | separater Client braucht eigenes Medium; transactional-update und Reboot-Modell getrennt planen | ## 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. [![Product Catalog im SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png)](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png) ## 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. [![SUSE Multi-Linux Manager 5.2 Systemliste mit mehreren Distributionen.](https://forgeone.solutions/media/04-system-list-all.png)](https://forgeone.solutions/media/04-system-list-all.png) 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. [![SUSE Multi-Linux Manager 5.2 mit verwalteten SLES-, Debian-, Ubuntu-, Rocky- und AlmaLinux-Systemen.](https://forgeone.solutions/media/01-all-systems-multidistro-1.png)](https://forgeone.solutions/media/01-all-systems-multidistro-1.png) [![Activation-Key-Liste im SUSE Multi-Linux Manager mit produktionsorientierten Lab-Schlüsseln.](https://forgeone.solutions/media/15-activation-keys-list.png)](https://forgeone.solutions/media/15-activation-keys-list.png) [![Bootstrapping-Formular im SUSE Multi-Linux Manager mit Activation-Key-Auswahl.](https://forgeone.solutions/media/17-bootstrap-form-activation-keys.png)](https://forgeone.solutions/media/17-bootstrap-form-activation-keys.png) [![Systemgruppe production-linux mit mehreren verwalteten Linux-Clients.](https://forgeone.solutions/media/19-system-group-production-detail.png)](https://forgeone.solutions/media/19-system-group-production-detail.png) - 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. [![Software-Channel-Liste mit SLES, SL Micro, Debian, Ubuntu, Rocky, Alma, Oracle Linux und grommunio-Community-Content.](https://forgeone.solutions/media/02-all-software-channels-with-grommunio-1.png)](https://forgeone.solutions/media/02-all-software-channels-with-grommunio-1.png) ## 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. [![Custom Repositories für grommunio Community unter openSUSE Leap, Debian und Ubuntu.](https://forgeone.solutions/media/03-custom-repositories-grommunio.png)](https://forgeone.solutions/media/03-custom-repositories-grommunio.png) [![Repository-Detail des grommunio-Community-Debian-13-Repositories.](https://forgeone.solutions/media/32-grommunio-debian-repo-detail.png)](https://forgeone.solutions/media/32-grommunio-debian-repo-detail.png) [![Repository-Detail des grommunio-Community-Ubuntu-24.04-Repositories.](https://forgeone.solutions/media/33-grommunio-ubuntu-repo-detail.png)](https://forgeone.solutions/media/33-grommunio-ubuntu-repo-detail.png) [![grommunio Community openSUSE Leap 16.0 Channel mit synchronisierten Paketen.](https://forgeone.solutions/media/10-grommunio-opensuse-channel-detail.png)](https://forgeone.solutions/media/10-grommunio-opensuse-channel-detail.png) [![Paketliste des grommunio-Community-openSUSE-Channels mit echten grommunio-Paketen.](https://forgeone.solutions/media/28-grommunio-opensuse-package-list.png)](https://forgeone.solutions/media/28-grommunio-opensuse-package-list.png) [![grommunio Community Debian 13 Channel mit synchronisierten Paketen.](https://forgeone.solutions/media/11-grommunio-debian-channel-detail.png)](https://forgeone.solutions/media/11-grommunio-debian-channel-detail.png) [![Paketliste des grommunio-Community-Debian-Channels mit echten grommunio-Paketen.](https://forgeone.solutions/media/29-grommunio-debian-package-list.png)](https://forgeone.solutions/media/29-grommunio-debian-package-list.png) [![grommunio Community Ubuntu 24.04 Channel mit synchronisierten Paketen.](https://forgeone.solutions/media/12-grommunio-ubuntu-channel-detail.png)](https://forgeone.solutions/media/12-grommunio-ubuntu-channel-detail.png) [![Paketliste des grommunio-Community-Ubuntu-Channels mit echten grommunio-Paketen.](https://forgeone.solutions/media/30-grommunio-ubuntu-package-list.png)](https://forgeone.solutions/media/30-grommunio-ubuntu-package-list.png) ## 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 [![Product Catalog im SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png)](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png) ## Quellen - SUSE Multi-Linux Manager 5.2 Dokumentation - SUSE Multi-Linux Manager 5.2 Client-Konfiguration und unterstützte Features - SUSE Multi-Linux Manager 5.2 Release Notes ## Titelbild [![Product Catalog im SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png)](https://forgeone.solutions/media/suse-mlm-client-onboarding-01-product-catalog.png) ## Autor Mathias Rumbold ## Kategorie - [Enterprise Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?category=enterprise-linux) - [Linux Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?category=linux-lifecycle-management) ## Tags - [SUSE](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=suse) - [SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=suse-multi-linux-manager) - [Mixed Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=mixed-linux) - [Enterprise Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=enterprise-linux) - [Linux Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=linux-management) - [Patch Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten?tags=patch-management) ## SUSE Enterprise Linux & Multi-Linux Manager Schritt für Schritt Die Serie verbindet SLES 16 Grundlagen mit dem produktiven Aufbau von SUSE Multi-Linux Manager 5.2. Bestehende URLs bleiben unverändert. 1. [SLES 16 produktiv installieren: vom ISO zum verwaltbaren Linux-Server](https://forgeone.solutions/de/tech/sles-16-installieren) 2. [SLES 16 und Enterprise Linux: Wie unterschiedlich ist der Admin-Alltag noch?](https://forgeone.solutions/de/tech/sles-16-enterprise-linux-rhel-rocky-almalinux-vergleich) 3. [SLES 16 härten und prüfen: OpenSCAP, CIS-Einordnung und SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/sles-16-hardening-openscap-cis-mlm) 4. [SUSE Multi-Linux Manager 5.2 produktiv installieren: SL Micro, Storage und erster Channel-Sync](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sl-micro-installieren) 5. [SUSE Multi-Linux Manager 5.2: erste Linux-Clients produktiv onboarden](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-clients-onboarden) 6. [SUSE Multi-Linux Manager 5.2: Patch- und Lifecycle-Management produktiv aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management) 7. [SUSE Multi-Linux Manager 5.2: Mixed Linux produktiv verwalten (aktueller Teil)](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-mixed-linux-verwalten) 8. [SUSE Multi-Linux Manager 5.2: OpenSCAP, Compliance und Audit produktiv nutzen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-openscap-compliance-audit) 9. [SUSE Multi-Linux Manager 5.2: Proxies für Standorte und verteilte Linux-Flotten aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-proxy-standorte-aufbauen) 10. [SUSE Multi-Linux Manager 5.2: SSO mit Keycloak, SAML und MFA integrieren](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-sso-keycloak-saml-mfa) 11. [SUSE Multi-Linux Manager 5.2: Ansible neben Salt produktiv nutzen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-ansible-neben-salt) 12. [SUSE Multi-Linux Manager 5.2: Reporting, Inventar und Subscription Audit aufbauen](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-reporting-inventory-subscription-audit) 13. [SUSE Multi-Linux Manager 5.2 produktiv betreiben und härten](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-produktiv-betreiben-haerten)