Install SUSE Multi-Linux Manager 5.2 for Production: SL Micro, Storage and First Channel Sync

Prerequisites

You need suitable SUSE images, entitlements, DNS, NTP, storage, network access and administrative accounts. Registration and mirroring data stay out of screenshots, Git and public text.

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

Goal of this guide

SUSE Multi-Linux Manager is the central lifecycle management platform for Linux estates. It lets you manage software channels, patches, activation keys, bootstrap processes, Salt-based configuration, system groups, compliance information and recurring operational tasks from one place.

The value becomes clear when servers should no longer be maintained one by one: SLES, SL Micro and selected other Linux distributions can be registered, supplied with approved repositories, patched, grouped and operated with traceability. Manual server maintenance becomes a reproducible platform process.

This first Multi-Linux Manager article therefore focuses deliberately on building the server platform. Clients, patch staging, mixed distributions and hardening follow in dedicated parts so every step remains easy to reproduce.

This guide shows how to set up SUSE Multi-Linux Manager 5.2 on SL Micro 6.2 so it becomes a reliable platform for Linux lifecycle management. At the end, the Manager is installed, registered, prepared with separate storage, reachable through the web interface and the first channel has been synchronized successfully.

The focus is not a quick demo. It is a production build: clean DNS and storage decisions, registered content, traceable checks, a controlled first sync and a clear handover into operations.

SUSE Multi-Linux Manager is the central lifecycle platform for Linux estates. It lets you manage software channels, updates, security advisories, activation keys, bootstrap workflows, Salt-based management, system groups, reporting and recurring operational tasks through one shared control plane.

The value does not start only at hundreds of systems. Even with a small production estate, the Manager helps keep repositories, patch levels, responsibilities and maintenance windows traceable. Instead of maintaining every server manually, you build a reproducible operating model.

Prepare for production operations

SUSE Multi-Linux Manager is a central system. If it later controls patches, channels, bootstrap repositories and client configuration, networking, storage, backup and access must be planned cleanly from the beginning.

Plan the Manager as a central infrastructure component. If the Manager is unavailable, clients do not immediately stop running, but patch control, reporting, bootstrapping and central actions are limited. DNS, NTP, storage, backup, certificates and monitoring therefore belong into the baseline before the first client rollout.

• FQDN and DNS: stable hostname, forward/reverse DNS and certificate planning.

• Resources: enough CPU and memory for web UI, database, repository sync and the future client count.

• Storage: separate data disk for Manager volumes and repository content, not just the system disk.

• Content access: SUSE Customer Center or approved mirroring access values; no sensitive values in figures or runbooks.

• Firewall: deliberately allow HTTPS, SSH, Salt ports and Cockpit instead of opening everything broadly.

• Operations: clarify backup, monitoring, patch windows, role model and documentation before client rollout.

Download and verify the image

This installation uses the official SUSE Multi-Linux Manager Server 5.2 QCOW2 image. Download the image only from SUSE Customer Center or an approved internal mirror and verify the SHA-256 checksum against the official metadata file.

sha256sum SUSE-Multi-Linux-Manager-Server.x86_64-5.2.0-Qcow-GM.qcow2
# Ausgabe mit der offiziellen SUSE-Prüfsumme für genau dieses Image vergleichen.

If a signature file is available, verify it with the matching SUSE public key. The verification must be traceable in internal documentation; public articles must not contain account-specific download URLs or access values.

Create the VM for production

The Manager runs as an appliance on SL Micro 6.2. The build used UEFI/OVMF, a system disk and a separate data disk. The separate data disk matters because repository content and persistent container volumes will grow.

qemu-img create -f qcow2 -b SUSE-Multi-Linux-Manager-Server.x86_64-5.2.0-Qcow-GM.qcow2 -F qcow2 mlm52-system.qcow2
qemu-img create -f qcow2 mlm52-data.qcow2 300G

For production, size beyond a minimal lab. Repository sync, database, bootstrap repositories, logs and backups need headroom. The first SL Micro 6.2 sync already consumed a measurable amount of Manager storage.

First boot and baseline validation

On first boot, set hostname, networking and admin access. Then verify the base system before running `mgradm`. This separation matters: stabilize the appliance base first, deploy the Manager stack second.

https://mlm01.example.test/

First boot of the SUSE Multi-Linux Manager appliance with a neutral hostname.

hostnamectl
cat /etc/os-release
systemctl --failed
ip address
ip route

Register and update the system

Register the system with the appropriate SUSE subscription and verify the status. Registration values are not copied into logs, figures or public documentation. After registration, update SL Micro through `transactional-update` and reboot when required.

sudo SUSEConnect --status-text
sudo transactional-update
sudo reboot

Prepare Manager storage

For SUSE Multi-Linux Manager 5.2, persistent Podman volumes and repository content are placed on separate storage. In the validated installation, the data disk was prepared with `mgr-storage-server` and used as an XFS volume for `/var/lib/containers/storage/volumes`.

Storage is not a side note for SUSE Multi-Linux Manager. Channels, package metadata, images, logs and database content grow with every additional distribution. Separate system disk and Manager data early, document mount points and watch capacity before the first large synchronization run.

lsblk
sudo mgr-storage-server /dev/vdb
findmnt /var/lib/containers/storage/volumes
df -h /var/lib/containers/storage/volumes

https://mlm01.example.test:9090/system/storage

Cockpit Storage shows the separate data disk for Manager volumes and repository content.

Install the Manager with mgradm

The primary installation command for this validated 5.2 environment is `mgradm install <fqdn>`. The FQDN must match the planned server name because it later appears in the web UI, certificates, clients and bootstrap configuration.

`mgradm` builds the containerized Manager from the prepared components. Do not treat this step as a black box: document FQDN, certificate choice, admin access, container state and service state. Afterwards the web UI must be reachable and the CLI must be able to verify the system.

sudo mgradm install mlm01.example.test
sudo mgradm status
sudo podman ps
systemctl status uyuni-server.service --no-pager
systemctl status uyuni-db.service --no-pager

After successful installation, the server and database containers are healthy. If `mgrctl status` is not available in your environment, use `mgradm status`, systemd and Podman checks.

Open the web UI and verify admin login

Open the Manager web UI through the final FQDN and log in with the configured admin account. For production systems, protect this access with TLS, firewall rules, admin networks and a role model.

https://mlm01.example.test/

Login to the SUSE Multi-Linux Manager web interface through the planned FQDN.

https://mlm01.example.test/

Dashboard after successful login with visible Manager version 5.2.

Validate Cockpit for day-2 operations

Cockpit does not replace lifecycle management in the Manager, but it helps with day-2 tasks on the appliance host: system status, networking, services, storage and quick diagnostics. This is especially valuable before clients are attached.

https://mlm01.example.test:9090/system

Cockpit system overview of the installed SL Micro based Manager appliance.

https://mlm01.example.test:9090/network

Cockpit networking view for validating the management connection.

Start the Setup Wizard

After the technical deployment, the Setup Wizard configures content access. This is the point where an installed server becomes a usable Manager platform.

https://mlm01.example.test/

Navigation to the Setup Wizard in the Manager web interface.

Enter SCC mirroring access values securely

Mirroring access values belong only in the intended form. Do not write them into figures, shell history, tickets or blog text. After saving, the Manager loads the product catalog from SUSE Customer Center.

https://mlm01.example.test/

Access-values form without visible access values before saving.

https://mlm01.example.test/

Loaded product catalog after successful SCC connection.

Synchronize the first product and channel

Do not start with every product at once. For the first production sync, choose one clearly bounded target product, verify the channels and synchronize in a controlled way. The validated environment used `SUSE Linux Micro 6.2 x86_64`, including the Manager tools channel.

The first synchronization proves that SCC credentials, Product Catalog, channel selection, storage and background jobs work together. In production, start deliberately small: one product, one clear target channel, then verify status. Only after that path is stable should you add more products and distributions.

https://mlm01.example.test/

Product catalog filtered for SL Micro 6.2.

https://mlm01.example.test/

Selected SL Micro 6.2 product before adding channels.

https://mlm01.example.test/

The first repository sync has been scheduled and started.

https://mlm01.example.test/

Completed sync status for the first SL Micro 6.2 channel.

Verify repository sync on the CLI

The web interface shows sync status, but for a reliable acceptance you also verify logs, channels and storage usage. Outputs with temporarily signed repository URLs must not be shared unfiltered.

sudo podman ps
sudo mgradm status
sudo journalctl -u uyuni-server.service -n 80 --no-pager
sudo du -sh /var/lib/containers/storage/volumes/var-spacewalk
df -h /var/lib/containers/storage/volumes

Validate firewall, services and health

Before the first client rollout, it must be clear which ports are intentionally open and which services are running. HTTPS and Salt communication are central for the Manager; SSH and Cockpit should be restricted to admin networks.

systemctl --failed
sudo ss -tulpn
sudo firewall-cmd --state || true
sudo firewall-cmd --list-all || true
sudo podman volume ls

Do not postpone backup and restore

As soon as the Manager controls channels, keys, clients and policies, it becomes critical. Configure backup before registering production clients. Also verify where database, repository content, configuration and certificates are stored.

sudo mgradm backup --help
sudo mgradm backup create --help

Production checklist before client rollout

• FQDN, DNS, TLS and admin access are final.

• System and Manager extension are registered.

• Separate storage volumes are configured and have enough headroom.

• Manager containers and systemd units are healthy.

• The first repository sync completed successfully.

• Bootstrap repositories have been regenerated.

• Backup, monitoring, logs and patch windows are defined.

• Role model and access to web UI, SCC access values and clients are clarified.

• Only then attach test clients first and production systems afterwards.

What comes next

After the server installation, the next useful steps are bootstrapping an SL Micro or SLES client, channel and lifecycle strategy, patch staging, groups, activation keys, compliance reports and later proxy operation for distributed sites. These topics belong in dedicated guides so this installation article stays clear.

Architecture: what the manager actually provides

• SL Micro 6.2: stable container host
• Podman + Netavark: manager containers and networking
• Persistent Podman volumes: database, configuration and repository content
• SUSE Customer Center Product Catalog: available products and channels
• Channel sync: locally managed content
• Linux clients: registration, Salt, patch and package state

Where to find what in SUSE Multi-Linux Manager 5.2

• 1. Install SLES 16 for production: /en/tech/install-sles-16
• 2. Install SUSE Multi-Linux Manager 5.2 for production: /en/tech/install-suse-multi-linux-manager-5-2-sl-micro - this article.
• 3. Onboard first Linux clients for production: /en/tech/suse-multi-linux-manager-5-2-onboard-linux-clients
• 4. Build production patch and lifecycle management: /en/tech/suse-multi-linux-manager-5-2-patch-lifecycle-management
• 5. Manage mixed Linux estates in production: /en/tech/suse-multi-linux-manager-5-2-manage-mixed-linux

Operations and validation

A successful installation alone is not enough for production operations. Validate services, logs, networking, login, updates, backup and recovery so that the state is repeatable and understandable for other administrators.

Sources and further documentation

For production work, also use the current vendor documentation, release notes, security advisories and internal operational standards. ForgeOne complements those sources with practical project experience from planning, implementation and operations.

Feature scope: what SUSE Multi-Linux Manager covers

SUSE Multi-Linux Manager is the central operations platform for heterogeneous Linux estates. You use it to manage products and software channels, register clients, control Salt-based configuration, evaluate patches and CVEs, build content lifecycle environments, schedule actions, generate reports and validate compliance with OpenSCAP.

• Product catalog and channel sync from SUSE Customer Center as the content base.
• Activation keys, bootstrap and Salt Bundle for reproducible client onboarding.
• System lists, groups, package state and patch state as daily operations views.
• Content Lifecycle Management for development, test and production approvals.
• OpenSCAP, CVE audits, subscription matching and reports for auditability.
• Backup, restore, certificates, monitoring, roles and storage planning for long-term operation.

The value is not that every distribution becomes identical. The value is that different Linux systems become visible, maintainable and auditable through one operational model.

app.example.com

Production check after installation

1. The manager FQDN resolves correctly internally and externally.
2. The TLS certificate and browser access work via HTTPS on port 443.
3. Persistent volumes are on planned storage with enough reserve.
4. The SCC organization is connected and access values are not stored in shell history or documentation.
5. The product catalog is visible and at least one required channel has been synchronized.
6. Admin account, role model, backup target and monitoring are defined before production clients are onboarded.

Product Catalog, channels and first sync as the operating foundation

After the base installation, the manager only becomes production-ready when the Product Catalog is loaded and the required channels are selected deliberately. These channels later feed activation keys, bootstrap scripts, patch status, CVE audit and reports.

app.example.com

For this series, the relevant channel families for SLES 16, SL Micro 6.2, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10, AlmaLinux 10 and Oracle Linux 10 were validated or assessed. In production, document purpose, target group, sync window, retention, owner and activation key for every channel.

app.example.com