Ziel dieser Anleitung
Dieser Abschlussbeitrag behandelt den Manager selbst als kritische Plattform. Nach Installation, Onboarding, Patchprozessen, Mixed Linux, OpenSCAP und Reporting geht es um den dauerhaften Betrieb: Backup, Restore, TLS, Rollen, Monitoring, Storage, Sync-Fenster und saubere Übergabe an den Regelbetrieb.
Backup und Restore planen
Ein Backup ist erst dann belastbar, wenn ein Restore geübt wurde. Sichere Datenbank, Konfiguration, Zertifikate, Repository-Content, Bootstrap-Artefakte und Betriebsdokumentation. Entscheide bewusst, ob Repository-Content vollständig gesichert oder aus synchronisierten Quellen wiederhergestellt wird.
mgradm backup --helpmgradm backup create --helpmgradm backup db --helpmgradm backup restore --help
TLS und Zertifikate
Produktiv sollte der Manager unter einem stabilen FQDN mit sauberem Zertifikatskonzept laufen. Clients, Admins und Automatisierung müssen dem Zertifikat vertrauen. Plane Erneuerung, CA-Wechsel und Dokumentation, bevor die ersten hundert Clients angebunden sind.
mgradm install mlm01.example.test \ --ssl-ca-root /root/pki/ca.crt \ --ssl-server-cert /root/pki/mlm01.example.test.crt \ --ssl-server-key /root/pki/mlm01.example.test.key
Admin-Rollen und Zugriff
Nutze persönliche Admin-Konten, ein klares Rollenmodell und eingeschränkte Netzfreigaben. Ein geteilter Admin-Login ist für den Aufbau bequem, im Dauerbetrieb aber schlecht auditierbar. Lege fest, wer Channels synchronisieren, Aktionen planen, Audits sehen und Systeme löschen darf.
Monitoring und Health Checks
Überwache nicht nur den Host. Entscheidend sind Containerzustand, Podman, Storage-Füllstand, Datenbank, Channel-Sync, Pending und Failed Actions, Salt-Kommunikation und letzte Client-Check-ins. Für größere Umgebungen kommen Kapazitätsplanung und Tuning dazu.
systemctl --failedpodman ps --format "table {{.Names}}\t{{.Status}}"mgradm statusdf -h /var/lib/containers/storage/volumesjournalctl -u podman --since "1 hour ago"
Storage-Wachstum und Sync-Fenster
SUSE dokumentiert erheblichen Speicherbedarf pro Produktfamilie. Deshalb synchronisierst du nicht wahllos alle Distributionen, Architekturen und Versionen. Definiere Zielplattformen, Aufbewahrung, Sync-Fenster und Eskalation bei Fehlern.
Content Lifecycle und Wartungsfenster
Produktive Systeme sollten nicht direkt aus Roh-Channels aktualisiert werden. Verwende Content Lifecycle Management, Testgruppen und Promotions, damit Patches erst nach fachlicher Freigabe in Produktion landen.
Produktionscheckliste
- Backup- und Restore-Ablauf ist getestet.
- TLS und FQDN sind stabil dokumentiert.
- Admin-Rollen sind persönlich und nachvollziehbar.
- Monitoring umfasst Host, Container, Storage, Sync, Aktionen und Clients.
- Storage-Wachstum ist budgetiert und alarmiert.
- Content Lifecycle trennt Test und Produktion.
- Betriebsdokumentation enthält Notfallkontakte, Wiederanlauf und Verantwortlichkeiten.
Betriebsübergabe statt Projektende
Nach dem erfolgreichen Aufbau darf SUSE Multi-Linux Manager nicht als fertige Installation liegen bleiben. Der entscheidende Schritt ist die Übergabe in den Regelbetrieb. Dazu gehören Runbooks, Monitoring, Backup, Restore-Probe, Rollen, Wartungsfenster, Patchkalender, Eskalationswege und eine klare Definition, welche Systeme über den Manager verwaltet werden.
Besonders bei Managed Services ist diese Phase kaufmännisch und technisch wichtig. Kunden kaufen nicht nur eine Weboberfläche, sondern einen stabilen Prozess für Linux Lifecycle, Security Updates, Compliance, Reporting und Nachvollziehbarkeit.
- Runbook für Normalbetrieb und Störung.
- Backup- und Restore-Test mit dokumentiertem Ergebnis.
- Monitoring für Host, Container, Storage, Sync und Clients.
- Rollenmodell für Admins und Auditoren.
- Review-Termin nach dem ersten Patchzyklus.
Notfall- und Restore-Szenarien
Plane mindestens drei Szenarien: Datenbank defekt, Repository-Storage voll oder verloren, Manager-Host nicht mehr startbar. Für jedes Szenario brauchst du Entscheidungspunkte: Restore aus Backup, Neuaufbau mit erneutem Sync, Zertifikatswiederherstellung, Client-Reaktivierung und Kommunikationsplan.
# Betriebscheck vor und nach Wartungmgradm statuspodman ps --format "table {{.Names}}\t{{.Status}}"df -h /var/lib/containers/storage/volumesspacewalk-report inactive-systems | headspacewalk-report actions | head
Security-Härtung des Managers
Der Manager hat Zugriff auf viele Systeme und darf nicht wie ein beliebiger Admin-Webserver behandelt werden. Beschränke Admin-Zugriff auf definierte Netze, nutze persönliche Konten, prüfe Zertifikate, rotiere Zugangsdaten und halte Betriebssystem sowie Manager-Container aktuell. API- und CLI-Zugriffe gehören in denselben Audit-Kontext wie die Weboberfläche.
Wenn externe Dienstleister oder Kunden Zugriff bekommen, müssen Rollen und Mandantenfähigkeit sauber geprüft werden. Nicht jeder Benutzer darf Channels verändern, Remote Commands starten oder Systeme löschen. Ein Review der Rollen ist Pflicht, bevor der Manager produktive Kundensysteme verwaltet.
Monitoring konkret machen
Gutes Monitoring zeigt nicht nur, dass der Host pingbar ist. Es muss sichtbar werden, ob Synchronisationen hängen, Actions fehlschlagen, Clients nicht mehr einchecken, Repository-Storage wächst oder Container nicht gesund sind. Dazu kommen klassische Hostmetriken wie CPU, RAM, Load, I/O und Filesystem-Füllstand.
# Beispiele für tägliche Kontrollensystemctl --failedjournalctl --since "24 hours ago" -p warning..alertpodman ps --filter health=unhealthydu -sh /var/lib/containers/storage/volumes/* | sort -h | tail
Skalierung und Proxies
Bei mehreren Standorten, vielen Clients oder schmalen Leitungen solltest du früh über SUSE Multi-Linux Manager Proxy, Sync-Fenster und Netzwerkwege nachdenken. Proxies reduzieren Last, verbessern lokale Verteilung und helfen, zentrale Manager-Systeme zu entlasten. Sie ersetzen aber nicht die saubere Planung von Channels, Content Lifecycle und Wartungsprozessen.
Betriebsbereiche, die vor dem breiten Rollout fertig sein müssen
Ein installierter Manager ist noch keine produktive Plattform. Vor dem breiten Rollout brauchst du ein klares Betriebsmodell für Backup, Restore, TLS, Admin-Rollen, Monitoring, Storage, Channel-Sync, Content Lifecycle, Proxy-Standorte und Notfallzugriff.
Backup und Restore
- Backup-Ziel außerhalb des Manager-Hosts.
- Regelmäßiger Restore-Test mit dokumentierter Dauer.
- Zertifikate und CA-Material kontrolliert sichern.
- Repository-Content wegen Größe bewusst behandeln.
- Vor Upgrades zusätzlichen konsistenten Stand erzeugen.
TLS, Rollen und Admin-Zugriff
Produktiver Betrieb braucht nachvollziehbaren Admin-Zugriff. Nutze individuelle Konten, Rollen nach Verantwortlichkeit und ein sauberes TLS-Modell. Self-signed Zertifikate sind für erste Tests okay, aber für produktive Zugriffe meist nicht der Zielzustand.
Monitoring und Kapazität
Überwache Containerzustand, CPU, RAM, I/O, freien Speicher, Channel-Sync-Dauer, Datenbankgröße, Queues, Aktionen und Client-Check-ins. SUSE weist darauf hin, dass langsamer Storage die Performance spürbar verschlechtern kann.
mgrctl pspodman pssystemctl status podmanjournalctl -u podman --since todaydf -h /var/lib/containers/storage/volumes
Skalierung mit Proxies
Bei verteilten Standorten oder vielen Clients sollte ein Proxy-Konzept geprüft werden. Proxies reduzieren Bandbreite, bringen Content näher an Clients und helfen, Außenstellen sauber anzubinden.
Betriebskalender für Produktion
Ein produktiver Manager braucht einen Betriebskalender. Darin stehen Channel-Sync, Patchfenster, OpenSCAP-Scans, Reportläufe, Backup-Prüfungen, Zertifikatsablauf, Proxy-Kontrollen und Restore-Tests.
- Täglich: Health, Sync-Status, fehlgeschlagene Jobs und kritische Alerts prüfen.
- Wöchentlich: Testgruppe patchen, Reports erzeugen und offene Aktionen bereinigen.
- Monatlich: Produktivgruppen nach Freigabe patchen, OpenSCAP/CVE-Status prüfen und Ausnahmen dokumentieren.
- Quartalsweise: Restore-Test, Rollenreview, Proxy-Check, Speicherwachstum und Zertifikatslaufzeiten prüfen.
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.
- SLES 16 produktiv installieren
- SUSE Multi-Linux Manager 5.2 produktiv installieren
- Erste Linux-Clients produktiv onboarden
- Patch- und Lifecycle-Management produktiv aufbauen
- Mixed Linux produktiv verwalten
- OpenSCAP, Compliance und Audit produktiv nutzen
- Proxies für Standorte und verteilte Linux-Flotten aufbauen
- SSO mit Keycloak, SAML und MFA integrieren
- Ansible neben Salt produktiv nutzen
- Reporting, Inventar und Subscription Audit aufbauen
- Produktiv betreiben und härten - dieser Beitrag
Wartungsfenster, Kalender und echte Scheduled Actions
Im Lab ist ein iCalendar-basierter Maintenance-Kalender angelegt. Die technische Ausführung wird weiterhin über geplante Aktionen sichtbar: Paketlisten-Refresh, Reboots, Patchläufe und Audit-Jobs müssen in Produktion je Systemgruppe geprüft werden.
- Wartungskalender definieren erlaubte Zeitfenster.
- Scheduled Actions zeigen die technische Umsetzung.
- Systemgruppen bestimmen, welche Systeme betroffen sind.
- Reports und Audit-Auswertungen belegen nach dem Fenster das Ergebnis.
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.
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.
- DEV erhält neue Paketstände zuerst, damit technische Kompatibilität, Service-Start, Migrationen und Rollback getestet werden.
- UAT erhält nur den Paketstand, der in DEV technisch bestanden hat und fachlich abgenommen werden soll.
- PROD erhält erst den exakt freigegebenen Stand aus UAT, nicht automatisch den neuesten Stand des Upstream-Repositories.
- Activation Keys und Systemgruppen sorgen dafür, dass neue Systeme direkt in die richtige Stage und den passenden Channel fallen.
- 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 8
- Teil 1 bis 7 liefern Installation, Clients, Patches, Mixed Linux, Audit und Reporting.
- Teil 8 macht daraus ein dauerhaft betreibbares System.
- Der Manager ist nicht nur ein Tool, sondern ein zentraler Kontrollpunkt für viele Linux-Systeme.
Betriebsfalle: Manager und Proxy nicht beiläufig umbenennen
Der FQDN eines SUSE Multi-Linux Manager Systems ist Teil der Betriebsarchitektur. Er steckt in Zertifikaten, Bootstrap-Konfiguration, Salt-Kommunikation, Repository-URLs und teilweise in persistenten Container- oder Servicekonfigurationen. Ein Rename gehört deshalb in ein geplantes Wartungsfenster.
- Vor dem Rename: DNS, Zertifikatsnamen, Manager-URL, Proxy-Parent und Client-Erreichbarkeit dokumentieren.
- Während des Rename: Manager-Konfiguration, Bootstrap-Overrides, Salt-Master-/Minion-Konfiguration und Proxy-Konfiguration konsistent ändern.
- Nach dem Rename: Salt-Ping, pkg.refresh_db, WebUI-Systemliste, Proxy-Status, Channel-Zugriff und Zertifikatskette getrennt prüfen.
- Nicht bewerten als erledigt, nur weil der Minion wieder grün ist. Repository-Metadaten können weiterhin auf den alten Manager-FQDN zeigen.
