SUSE Multi-Linux Manager Server 5.2

SUSE Multi-Linux Manager 5.2 introduces support for deploying and running the Server on Kubernetes. This provides an alternative deployment model alongside the existing Podman-based containerized setup, offering organizations greater flexibility in aligning SUSE Multi-Linux Manager with their existing container orchestration infrastructure.

Given the variety of Kubernetes distributions and deployment configurations available, initial support begins with a limited support matrix focused on RKE2. Support for additional Kubernetes distributions and configurations will be evaluated and expanded over time.

This feature is available as a Technology Preview and will be moved to a fully supported state in a future release.

SUSE Multi-Linux Manager 5.2 introduces a modernized approach to SCAP (Security Content Automation Protocol) auditing. The enhanced SCAP integration streamlines compliance scanning by centralizing content management, introducing reusable policies, supporting automated remediation, and eliminating the need to pre-stage SCAP files on managed systems.

Key improvements include centralized SCAP content management, reusable scan policies, automated remediation support, and recurring scan scheduling.

This feature is available as a Technology Preview and will be moved to a fully supported state in a future release.

SUSE Multi-Linux Manager 5.2 will introduce support for Confidential Computing (CoCo) Attestation on IBM Z series (s390x) architecture. This capability enables verification that workloads are running in a trusted, confidential execution environment, strengthening security for sensitive workloads on IBM Z infrastructure.

This will be supported with the 1st Maintenance Update.

Building on the Technology Preview introduced in SUSE Multi-Linux Manager 5.1, CVE auditing based on OVAL data is now fully supported. By consuming OVAL data, CVE audit delivers more accurate vulnerability assessment results compared to relying solely on channel metadata.

During the lifecycle of SUSE Multi-Linux Manager 5.2, support for additional operating systems and versions will be added as they become available or soon after. For example, Ubuntu 26.04 LTS is now supported starting with the 5.2.1 Maintenance update.

SUSE Multi-Linux Manager continues to offer comprehensive management capabilities for a wide range of distributions, including SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP Applications, SUSE Linux Enterprise Server Micro, SUSE Linux Micro, Red Hat Enterprise Linux, openSUSE, SUSE Liberty Linux, Oracle Linux, AlmaLinux, Rocky Linux, Ubuntu, Debian, and Amazon Linux.

SUSE Multi-Linux Manager 5.2 will not be a base product, similar to previous 5.x versions. Instead, it will be an extension for SUSE Linux Micro 6.2 and SUSE Linux Enterprise 15 SP7, available through the SUSE Customer Center. This extension will include all the necessary tools to install and manage SUSE Multi-Linux Manager.

SUSE Multi-Linux Manager 5.2 Server will be supported on x86_64, s390x, IBM POWER (ppc64le), and ARM64 (AArch64) architectures.

SUSE Multi-Linux Manager Server, Proxy, and Retail Branch Server will be delivered as containers, accessible via the SUSE Registry.

SUSE Linux Enterprise Server as Host OS requires an additional subscription, while SUSE Linux Micro is included.

Additionally, VM images based on SUSE Linux Micro are provided for simplified setup, featuring preloaded configurations for easy customization.

For more details on system requirements, see the Installation Guide on https://documentation.suse.com/multi-linux-manager/5.2/

In-place upgrade from SUSE Multi-Linux Manager Server 5.0 and 5.1 is supported, if the host operating system remains the same.

SUSE Multi-Linux Manager Server 5.2 includes tools designed to simplify the migration process.

Once the upgrade is complete, all connected clients will seamlessly continue to run without any changes.

For detailed instructions on upgrading, please refer to the Upgrade Guide available at https://documentation.suse.com/multi-linux-manager/5.2/

Although SUSE Multi-Linux Manager Server 5.2 works with SUSE Multi-Linux Manager Proxy  5.1 and SUSE Multi-Linux Manager Retail Branch Server 5.1, we highly recommend upgrading your Proxy and Retail Branch Server when feasible. The product is designed for optimal performance when used in a scenario where all components — SUSE Multi-Linux Manager Server, SUSE Multi-Linux Manager Proxy, and Retail Branch Server — are of the same version. It is generally advised to avoid using mixed versions long-term in production environments.

When upgrading, upgrade the SUSE Multi-Linux Manager Server first, followed by the SUSE Multi-Linux Manager Proxy and Retail Branch Servers.

For instructions on upgrading when SUSE Multi-Linux Manager Proxy or SUSE Multi-Linux Manager Retail Branch Servers are in use, see the Upgrade Guide on https://documentation.suse.com/multi-linux-manager/5.2/.

The SUSE Patch Finder is a simple online service to view released patches.

SUSE Multi-Linux Manager 5.2 continues to use Salt 3006 (LTS) for now. The plan is to upgrade to the next LTS version 3008.x later at a later date during the lifecycle of 5.2.

The database engine has been updated to PostgreSQL 18, which brings a number of performance and reliability improvements. A detailed changelog is available upstream.

SUSE Multi-Linux Manager 5.2 is delivered as containers, built on the bci-init image.

With version 5.2, SUSE Multi-Linux Manager moves to SUSE Linux Micro 6.2 and SUSE Linux Enterprise 15 SP7 as its supported container host systems. The SL Micro subscription for the host server is included with the SUSE Multi-Linux Manager subscription. However, for SUSE Linux Enterprise 15 SP7, users will need to have a separate subscription.

SUSE Multi-Linux Manager 5.2 introduces support for deploying the Server on Kubernetes as an alternative to the existing Podman-based containerized setup. Initial support focuses on RKE2, with additional Kubernetes distributions and configurations to be evaluated over time.

Note that Kubernetes deployment is only supported for new installations; migration from Podman-based deployments to Kubernetes is not supported.

For more information about supported configurations and environments, see Support on Kubernetes.

For deployment instructions, see the Deployment on Kubernetes documentation.

A modernized approach to SCAP auditing is now available, featuring centralized content management, reusable scan policies, automated remediation support, and recurring scan scheduling. This eliminates the need to pre-stage SCAP files on managed systems.

By default, this beta feature is disabled. Users can enable it by navigating to Home → My Preferences, checking the Enable Beta Features checkbox, and clicking Submit.

For more information, consult the documentation: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/openscap-enhanced-beta.html

Building on the Technology Preview from SUSE Multi-Linux Manager 5.1, CVE auditing based on OVAL data is now fully supported. This provides more accurate vulnerability assessment compared to relying solely on channel metadata.

SUSE Multi-Linux Manager 5.2 supports migrating managed clients from SUSE Linux Enterprise Server 15 SP7 to SUSE Linux Enterprise Server 16.0 using the built-in product migration feature. This enables administrators to seamlessly upgrade their managed systems to the latest SUSE Linux Enterprise Server release directly from the SUSE Multi-Linux Manager web interface.

This migration process differs from other migration workflows. It is performed in two steps: the migration itself, followed by a dedicated verification step to confirm the result.

SUSE Multi-Linux Manager 5.2 introduces a new reporting dashboard integrated with the existing Grafana monitoring stack.

While the read-only reporting database continues to support third-party visualization tools such as Metabase, these new dashboards provide a convenient out-of-the-box option for viewing and filtering report data. Administrators can leverage Grafana’s powerful visualization and filtering capabilities directly within the existing monitoring infrastructure, eliminating the need to configure additional tools.

SUSE Multi-Linux Manager 5.2 adds full support Raspberry Pi OS 13 clients managed via Salt, graduating them from the Technology Preview status they held in version 5.1.

For a detailed list of supported features, see the Supported Features for Raspberry Pi OS documentation.

SUSE Multi-Linux Manager 5.2 can now be deployed on a FIPS-enabled SUSE Linux Enterprise Server 15 SP7 host OS. This allows organizations with strict cryptographic compliance requirements to run SUSE Multi-Linux Manager within a FIPS-enforced environment.

SUSE Multi-Linux Manager 5.2 also comes with bootstrap repository definitions and product entries for SUSE Liberty Linux 9.6 EMS (Extended Minor Version Support).

Administrators can now register and manage SUSE Liberty Linux 9.6 clients directly from SUSE Multi-Linux Manager 5.2.

SUSE Multi-Linux Manager 5.2 introduces the ability to disable automatic synchronization on a per-channel basis. By default, channels are kept in sync with their upstream repositories to ensure clients always have access to the latest content. In cases where tighter control over update timing is required, administrators can now opt specific channels out of automatic synchronization and trigger syncs manually instead.

The synchronization status of a channel can be viewed via the API or the Web UI. However, enabling or disabling automatic synchronization can only be configured through the API for now. Even when automatic synchronization is disabled, channels can still be synchronized on demand using spacewalk-repo-sync.

For full details on verifying synchronization status, disabling automatic sync, and running manual syncs, see the Configuring Channel Synchronization documentation.

The monitoring server-related packages previously shipped in the SLES 12 client tools channels have been removed. These packages allowed a SLES 12 system to act as a monitoring server and included components such as Prometheus, Alertmanager, Grafana, and related dashboards.

Client-side monitoring components (exporters) continue to be provided, ensuring that SLES 12 systems can still be monitored by an external monitoring server.

The smdba tool, deprecated since SUSE Multi-Linux Manager 5.1, has been removed. Users should use the built-in backup and restore solution instead. For more details, see the Administration Guide.

The spacewalk-manage-channel-lifecycle tool has been removed. Content Lifecycle Management (CLM) fully covers the functionality previously offered by this tool as well as the previously deprecated spacewalk-clone-by-date tool. We strongly recommend migrating existing workflows and scripts to CLM.

The cobbler_api XML-RPC endpoint is no longer reachable from outside the server container; access is now restricted to localhost. This endpoint is only used internally by SUSE Multi-Linux Manager and was never intended to be exposed publicly.

Using Cobbler directly, outside of the SUSE Multi-Linux Manager integration, is not supported. If external access to cobbler_api is still required, create the following file inside the server container at /etc/apache2/conf.d/zz-cobblerapi.conf:

All Prometheus exporters provided in the RHEL and clone client tools, with the exception of the Node Exporter (golang-github-prometheus-node_exporter) are deprecated and scheduled for removal in a future release.

The Enhanced SCAP Auditing Integration is still available as a Technology Preview in SUSE Multi-Linux Manager 5.2.1 and is planned to become generally available in 5.2.2 maintenance update. Ahead of that change, the following legacy system.scap API endpoints, which rely on pre-staging XCCDF/OVAL files on managed systems, are now deprecated and will be removed once the new SCAP integration becomes generally available:

Users of these endpoints should migrate to the Technology Preview policy-based or custom scan endpoints instead:

Once the Enhanced SCAP Auditing Integration becomes generally available, these two methods will be renamed to system.scap.scheduleXccdfScanWithPolicy and system.scap.scheduleXccdfScanCustom, and will no longer require beta features to be enabled.

Users who require these exporters on client systems should obtain them directly from their respective upstream vendors.

Debian 12 reached end of life on 11th July 2026 and has now entered its 3-month grace period. SUSE Multi-Linux Manager 5.2.1 is the last release to update the Debian 12 client tools.

When handling Service Requests, supporters and engineers may ask for the output of the supportconfig tool from SUSE Multi-Linux Manager Server or clients.

This disclaimer applies:

When you run supportconfig or mgradm support, the output will contain information about your clients as well as about the Server. In particular, debug data for the subscription matching feature contains a list of registered clients, their installed products, and some minimal hardware information (such as the CPU socket count). It also contains a copy of the subscription data available from the SUSE Customer Center.

If this is a concern, please prune data in the subscription-matcher directory in the spacewalk-debug tarball before sending it to SUSE.

SUSE Multi-Linux Manager 5.2 Server can now be deployed as a containerized workload on RKE2, alongside the existing Podman-based deployment.

All software components embedded into SUSE Multi-Linux Manager, like Cobbler for PXE booting, are only supported in the context of SUSE Multi-Linux Manager. Stand-alone usage (e. g. Cobbler command-line) is not supported.

The SUSE Multi-Linux Manager engineering team provides best effort support for products past their end-of-life date. For more information about product support, see Product Support Lifecycle.

Support for products that are considered past their end-of-life is limited to assisting you to bring production systems to a supported state. This could be either by migrating to a supported service pack or by upgrading to a supported product version.

SUSE Multi-Linux Manager supports SUSE Liberty Linux 7, 8, 9 and 10. SUSE Liberty Linux is the technical name used for SUSE Multi-Linux Support (MLS) offering. SUSE Liberty Linux clients are sometimes also called SUSE Linux Enterprise Server with Expanded Support (SLESES) or simply RES.

SUSE has offered LTSS support for SUSE Liberty Linux 7, and SUSE Multi-Linux Manager will continue to support it throughout the LTSS phase.

For a detailed list of supported features, check the Client Configuration Guide.

SUSE Multi-Linux Manager supports RHEL/Oracle Linux 8, 9 and 10.

SUSE Multi-Linux Manager has the ability to mirror all entitled content for the supported operating systems. Although SUSE Multi-Linux Manager doesn’t assign content for specific systems using subscription-manager, it does rely on it initially to retrieve the list of repositories that are available. By utilizing the same EUS channels that Red Hat provides, customers can limit content to individual dot releases.

CentOS Stream is explicitly not supported by SUSE.

Note: Directly syncing ULN repos with SUSE Multi-Linux Manager is not currently supported. An Oracle Local Distribution for ULN must be used. To set up a local ULN mirror, please consult the Oracle documentation provided at the following link.

SUSE Multi-Linux Manager supports Rocky Linux 8/9/10 and AlmaLinux 8/9/10.

For a detailed list of supported features for AlmaLinux, check the Client Configuration Guide. For a detailed list of supported features for Rocky Linux, check the Client Configuration Guide.

SUSE Multi-Linux Manager supports Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS clients using Salt.

Support for Ubuntu is limited to a growing list of specific features. For a detailed list of supported features, check the Client Configuration Guide.

SUSE Multi-Linux Manager supports Debian 13 "trixie" clients using Salt.

Support for Debian is limited to a growing list of specific features. For a detailed list of supported features, check the Client Configuration Guide.

SUSE Multi-Linux Manager supports Raspberry Pi OS 13 clients using Salt.

Support for Raspberry Pi OS is limited to a growing list of specific features. For a detailed list of supported features, check the Client Configuration Guide.

The SUSE Multi-Linux Manager supports multiple major versions of non-SUSE client operating systems, such as RHEL, Rocky Linux, Debian and others. However, only the latest minor release of each supported major version is fully supported.

For example:

Older minor releases might still work but will only be supported on a limited and reasonable-effort basis. If issues arise on an outdated minor release, users will be asked to upgrade to the latest available minor version before further support is provided.

For RHEL clients on the ppc64le architecture, SUSE Multi-Linux Manager offers the same functionality that is supported for the x86_64 architecture. Client tools are not available yet from SCC but the https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Stable:EL<version>-Uyuni-Client-Tools client tools from Uyuni can be enabled using spacewalk-common-channels.

RHEL ppc64le are only supported at L1 level support. L1 support is limited to problem determination, which means technical support designed to provide compatibility information, usage support, on-going maintenance, information gathering, and basic troubleshooting using available documentation. At the time of writing, any problems or bugs specific to RHEL on ppc64le will only be fixed on a best-effort basis.

Please contact your Sales Engineer or SUSE Consulting if you need additional support or features for these operating systems.

SUSE provides the scap-security-guide package for different OpenSCAP profiles. In the current version of scap-security-guide, SUSE supports the following profiles:

Other profiles, like the CIS profile, are community supplied and not officially supported by SUSE.

For Non-SUSE OSs, please note that the included profiles are community supplied and not officially supported by SUSE.

Only the file Podman secret driver has been tested and is officially supported for SUSE Multi-Linux Manager container deployments at this time. Other drivers, such as pass or any custom or external secret providers, have not been tested and are not supported.

To effectively manage your SUSE Multi-Linux Manager environment via the Web UI, it’s essential to use an up-to-date web browser. SUSE Multi-Linux Manager is compatible with:

Please note that Windows Internet Explorer is not supported. The SUSE Multi-Linux Manager Web UI may not render correctly when accessed through Windows Internet Explorer.

Please refer to the General Requirements for a list of supported browsers.

The only supported method for installing SUSE Multi-Linux Manager is by utilizing images provided by SUSE, or the tools provided in the SUSE Multi-Linux Manager 5.2 Extension, on top of SUSE Linux Micro 6.2 and SUSE Linux Enterprise 15 SP7.

The default rhn_java_sso.conf configuration no longer requests a specific SAML authentication context from the IdP. Previously, the Password context was requested by default, which prevented passwordless authentication methods (FIDO2, Yubikey, Windows Hello) from working with strict SAML clients such as Microsoft Edge.

Action required for existing deployments: If your security policy requires enforcing password-based authentication at the SAML protocol level, uncomment and set the following lines in /etc/rhn/rhn_java_sso.conf:

Since Multi-Linux Manager 5.0, repositories are now kept strictly in sync with the upstream repository. For example, when a package is removed from the upstream repo, it is also removed from the channel directly connected to that repo. Cloned channels will remain unchanged unless the admin syncs them with the original parent channel.

Users can disable this behavior for custom channels; however, it cannot be changed for vendor channels.

A known issue in transactional-update can cause the snapshot created during package installation to be dropped if the system is not rebooted before further transactional operations are performed. This can affect SelfInstall images built on transactional systems such as SUSE Linux Micro.

For details and the workaround, see the following SUSE Knowledge Base article:

Kernel and kernel-livepatch errata for SUSE Linux Enterprise Server 15 SP7 have been split. Because the previous, combined errata had to be removed from the vendor channels and re-synced, some manual steps are required to get the new errata into your environment.

After the container upgrade, an automated product refresh with repo-sync is triggered, which brings the new errata into the vendor channels. However:

For Hub deployments, update the Hub container first. Only after the repo-sync has finished and the metadata has been regenerated on the Hub, update the container of the peripheral server(s).

The startup healthcheck for the server and database containers has been improved and now succeeds as long as all services start within 10 minutes, which covers all supported deployments meeting the minimum hardware requirements.

On systems where startup takes longer than 10 minutes, the healthcheck may still report a failure. If you encounter this, please report it, as it should not occur on supported hardware. In the meantime, you can work around it:

The currently active setting can be inspected with podman inspect <id>.

During mgradm install podman, after a system reboot, or at any other time the uyuni-server service is started, the service may occasionally fail to start with an error similar to:

On slower hardware, the database may not yet be ready to accept connections by the time the uyuni-server container starts and tries to connect to it. The server container currently does not retry these database connection attempts, so it can fail to start in this case, even though no data or configuration is actually affected.

To recover:

For some time, RFC 5280 has required the critical flag to be set for Certificate Authority (CA) certificates. While most clients currently ignore this requirement and still establish SSL connections without it, clients using Python 3.13 or later have switched to a strict policy. These newer clients will reject connections if the CA certificate lacks the critical flag.

By default, the automatically generated SSL CA certificates in SUSE Multi-Linux Manager 5.1 and earlier do not have the critical flag set.

You can verify that by following the instructions here Verify CA Basic Constraints.

If you are using these certificates without the Critical flag , you may encounter connection errors from clients enforcing strict validation. For example, spacecmd running on a SLES 16 client, or any custom scripts using the XML-RPC or REST APIs with Python 3.13+, could be affected.

To resolve this issue, you must rotate your certificates. Please refer to our documentation on Migrate SSL Certificate Authorities for the step-by-step procedure.

Migrating systems from SLES 15 SP7 to SLES 16 can leave an outdated SFTP subsystem path in /etc/ssh/sshd_config. This causes file transfer protocols like scp and sftp to fail. A permanent automated fix will be included in the next update.

Until this is fixed, please apply the following manual fix on affected SLES 16 minions:

After upgrading to version 5.2, Tomcat may fail to start with a Java core dump if monitoring was enabled prior to the upgrade.

The following error appears in the system journal (journalctl -u tomcat):

This is followed by a Java core dump and Tomcat failing to start.

Explicitly enabling or disabling monitoring via the Admin UI resolves the issue because the enable/disable Salt states remove the duplicate file.

Alternatively, remove the duplicate configuration files manually:

Then restart Tomcat and taskomatic:

When the SUSE Multi-Linux Manager server container runs on a host with FIPS mode enabled (/proc/sys/crypto/fips_enabled=1), Salt SSH minions stop checking in (shown as a black question mark in the systems list), and onboarding of new systems can also fail. Already onboarded regular (non-SSH) minions are not affected. The container inherits the host kernel’s FIPS flag but ships with the DEFAULT crypto policy, leaving it in an inconsistent state (FIPS kernel + non-FIPS policy). OpenSSH, acting as the Salt SSH client, then rejects its own configuration before it can open any connection.

As a result, the following error appears when the server tries to SSH into a client:

To resolve this, align the container’s SSH crypto policy with the FIPS-enabled kernel by pointing the OpenSSH back-end configuration at the FIPS profile already present in the image:

Custom installation images for S390x will be available later. Pre-configured installation images for all other supported architectures are available for SUSE Multi-Linux Manager 5.2, simplifying the initial installation process.