Goal of this guide

This final article treats the Manager itself as critical infrastructure. After installation, onboarding, patch processes, mixed Linux, OpenSCAP and reporting, the focus is ongoing operations: backup, restore, TLS, roles, monitoring, storage, sync windows and handover into steady state.

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

SUSE series: part 8

  • Parts 1 to 7 cover installation, clients, patches, mixed Linux, audit and reporting.
  • Part 8 turns this into an operable long-term system.
  • The Manager is not just a tool, but a central control point for many Linux systems.
https://mlm01.example.test

Plan backup and restore

A backup is only reliable when restore has been rehearsed. Protect database, configuration, certificates, repository content, bootstrap artifacts and operations documentation. Decide deliberately whether repository content is backed up fully or restored from synchronized sources.

bash
mgradm backup --help
mgradm backup create --help
mgradm backup db --help
mgradm backup restore --help

TLS and certificates

In production, the Manager should run under a stable FQDN with a proper certificate concept. Clients, administrators and automation must trust the certificate. Plan renewal, CA changes and documentation before onboarding the first hundred clients.

bash
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 roles and access

Use personal admin accounts, a clear role model and restricted network access. A shared admin login is convenient during setup, but poor for audits in steady state. Define who may synchronize channels, schedule actions, view audits and delete systems.

Monitoring and health checks

Do not monitor only the host. Key signals are container state, Podman, storage usage, database health, channel sync, pending and failed actions, Salt communication and client check-ins. Larger environments also need capacity planning and tuning.

bash
systemctl --failed
podman ps --format "table {{.Names}}\t{{.Status}}"
mgradm status
df -h /var/lib/containers/storage/volumes
journalctl -u podman --since "1 hour ago"
https://mlm01.example.test

Storage growth and sync windows

SUSE documents significant storage requirements per product family. Do not blindly synchronize every distribution, architecture and version. Define target platforms, retention, sync windows and escalation for errors.

Content lifecycle and maintenance windows

Production systems should not be updated directly from raw channels. Use Content Lifecycle Management, test groups and promotions so patches reach production only after review.

https://mlm01.example.test

Production checklist

  • Backup and restore are tested.
  • TLS and FQDN are stable and documented.
  • Admin roles are personal and traceable.
  • Monitoring covers host, containers, storage, sync, actions and clients.
  • Storage growth is budgeted and alerted.
  • Content lifecycle separates test and production.
  • Operations documentation includes emergency contacts, recovery and ownership.

Handover to operations, not project closure

After a successful setup, SUSE Multi-Linux Manager must not remain just an installed system. The crucial step is handover into steady state. This includes runbooks, monitoring, backup, restore rehearsal, roles, maintenance windows, patch calendar, escalation paths and a clear definition of which systems are managed through the platform.

This phase is commercially and technically important for managed services. Customers do not buy a web UI; they buy a stable process for Linux lifecycle, security updates, compliance, reporting and traceability.

  • Runbook for normal operation and incidents.
  • Backup and restore test with documented result.
  • Monitoring for host, containers, storage, sync and clients.
  • Role model for administrators and auditors.
  • Review meeting after the first patch cycle.

Emergency and restore scenarios

Plan at least three scenarios: database failure, repository storage full or lost, Manager host no longer booting. For each scenario define decisions: restore from backup, rebuild with fresh sync, certificate recovery, client reactivation and communication plan.

bash
# Operations check before and after maintenance
mgradm status
podman ps --format "table {{.Names}}\t{{.Status}}"
df -h /var/lib/containers/storage/volumes
spacewalk-report inactive-systems | head
spacewalk-report actions | head

Security hardening of the Manager

The Manager has access to many systems and must not be treated like an ordinary admin web server. Restrict admin access to defined networks, use personal accounts, verify certificates, rotate credentials and keep both operating system and Manager containers current. API and CLI access belong in the same audit context as the Web UI.

If external providers or customers get access, roles and tenancy boundaries must be reviewed carefully. Not every user should change channels, run remote commands or delete systems. Role review is mandatory before managing production customer systems.

Make monitoring concrete

Good monitoring does not only show that the host answers ping. It must show stalled syncs, failed actions, missing client check-ins, repository storage growth and unhealthy containers. Add classic host metrics such as CPU, RAM, load, I/O and filesystem usage.

bash
# Examples for daily checks
systemctl --failed
journalctl --since "24 hours ago" -p warning..alert
podman ps --filter health=unhealthy
du -sh /var/lib/containers/storage/volumes/* | sort -h | tail

Scaling and proxies

For multiple sites, many clients or constrained links, think early about SUSE Multi-Linux Manager Proxy, sync windows and network paths. Proxies reduce load, improve local distribution and help offload central Manager systems. They do not replace proper channel, content lifecycle and maintenance planning.

Sources and further documentation

  • SUSE Multi-Linux Manager 5.2 OpenSCAP: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/openscap.html
  • SUSE Multi-Linux Manager 5.2 Auditing: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/auditing.html
  • SUSE Multi-Linux Manager 5.2 Reports: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/reports.html
  • SUSE Multi-Linux Manager 5.2 Backup and Restore: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/backup-restore.html

Operational areas that must be ready before broad rollout

An installed manager is not yet a production platform. Before broad rollout, you need a clear operational model for backup, restore, TLS, admin roles, monitoring, storage, channel sync, content lifecycle, proxy locations and emergency access.

app.example.com

Backup and restore

  • Backup target outside the manager host.
  • Regular restore test with documented duration.
  • Certificates and CA material stored under control.
  • Repository content handled consciously because of size.
  • Additional consistent state before upgrades.

TLS, roles and admin access

Production operation needs traceable admin access. Use individual accounts, responsibility-based roles and a clean TLS model. Self-signed certificates are fine for first tests, but usually not the target state for production access.

Monitoring and capacity

Monitor container state, CPU, RAM, I/O, free storage, channel sync duration, database size, queues, actions and client check-ins. SUSE notes that slow storage can noticeably degrade performance.

bash
mgrctl ps
podman ps
systemctl status podman
journalctl -u podman --since today
df -h /var/lib/containers/storage/volumes

Scaling with proxies

For distributed locations or many clients, evaluate a proxy concept. Proxies reduce bandwidth, bring content closer to clients and help connect branch sites cleanly.

Operations calendar for production

A production manager needs an operations calendar. It should cover channel sync, patch windows, OpenSCAP scans, report runs, backup checks, certificate expiry, proxy checks and restore tests.

  • Daily: check health, sync status, failed jobs and critical alerts.
  • Weekly: patch the test group, generate reports and clean up pending actions.
  • Monthly: patch production groups after approval, review OpenSCAP/CVE status and document exceptions.
  • Quarterly: perform restore test, role review, proxy check, storage growth review and certificate expiry check.
app.example.com

Run SUSE Multi-Linux Manager in production

Do you want to manage SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux or Oracle Linux centrally, validate patches, prove compliance or harden operations? ForgeOne supports licenses, architecture, installation, professional services and ongoing support.

Discuss your SUSE project