SUSE Multi-Linux Manager 5.2: reporting, inventory and subscription audit

Goal of this guide

This part turns managed systems into evidence: inventory, system groups, patch state, CVE audit, subscription matching, OpenSCAP results, proxy overview, reports and recurring exports. This is where SUSE Multi-Linux Manager becomes an operations platform.

Complete series path

This series guides you step by step through production deployment: 1. Install SLES 16 for production · 2. Install SUSE Multi-Linux Manager 5.2 · 3. Onboard first Linux clients · 4. Patch and lifecycle management · 5. Manage mixed Linux · 6. OpenSCAP, compliance and audit · 7. Build proxies for sites · 8. Integrate SSO with Keycloak · 9. Use Ansible next to Salt · 10. Reporting, inventory and audit · 11. Operate and harden in production

What reporting delivers

Reports answer recurring questions: which systems exist, which distributions and versions run, which hosts are inactive, which patches are missing, which clients use which channels, which OpenSCAP scans exist and which systems belong to which site or group.

https://mlm01.lab.example

Read reports per system

For individual systems, detail pages matter more than global exports. Check last contact, Salt status, operating system, kernel, base channel, installed packages, available updates, events, history, OpenSCAP results and custom information.

A professional system review follows a fixed sequence: reachability and last check-in, operating system and kernel, channel assignment, available updates, critical security updates, event history and compliance results.

System groups as operations model

System groups turn a server list into manageable operations. Separate at least by environment, site, responsibility and operating system family. Groups are often more important than individual host lists for patch windows, OpenSCAP scans and reports.

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

CLI reports with spacewalk-report

spacewalk-report provides exportable reports for recurring reviews. The validated SUSE Multi-Linux Manager 5.2 environment exposed these reports among others:

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

Inventory, hardware and system history

Inventory and hardware reports support estate reviews, operating-system overviews and service discussions. History reports show which channels, packages, errata, configurations and OpenSCAP results were associated with a system.

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 and update reports

Patch reports show where action is required. Operations must distinguish available updates, newest updates, security errata and scheduled actions.

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 and audit reports

OpenSCAP reports are central for security and compliance. They show which scans ran, which rules failed, which systems are affected and how findings change over time.

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 and proxy audit

Channel and entitlement reports help compare technical use with commercial assignment. When proxies are used, proxies-overview belongs into recurring reporting so site paths, cache architecture and client assignment remain visible.

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

Automated report storage

Recurring exports should be automated and stored in a protected internal location or reporting system. Customer data, hostnames and internal IP addresses must not be copied into external tickets or public documentation without review.

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

Acceptance test

Reporting is complete when system detail pages, system groups, patch reports, OpenSCAP reports, proxy reports and inventories describe the same reality.

Audience-oriented reports

Not every report is equally useful for every audience. Operations needs patch state, last contact, failed actions and inactive systems. Security needs CVEs, OpenSCAP results and audit history. Purchasing and license management need channel and entitlement views. Management needs trends, risks and clear status instead of raw data.

Therefore, do not create one large export for everyone. Build repeatable report packages. Monthly operations reporting can have different columns and detail levels than a security audit or licensing review.

Compare reports by distribution

The value of Multi-Linux Manager is managing different Linux families in one view. SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux and Oracle Linux have different package models and lifecycle rules. Reporting must show these differences without pretending they are identical.

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

Detect deviations

Good reporting shows more than existing systems. It shows deviations: hosts without recent check-in, systems missing expected groups, clients without proper base channel, patch state outside maintenance windows, missing OpenSCAP scans or distributions that do not match the intended operating model.

From report to action

Reports become valuable when they lead to decisions. A patch report leads to maintenance windows. An OpenSCAP report leads to remediation or exception approval. Inventory leads to cleanup, subscription clarification or decommissioning. Proxy reports lead to site analysis or cache sizing.

Report quality assurance

At least once per cycle, compare UI, CLI export and a client-side sample. If a report says a system is current, the client should confirm that state. If a client has not checked in for a long time, it must not silently disappear from reporting.

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

Recurring report packages

A professional report package consists of several files and a short assessment. Raw data shows systems, patches and scans. The assessment explains the consequence: which systems are patched in the next window, which exceptions remain, which clients do not check in and which systems leave lifecycle.

Weekly operations meetings often need patch state, inactive systems and failed actions. Monthly security meetings add OpenSCAP, CVE or errata views and system history. Quarterly reviews focus on inventory, entitlements, channel usage and proxy structure.

Connect reports with system detail pages

CSV reports are powerful, but they do not replace the Manager detail page. When a report shows an issue, open the system and review history, events, software, channels, errata and OpenSCAP results. That turns an export into a traceable operations decision.

Mixed Linux assessment

In mixed Linux environments, reporting must not pretend that all distributions are identical. SLES and SL Micro are tightly connected to SCC and SUSE lifecycle. Debian and Ubuntu follow apt and LTS models. Rocky, AlmaLinux and Oracle Linux follow a RHEL-compatible model, but with their own release and support realities.

Good reporting therefore shows not only patch state, but also platform family. Customers can then see where SUSE support, community lifecycle, vendor support or internal operations models matter.

Auditability for customer projects

For customer projects, reporting builds trust. It shows not only that ForgeOne can manage systems technically. It shows that patch state, compliance, lifecycle and responsibilities can be explained. In regulated or critical environments, that is often more important than a single quick patch run.

Reports, schedules and recurring evidence

For management and audits, one manual Web UI check is not enough. Define recurring reports and specify when they are generated, reviewed and archived.

• Weekly: patch status per system group and overdue updates.
• Monthly: inventory, hardware/software changes and channel assignment.
• After maintenance windows: successful, failed and pending actions.
• Quarterly: CVE, OpenSCAP, subscription and lifecycle review.

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

In larger environments, these exports should feed an internal reporting or ticketing workflow. What matters is traceability: which group was in the maintenance window, which action was scheduled, what completed and what remains open?