# Operate and harden SUSE Multi-Linux Manager 5.2 in production Source: https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production Language: en Published: 2026-09-18 Updated: 2026-10-16 Operate SUSE Multi-Linux Manager 5.2 long-term: backup, restore, TLS, roles, monitoring, storage, channel sync, maintenance windows and handover. ## 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. ## 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" ``` [![Product status after the first SL Micro 6.2 sync.](https://forgeone.solutions/media/suse-mlm-5-2-14-product-sync-status.png)](https://forgeone.solutions/media/suse-mlm-5-2-14-product-sync-status.png) ## 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. [![System list with patch and package indicators.](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-02-system-list.png)](https://forgeone.solutions/media/suse-mlm-patch-lifecycle-02-system-list.png) ## 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. ## 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. [![Cockpit storage view with the separate data disk.](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png)](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png) ## 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. [![Scheduled actions in SUSE Multi-Linux Manager 5.2.](https://forgeone.solutions/media/08-scheduled-actions.png)](https://forgeone.solutions/media/08-scheduled-actions.png) ## Evidence from the tested manager environment The following sections do more than list commands. They show real state from the tested SUSE Multi-Linux Manager 5.2 environment: registered clients, channel assignment, package and patch counts, scheduled actions and the current audit state. access data, registration codes and internal infrastructure are deliberately not visible. ## Maintenance windows, calendars and real scheduled actions An iCalendar-based maintenance calendar is present in the lab. The technical execution remains visible through scheduled actions: package-list refreshes, reboots, patch runs and audit jobs must be reviewed per system group in production. [![Maintenance calendar in SUSE Multi-Linux Manager with a configured ForgeOne lab maintenance calendar.](https://forgeone.solutions/media/13-maintenance-calendars.png)](https://forgeone.solutions/media/13-maintenance-calendars.png) [![Maintenance schedules in SUSE Multi-Linux Manager without an assigned production schedule.](https://forgeone.solutions/media/14-maintenance-schedules.png)](https://forgeone.solutions/media/14-maintenance-schedules.png) [![Scheduled actions in SUSE Multi-Linux Manager with package-list and reboot jobs.](https://forgeone.solutions/media/06-scheduled-actions-real-jobs.png)](https://forgeone.solutions/media/06-scheduled-actions-real-jobs.png) [![Completed actions in SUSE Multi-Linux Manager with successful inventory and package jobs.](https://forgeone.solutions/media/23-completed-actions.png)](https://forgeone.solutions/media/23-completed-actions.png) [![Failed actions in SUSE Multi-Linux Manager as a real troubleshooting starting point.](https://forgeone.solutions/media/24-failed-actions.png)](https://forgeone.solutions/media/24-failed-actions.png) - Maintenance calendars define allowed windows. - Scheduled Actions show technical execution. - System groups define which systems are affected. - Reports and audit results prove the outcome after the window. ## grommunio community repositories in the manager For grommunio, this environment deliberately integrates the community repository only. grommunio supports Debian, Ubuntu and SUSE/openSUSE-based package paths; EL clients are not planned as target platforms for this workload. [![Custom repositories for grommunio Community on openSUSE Leap, Debian and Ubuntu.](https://forgeone.solutions/media/03-custom-repositories-grommunio.png)](https://forgeone.solutions/media/03-custom-repositories-grommunio.png) [![Repository detail of the grommunio community Debian 13 repository.](https://forgeone.solutions/media/32-grommunio-debian-repo-detail.png)](https://forgeone.solutions/media/32-grommunio-debian-repo-detail.png) [![Repository detail of the grommunio community Ubuntu 24.04 repository.](https://forgeone.solutions/media/33-grommunio-ubuntu-repo-detail.png)](https://forgeone.solutions/media/33-grommunio-ubuntu-repo-detail.png) [![grommunio Community openSUSE Leap 16.0 channel with synchronized packages.](https://forgeone.solutions/media/10-grommunio-opensuse-channel-detail.png)](https://forgeone.solutions/media/10-grommunio-opensuse-channel-detail.png) [![Package list of the grommunio community openSUSE channel with real grommunio packages.](https://forgeone.solutions/media/28-grommunio-opensuse-package-list.png)](https://forgeone.solutions/media/28-grommunio-opensuse-package-list.png) [![grommunio Community Debian 13 channel with synchronized packages.](https://forgeone.solutions/media/11-grommunio-debian-channel-detail.png)](https://forgeone.solutions/media/11-grommunio-debian-channel-detail.png) [![Package list of the grommunio community Debian channel with real grommunio packages.](https://forgeone.solutions/media/29-grommunio-debian-package-list.png)](https://forgeone.solutions/media/29-grommunio-debian-package-list.png) [![grommunio Community Ubuntu 24.04 channel with synchronized packages.](https://forgeone.solutions/media/12-grommunio-ubuntu-channel-detail.png)](https://forgeone.solutions/media/12-grommunio-ubuntu-channel-detail.png) [![Package list of the grommunio community Ubuntu channel with real grommunio packages.](https://forgeone.solutions/media/30-grommunio-ubuntu-package-list.png)](https://forgeone.solutions/media/30-grommunio-ubuntu-package-list.png) ## Content staging: identical package levels across dev, UAT and production The most important production value of SUSE Multi-Linux Manager is not installing the newest packages everywhere as quickly as possible. The key is moving defined package levels in a controlled way from development through UAT into production and proving which level is approved where. 1. DEV receives new package levels first so technical compatibility, service startup, migrations and rollback can be tested. 2. UAT only receives the package level that passed technically in DEV and is ready for business acceptance. 3. PROD receives the exact approved level from UAT, not automatically the newest upstream repository state. 4. Activation keys and system groups ensure that new systems land in the correct stage and channel immediately. 5. Reports, CVE audit and scheduled actions prove which level was rolled out and where deviations remain. For grommunio this means: community or subscription content is first synchronized into a tested channel, approved for DEV, promoted to UAT and only used for PROD after acceptance. This lets you test new grommunio packages without UAT or production unintentionally receiving the same new level. ## 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. [![Cockpit storage view with the separate data disk.](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png)](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png) ## Operations pitfall: do not rename manager and proxy casually The FQDN of a SUSE Multi-Linux Manager system is part of the operating architecture. It appears in certificates, bootstrap configuration, Salt communication, repository URLs and sometimes persistent container or service configuration. A rename therefore belongs into a planned maintenance window. - Before the rename: document DNS, certificate names, manager URL, proxy parent and client reachability. - During the rename: adjust manager configuration, bootstrap overrides, Salt master/minion configuration and proxy configuration consistently. - After the rename: validate Salt ping, pkg.refresh\_db, web UI system list, proxy status, channel access and certificate chain separately. - Do not consider the work finished just because the minion is green again. Repository metadata can still point to the old manager FQDN. ## 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 - [SUSE Multi-Linux Manager 5.2 documentation](https://documentation.suse.com/multi-linux-manager/5.2/en/docs/index.html) - [SUSE Multi-Linux Manager 5.2 Release Notes](https://documentation.suse.com/releasenotes/multi-linux-manager/5.2/index.html) - [SUSE Multi-Linux Manager product page](https://www.suse.com/products/multi-linux-manager/) ### 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](https://forgeone.solutions/en/contact) ## Hero image [![Cockpit storage view with the separate data disk.](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png)](https://forgeone.solutions/media/suse-mlm-5-2-06-cockpit-storage.png) ## Author Mathias Rumbold ## Category - [Enterprise Linux](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?category=enterprise-linux) - [Linux Lifecycle Management](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?category=linux-lifecycle-management) ## Tags - [SUSE](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?tags=suse) - [SUSE Multi-Linux Manager](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?tags=suse-multi-linux-manager) - [Hardening](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?tags=hardening) - [Backup](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?tags=backup) - [Enterprise Linux](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production?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. [Install SLES 16 for production: from ISO to manageable Linux server](https://forgeone.solutions/en/tech/install-sles-16) 2. [SLES 16 and Enterprise Linux: How Different Is Day-to-Day Administration?](https://forgeone.solutions/en/tech/sles-16-enterprise-linux-rhel-rocky-almalinux-comparison) 3. [Hardening and auditing SLES 16: OpenSCAP, CIS context and SUSE Multi-Linux Manager](https://forgeone.solutions/en/tech/sles-16-hardening-openscap-cis-mlm) 4. [Install SUSE Multi-Linux Manager 5.2 for production: SL Micro, storage and first channel sync](https://forgeone.solutions/en/tech/install-suse-multi-linux-manager-5-2-sl-micro) 5. [SUSE Multi-Linux Manager 5.2: onboard first Linux clients for production](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-onboard-linux-clients) 6. [SUSE Multi-Linux Manager 5.2: build production patch and lifecycle management](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management) 7. [SUSE Multi-Linux Manager 5.2: manage mixed Linux estates in production](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-manage-mixed-linux) 8. [SUSE Multi-Linux Manager 5.2: use OpenSCAP, compliance and audit in production](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-openscap-compliance-audit) 9. [SUSE Multi-Linux Manager 5.2: build proxies for sites and distributed Linux estates](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-build-proxies-for-sites) 10. [SUSE Multi-Linux Manager 5.2: integrate SSO with Keycloak, SAML and MFA](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-integrate-sso-keycloak-saml-mfa) 11. [SUSE Multi-Linux Manager 5.2: use Ansible next to Salt in production](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-ansible-next-to-salt) 12. [SUSE Multi-Linux Manager 5.2: build reporting, inventory and subscription audit](https://forgeone.solutions/en/tech/suse-multi-linux-manager-5-2-reporting-inventory-subscription-audit) 13. [Operate and harden SUSE Multi-Linux Manager 5.2 in production (current part)](https://forgeone.solutions/en/tech/operate-harden-suse-multi-linux-manager-5-2-production)