SUSE Multi-Linux Manager 5.2: Reporting, Inventar und Subscription Audit aufbauen

Ziel dieser Anleitung

Dieser Teil zeigt, wie aus verwalteten Systemen belastbare Informationen werden: Inventar, Systemgruppen, Patchstatus, CVE-Audit, Subscription Matching, OpenSCAP-Ergebnisse, Proxy-Übersichten, Reports und wiederkehrende Auswertungen. Genau hier wird SUSE Multi-Linux Manager vom Installationsprojekt zur Betriebsplattform.

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

Was Reporting im Betrieb leistet

Reports beantworten wiederkehrende Fragen: Welche Systeme existieren? Welche Distributionen und Versionen laufen? Welche Systeme sind inaktiv? Welche Patches fehlen? Welche Clients hängen an welchen Channels? Welche OpenSCAP-Scans gibt es? Welche Systeme gehören zu welchem Standort oder welcher Gruppe?

https://mlm01.lab.example

Reports pro System lesen

Für einzelne Systeme sind die Detailseiten wichtiger als ein globaler Export. Dort prüfst du letzter Check-in, Salt-Status, Betriebssystem, Kernel, Base Channel, installierte Pakete, verfügbare Updates, Events, Historie, OpenSCAP-Ergebnisse und Custom Info.

Ein professioneller Systemcheck folgt einem festen Muster: Erreichbarkeit und letzter Check-in, Betriebssystem und Kernel, Channel-Zuordnung, verfügbare Updates, kritische Sicherheitsupdates, Event-Historie und Compliance-Ergebnisse. So kann ein Administrator erklären, warum ein System patchbar ist oder warum es zuerst vorbereitet werden muss.

Systemgruppen als Betriebsmodell

Systemgruppen machen aus einer Serverliste einen steuerbaren Betrieb. Trenne mindestens nach Umgebung, Standort, Verantwortungsbereich und Betriebssystemfamilie. Für Patchfenster, OpenSCAP-Scans und Reports sind Gruppen oft wichtiger als einzelne Hostlisten.

groups:
  - production-sles
  - production-debian
  - production-ubuntu
  - production-rhel-compatible
  - branch-vienna
  - security-audit-scope
  - patch-window-weekly
  - patch-window-monthly

CLI-Reports mit spacewalk-report

spacewalk-report liefert exportierbare Reports für wiederkehrende Auswertungen. In der validierten SUSE-Multi-Linux-Manager-5.2-Umgebung waren unter anderem diese Reports verfügbar:

available_reports:
  - actions
  - channels
  - inventory
  - inactive-systems
  - packages-updates-all
  - packages-updates-newest
  - proxies-overview
  - scap-scan
  - scap-scan-results
  - system-groups
  - system-groups-systems
  - system-hardware
  - system-history
  - system-history-channels
  - system-history-configuration
  - system-history-entitlements
  - system-history-errata
  - system-history-packages
  - system-history-scap
  - users
  - users-systems

Inventar, Hardware und Systemhistorie

Inventory- und Hardware-Reports eignen sich für Bestandsaufnahmen, Betriebssystemübersichten und Servicegespräche. Die Historie zeigt, welche Channels, Pakete, Errata, Konfigurationen und OpenSCAP-Ergebnisse mit einem System verbunden waren.

spacewalk-report inventory > inventory.csv
spacewalk-report system-hardware > system-hardware.csv
spacewalk-report system-history > system-history.csv
spacewalk-report system-groups-systems > system-groups-systems.csv

Patch- und Update-Reports

Patchreports zeigen, wo Handlungsbedarf besteht. Für den Betrieb ist wichtig, zwischen vorhandenen Updates, neuesten Updates, Security-relevanten Errata und bereits geplanten Aktionen zu unterscheiden.

https://mlm01.lab.example

spacewalk-report packages-updates-all > packages-updates-all.csv
spacewalk-report packages-updates-newest > packages-updates-newest.csv
spacewalk-report errata-systems > errata-systems.csv
spacewalk-report system-history-packages > system-history-packages.csv

OpenSCAP- und Audit-Reports

OpenSCAP-Reports sind für Security und Compliance zentral. Sie zeigen, welche Scans gelaufen sind, welche Regeln fehlschlagen, welche Systeme betroffen sind und wie sich Ergebnisse über Zeit verändern.

spacewalk-report scap-scan > scap-scan.csv
spacewalk-report scap-scan-results > scap-scan-results.csv
spacewalk-report system-history-scap > system-history-scap.csv

Subscription-, Channel- und Proxy-Audit

Für Lizenz- und Subscription-Prüfungen sind Channel- und Entitlement-Reports relevant. Wenn Proxies eingesetzt werden, gehört proxies-overview in das Regelreporting, damit Standortpfade, Cache-Architektur und Client-Zuordnung sichtbar bleiben.

spacewalk-report channels > channels.csv
spacewalk-report system-history-channels > system-history-channels.csv
spacewalk-report system-history-entitlements > system-history-entitlements.csv
spacewalk-report proxies-overview > proxies-overview.csv
spacewalk-report inactive-systems > inactive-systems.csv

Automatisierte Reportablage

Für wiederkehrende Auswertungen sollte die Report-Erstellung automatisiert werden. Die Dateien gehören in ein internes, zugriffsgeschütztes Verzeichnis oder in ein Reporting-System. Kundendaten, Hostnamen und interne IP-Adressen gehören nicht ungeprüft in externe Tickets oder öffentliche Dokumentation.

install -d -m 0750 /srv/mlm-reports
stamp=$(date +%F)
spacewalk-report inventory > /srv/mlm-reports/inventory-$stamp.csv
spacewalk-report packages-updates-newest > /srv/mlm-reports/packages-updates-newest-$stamp.csv
spacewalk-report scap-scan-results > /srv/mlm-reports/scap-scan-results-$stamp.csv

Abnahmetest

Reporting ist fertig, wenn Systemdetailseiten, Systemgruppen, Patchreports, OpenSCAP-Reports, Proxy-Reports und Inventare dieselbe Realität zeigen. Ein System, das im Patchreport auftaucht, muss in der Systemliste, in der Gruppe und in der Historie nachvollziehbar sein.

Empfängerorientierte Reports

Nicht jeder Report ist für jede Zielgruppe gleich wertvoll. Betrieb braucht Patchstatus, letzte Kontakte, fehlgeschlagene Aktionen und inaktive Systeme. Security braucht CVEs, OpenSCAP-Ergebnisse und Audit-Historie. Einkauf und Lizenzmanagement brauchen Channel- und Entitlement-Sichten. Management braucht Trends, Risiken und klare Ampeln statt Rohdaten.

Genau deshalb erzeugst du nicht einen großen Export für alle, sondern wiederholbare Reportpakete. Ein monatliches Betriebsreporting kann andere Spalten und andere Detailtiefe haben als ein Security-Audit oder ein Lizenzreview.

Reports pro Distribution vergleichen

Der besondere Wert von Multi-Linux Manager liegt darin, unterschiedliche Linux-Familien in einer gemeinsamen Sicht zu führen. SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux und Oracle Linux haben verschiedene Paketmodelle und Lifecycle-Regeln. Das Reporting muss diese Unterschiede sichtbar machen, ohne sie künstlich gleichzurechnen.

report_view:
  sles: zypper, SUSE lifecycle, SCC channels
  sl_micro: immutable host focus, container operations
  debian: apt model, Debian security lifecycle
  ubuntu: apt model, LTS lifecycle
  rocky_alma_oracle: dnf/yum model, RHEL-compatible lifecycle

Abweichungen erkennen

Ein gutes Reporting zeigt nicht nur, dass Systeme vorhanden sind. Es zeigt Abweichungen: Hosts ohne aktuellen Check-in, Systeme ohne erwartete Gruppe, Clients ohne passenden Base Channel, Patchstände außerhalb des Wartungsfensters, fehlende OpenSCAP-Scans oder Systeme, deren Distribution nicht zum vorgesehenen Betriebsmodell passt.

Vom Report zur Aktion

Reports werden erst wertvoll, wenn daraus Entscheidungen entstehen. Ein Patchreport führt zu Wartungsfenstern. Ein OpenSCAP-Report führt zu Remediation oder Ausnahmegenehmigung. Ein Inventory-Report führt zu Bereinigung, Subscription-Klärung oder Decommissioning. Ein Proxy-Report führt zu Standortanalyse oder Cache-Dimensionierung.

Qualitätssicherung der Reports

Mindestens einmal pro Zyklus vergleichst du UI, CLI-Export und Stichprobe am Client. Wenn ein System laut Report aktuell ist, sollte der Client diesen Zustand bestätigen. Wenn ein Client lange nicht eingecheckt hat, darf er nicht stillschweigend aus dem Reporting verschwinden.

salt 'sles16-client01.lab.example' test.ping
salt 'debian13-client01.lab.example' grains.item os osrelease fqdn
spacewalk-report inactive-systems
spacewalk-report packages-updates-newest

Regelmäßige Reportpakete

Ein professionelles Reportpaket besteht aus mehreren Dateien und einer kurzen Bewertung. Die Rohdaten zeigen Systeme, Patches und Scans. Die Bewertung erklärt, was daraus folgt: welche Systeme im nächsten Wartungsfenster gepatcht werden, welche Ausnahmen offen sind, welche Clients nicht einchecken und welche Systeme aus dem Lifecycle fallen.

Für wöchentliche Betriebsrunden reichen oft Patchstatus, inaktive Systeme und fehlgeschlagene Aktionen. Für monatliche Security-Runden kommen OpenSCAP, CVE-/Errata-Sicht und Systemhistorie dazu. Für Quartalsreviews sind Inventory, Entitlements, Channel-Nutzung und Proxy-Struktur wichtig.

Reports mit Systemdetailseiten verbinden

CSV-Reports sind stark, aber sie ersetzen nicht die Detailseite im Manager. Wenn ein Report ein Problem zeigt, springst du zum System und prüfst dort Historie, Events, Software, Channel, Errata und OpenSCAP-Ergebnis. Dadurch wird aus einem Export eine nachvollziehbare Betriebsentscheidung.

Mixed-Linux-Bewertung

Bei gemischten Linux-Umgebungen darf Reporting nicht so tun, als wären alle Distributionen gleich. SLES und SL Micro hängen enger an SCC und SUSE Lifecycle. Debian und Ubuntu folgen ihrem apt- und LTS-Modell. Rocky, AlmaLinux und Oracle Linux folgen einem RHEL-kompatiblen Modell, aber mit eigenen Release- und Supportrealitäten.

Ein guter Report nennt deshalb nicht nur den Patchstatus, sondern auch die Plattformfamilie. So kann ein Kunde erkennen, wo SUSE-Support, Community-Lifecycle, Hersteller-Support oder internes Betriebsmodell relevant sind.

Auditierbarkeit für Kundenprojekte

Für Kundenprojekte ist Reporting ein Vertrauensbaustein. Es zeigt nicht nur, dass ForgeOne Systeme technisch verwalten kann. Es zeigt, dass Patchstände, Compliance, Lifecycle und Zuständigkeiten erklärbar sind. Genau das ist bei regulierten oder kritischen Umgebungen oft wichtiger als ein einzelner schneller Patchlauf.

Reports, Schedules und wiederkehrende Nachweise

Für Management und Audit reicht eine einmalige Web-UI-Prüfung nicht. Definiere wiederkehrende Reports und lege fest, wann sie erzeugt, geprüft und abgelegt werden.

• Wöchentlich: Patchstatus je Systemgruppe und überfällige Updates.
• Monatlich: Inventory, Hardware-/Softwareänderungen und Channel-Zuordnung.
• Nach Wartungsfenstern: erfolgreiche, fehlgeschlagene und offene Aktionen auswerten.
• Quartalsweise: CVE-, OpenSCAP-, Subscription- und Lifecycle-Review vorbereiten.

spacewalk-report system-groups\nspacewalk-report system-history\nspacewalk-report errata-systems\nspacewalk-report scap-scan

In größeren Umgebungen werden diese Exporte nicht manuell zusammengesucht, sondern in ein internes Reporting- oder Ticketing-Verfahren überführt. Wichtig ist die Nachvollziehbarkeit: Welche Gruppe war im Wartungsfenster, welche Aktion wurde geplant, was ist abgeschlossen und was bleibt offen?