# SUSE Multi-Linux Manager 5.2: Patch- und Lifecycle-Management produktiv aufbauen

Source: https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management
Language: de
Published: 2026-09-11
Updated: 2026-10-23

Relevante Patches, Staging, Wartungsfenster und CLM als produktiver Update-Prozess.

## 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.

Ein registrierter Client ist nur der Anfang. Produktiv wird SUSE Multi-Linux Manager dann, wenn Updates nicht zufällig, sondern nachvollziehbar bewertet, getestet, freigegeben und dokumentiert werden. Genau darum geht es in diesem Beitrag.

Wir nutzen den SLES-16-Client aus dem vorherigen Teil und bauen daraus einen ersten Patch- und Lifecycle-Ablauf: relevante Patches erkennen, Kritikalität verstehen, Channels sauber halten, Wartungsfenster planen und Content Lifecycle Management als Staging-Modell einordnen.

Die Stärke liegt nicht nur in SUSE-Systemen. Der gleiche Betriebsansatz kann später auf heterogene Flotten ausgeweitet werden: SLES, SL Micro, Debian, Ubuntu, Rocky Linux, AlmaLinux, Oracle Linux und weitere Enterprise-Linux-Varianten werden nicht zu identischen Systemen, aber sie werden über eine gemeinsame Betriebsoberfläche, einheitliche Sichtbarkeit und nachvollziehbare Prozesse steuerbar.

## Zielbild

Am Ende weißt du, welche Systeme welche Patches benötigen, wie du Paket- und Patchstatus prüfst, wann ein direkter Patchlauf reicht und wann du mit Content Lifecycle Management über Dev, Test und Produktion arbeiten solltest.

Für Entscheider ist genau das der Unterschied: Nicht jede Distribution wird gleich behandelt, aber Patch-Bewertung, Freigabe, Wartungsfenster, Reporting und Verantwortlichkeiten können zentralisiert werden. Das reduziert Betriebsrisiko, Audit-Aufwand und Wildwuchs in gewachsenen Linux-Landschaften.

Patch- und Lifecycle-Management ist mehr als ein Button für Updates. Du brauchst Sichtbarkeit über Relevanz, Risiko, Zielgruppen, Wartungsfenster, Freigaben, Rollout-Reihenfolge und Nachweis. SUSE Multi-Linux Manager liefert dafür eine gemeinsame Oberfläche, aber die Betriebsentscheidung bleibt bei dir.

[![Relevante Patches im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)

## 1. Relevante Patches prüfen

Starte nicht beim einzelnen Paket, sondern bei den relevanten Patches. In der Web-UI findest du sie unter Patches -> Patch List -> Relevant. Dort siehst du Typ, Advisory, Synopsis, betroffene Systeme und Aktualisierungsdatum.

Beginne nicht mit dem Patchlauf, sondern mit der Bewertung. Welche Systeme sind betroffen? Handelt es sich um Security Advisories, Bugfixes oder normale Updates? Welche Services laufen auf den Systemen? Erst diese Einordnung entscheidet, ob du sofort patchst, wartest oder in Stufen ausrollst.

- Security Patches zuerst bewerten.
- Bugfix- und Enhancement-Patches nach Betriebsrelevanz einordnen.
- Betroffene Systeme prüfen.
- Reboot-Hinweise und Service-Impact beachten.
- Nicht direkt auf Produktion klicken, wenn Test- oder Staging-Gruppen vorgesehen sind.

## 2. Systemstatus kontrollieren

Öffne das betroffene System und prüfe Base Channel, Last Check-In, Paketabweichungen und ausstehende Patches. Wenn der Client nicht regelmäßig eincheckt, ist Patch-Management nicht belastbar.

[![Systemliste mit Patch- und Paketindikatoren.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-02-system-list.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-02-system-list.png)

```bash
salt '<client-fqdn>' test.ping --out=txt
salt '<client-fqdn>' cmd.run 'zypper lr'
salt '<client-fqdn>' cmd.run 'zypper list-patches'
```

## 3. Direkter Patchlauf oder Staging?

Für einzelne Testsysteme kannst du Updates direkt planen. Für produktive Serverflotten ist ein Staging-Modell sinnvoller: Quellen synchronisieren, Inhalte filtern, eine Version bauen, nach Test fördern und erst dann Produktionssysteme zuordnen.

Direktes Patchen ist für kleine, unkritische Systeme möglich, aber nicht der Standard für zentrale Plattformen. Produktiver Betrieb braucht mindestens Testgruppe, Pilotgruppe und Rolloutgruppe. Bei kritischen Systemen kommen Change-Freigabe, Backup-Status, Wartungsfenster und Rückfallplan dazu.

## 4. Content Lifecycle Management einordnen

Content Lifecycle Management wählt Software-Channels als Quellen, erlaubt Filter und baut daraus Umgebungen wie Dev, Test und Production. SUSE beschreibt CLM als Weg, Inhalte vor der Installation auf Produktionsclients gründlich zu testen.

Content Lifecycle Management trennt Paketverfügbarkeit von Paketfreigabe. Du kannst synchronisierte Inhalte in Umgebungen wie Test, Staging und Produktion bewegen und damit verhindern, dass jeder neue Sync automatisch auf produktive Server trifft.

- Quelle: Filter
- -> Build: Dev
- -> Test: Produktion
- : Client-Zuordnung

Wichtig: Neu gebaute oder geförderte CLM-Channels werden Clients nicht automatisch zugeordnet. Prüfe nach jedem Build und jeder Promotion die Channel-Zuordnung der Zielsysteme.

## 5. Wartungsfenster planen

Patch-Management ist kein einzelner Button. Definiere, wann Security-Patches beschleunigt werden, wann normale Updates laufen, wer freigibt, welche Systeme zuerst gepatcht werden und wie Reboots koordiniert werden.

- Testsysteme zuerst aktualisieren.
- Produktionsgruppen nach Kritikalität und Abhängigkeiten staffeln.
- Reboot-Patches getrennt planen.
- Vorher Backup- und Restore-Fähigkeit prüfen.
- Nachher Services, Monitoring und Anwendungstests kontrollieren.

## 6. Patchlauf kontrolliert ausführen

In einer produktiven Umgebung dokumentierst du vor dem Patchlauf den Ausgangszustand, planst die Aktion im Manager und prüfst danach Ergebnis, Paketstand und Systemzustand. Der nächste Befehl zeigt das Prinzip für eine technische Vorprüfung, nicht als Ersatz für Change-Freigabe.

```bash
salt '<client-fqdn>' cmd.run 'zypper list-patches'
salt '<client-fqdn>' cmd.run 'systemctl --failed'
salt '<client-fqdn>' cmd.run 'needs-restarting -r || true'
```

Je nach Distribution sind nicht alle Hilfsbefehle identisch verfügbar. In der SUSE-Serie behandeln wir Mixed-Linux-Details separat, damit SLES, SL Micro, Rocky, Alma, Debian und Ubuntu nicht in einem einzigen unscharfen Ablauf vermischt werden.

## 7. Reporting und Nachvollziehbarkeit

Nach dem Patchlauf muss klar sein, was geplant war, was ausgeführt wurde, welche Systeme erfolgreich waren, welche Systeme nacharbeiten brauchen und ob Reboots offen sind. Nutze Systemlisten, Patchansichten, Schedule-Resultate und Exportfunktionen als Betriebsnachweis.

Nach dem Patchlauf zählt nicht nur, ob Pakete aktualisiert wurden. Wichtig sind offene Advisories, fehlgeschlagene Aktionen, Systeme ohne Check-in, abweichende Channel-Zuordnung und Services, die einen Neustart brauchen. Genau diese Signale machen aus Patchen einen kontrollierten Lifecycle-Prozess.

## Produktionscheck

- Alle Zielsysteme checken regelmäßig ein.
- Channels sind synchronisiert und dokumentiert.
- Activation Keys und Channel-Zuordnungen sind nachvollziehbar.
- Security-Patches werden priorisiert bewertet.
- CLM-Projekte haben klare Umgebungen und Versionen.
- Wartungsfenster und Reboot-Regeln sind definiert.
- Patchläufe werden protokolliert.
- Monitoring, Backup und Rollback-Überlegungen sind vor dem Patchlauf geklärt.

## Nächster Teil: Mixed Linux verwalten

Der nächste Beitrag erweitert den Blick auf unterschiedliche Distributionen: SLES, SL Micro, Rocky, Alma, Debian, Ubuntu und weitere Plattformen. Dort geht es darum, was wirklich einheitlich funktioniert und wo Distributionen eigene Regeln behalten.

## MLM-5.2-Menüpfade für den Patch-Alltag

| Aufgabe | Menüpfad |
| --- | --- |
| Alle Systeme prüfen | Systems -> System List -> All |
| Relevante Patches ansehen | Patches -> Patch List -> Relevant |
| Geplante Aktionen prüfen | Schedule -> Pending Actions |
| Softwarequellen prüfen | Software -> Channel List -> All |
| Gruppen für Wartungsfenster nutzen | Systems -> System Groups |
| Product Catalog öffnen | Admin/Setup -> Products |
| Neue Clients vorbereiten | Systems -> Bootstrapping |

[![Relevante Patches in SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/07-relevant-patches.png)](https://forgeone.solutions/media/07-relevant-patches.png)

[![Geplante Aktionen in SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/08-scheduled-actions.png)](https://forgeone.solutions/media/08-scheduled-actions.png)

- 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
- 4. Patch- und Lifecycle-Management produktiv aufbauen: /de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management - dieser Beitrag.
- 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.

## 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.

## Patch-Management als Prozess

Patch-Management mit SUSE Multi-Linux Manager besteht aus Bewertung, Staging, Ausführung und Nachweis. Die Web-UI hilft beim täglichen Überblick; die eigentliche Qualität entsteht aber durch klare Gruppen, Wartungsfenster und Freigaben.

[![Relevante Patches im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)

- Relevant Patches zeigen echten Handlungsbedarf statt allgemeiner Paketlisten.
- CVE-Audit hilft bei sicherheitsbezogener Priorisierung.
- Content Lifecycle Management trennt Source, Build, Test und Production.
- Scheduled Actions machen Ausführung und Nachvollziehbarkeit sichtbar.
- Reports liefern Audit- und Betriebsnachweise.

## Typischer Ablauf für Produktion

1. Channels synchronisieren und Sync-Fehler prüfen.
2. Relevante Security- und Bugfix-Patches bewerten.
3. Testsysteme oder Testgruppe aktualisieren.
4. Applikations- und Monitoringchecks durchführen.
5. Content Lifecycle Environment fördern oder Produktionsgruppe freigeben.
6. Produktionssysteme im Wartungsfenster aktualisieren.
7. Reboot, Services und Nachweise prüfen.

```bash
salt 'sles16-client01.example.test' test.ping
salt 'sles16-client01.example.test' pkg.list_upgrades
salt 'sles16-client01.example.test' service.status sshd
```

## Wartungsfenster, Kalender und geplante Aktionen

Patch-Management endet nicht bei der Liste relevanter Patches. Für produktive Systeme brauchst du Wartungsfenster, geplante Aktionen und eine klare Rückmeldung, ob die Aktion erfolgreich war.

- Lege technische Gruppen nach Kritikalität und Betriebszeit an, zum Beispiel Test, Staging, Produktion und Sonderfenster.
- Pflege Wartungskalender unter Schedule > Maintenance Windows > Calendars, damit wiederkehrende Zeitfenster nachvollziehbar sind.
- Plane Patchläufe, Reboots und Audit-Scans in diese Fenster und prüfe danach Pending, Failed und Completed Actions.
- Dokumentiere pro Gruppe, wer freigibt, wer ausführt, wann zurückgerollt wird und welche Systeme ausgenommen sind.

[![Geplante Aktionen in SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/08-scheduled-actions.png)](https://forgeone.solutions/media/08-scheduled-actions.png)

SUSE beschreibt Wartungskalender in der offiziellen Dokumentation unter [Maintenance Windows](https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/maintenance-windows.html). Für den Betrieb ist wichtig: Kalender definieren das erlaubte Zeitfenster, Scheduled Actions zeigen die konkrete technische Ausführung.

## Belastbare Belege aus der getesteten Manager-Umgebung

Die folgenden Abschnitte beschreiben nicht nur die Befehle. Sie zeigen reale Zustände aus der getesteten SUSE-Multi-Linux-Manager-5.2-Umgebung: registrierte Clients, Channel-Zuordnung, Paket- und Patchzahlen, geplante Aktionen sowie den Stand der Audit-Funktionen. Zugangsdaten, Registrierungscodes und interne Infrastruktur sind bewusst nicht sichtbar.

1. SLES 16 produktiv installieren
2. SUSE Multi-Linux Manager 5.2 produktiv installieren
3. Erste Linux-Clients produktiv onboarden
4. Patch- und Lifecycle-Management produktiv aufbauen - dieser Beitrag
5. Mixed Linux produktiv verwalten
6. OpenSCAP, Compliance und Audit produktiv nutzen
7. Proxies für Standorte und verteilte Linux-Flotten aufbauen
8. SSO mit Keycloak, SAML und MFA integrieren
9. Ansible neben Salt produktiv nutzen
10. Reporting, Inventar und Subscription Audit aufbauen
11. Produktiv betreiben und härten

[![Relevante Patches im SUSE Multi-Linux Manager mit Security Advisory für SLES 16.](https://forgeone.solutions/media/05-relevant-patches-cve-data.png)](https://forgeone.solutions/media/05-relevant-patches-cve-data.png)

[![Security-Patchliste eines verwalteten SLES-16-Clients.](https://forgeone.solutions/media/42-sles16-security-patches-list.png)](https://forgeone.solutions/media/42-sles16-security-patches-list.png)

[![SLES-16-Security-Advisory mit echten CVE-Referenzen im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/34-sles-advisory-detail-cves.png)](https://forgeone.solutions/media/34-sles-advisory-detail-cves.png)

[![Relevante SLES-16-Security-Advisory im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/09-sles16-relevant-advisory.png)](https://forgeone.solutions/media/09-sles16-relevant-advisory.png)

[![Aktualisierbare Pakete eines verwalteten SLES-16-Clients.](https://forgeone.solutions/media/43-sles16-upgradable-packages.png)](https://forgeone.solutions/media/43-sles16-upgradable-packages.png)

[![Geplante Aktionen im SUSE Multi-Linux Manager mit Paketlisten- und Reboot-Jobs.](https://forgeone.solutions/media/06-scheduled-actions-real-jobs.png)](https://forgeone.solutions/media/06-scheduled-actions-real-jobs.png)

[![Abgeschlossene Aktionen im SUSE Multi-Linux Manager mit erfolgreichen Inventory- und Paketjobs.](https://forgeone.solutions/media/23-completed-actions.png)](https://forgeone.solutions/media/23-completed-actions.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: vom Server zum Patch-Prozess

Dieser Beitrag ist Teil 4 der Serie. Du solltest vorher den Manager installiert und mindestens einen Client erfolgreich onboarded haben.

- 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
- 4. Patch- und Lifecycle-Management - dieser Beitrag.
- 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.

## Quellen

- SUSE Multi-Linux Manager 5.2 Dokumentation: Content Lifecycle Management
- SUSE Multi-Linux Manager 5.2 Dokumentation: Content Lifecycle Management Workflow
- SUSE Multi-Linux Manager 5.2 Dokumentation: Content Lifecycle Management Beispiele
- SUSE Multi-Linux Manager 5.2 Release Notes

## Titelbild

[![Relevante Patches im SUSE Multi-Linux Manager.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-01-relevant-patches.png)

## Autor

Mathias Rumbold

## Kategorie

- [Enterprise Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?category=enterprise-linux)
- [Linux Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?category=linux-lifecycle-management)

## Tags

- [SUSE](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=suse)
- [SUSE Multi-Linux Manager](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=suse-multi-linux-manager)
- [Patch Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=patch-management)
- [Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=lifecycle-management)
- [Content Lifecycle Management](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=content-lifecycle-management)
- [Enterprise Linux](https://forgeone.solutions/de/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management?tags=enterprise-linux)

## 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 (aktueller Teil)](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](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)

## Weiterführende Inhalte

- [SUSE Multi-Linux Manager](https://forgeone.solutions/de/produkte/suse-multilinux-manager)