SUSE Multi-Linux Manager 5.2: onboard your first Linux clients for production

Goal of this guide

This article puts SUSE platform into a practical context and explains the decisions that matter for a reliable implementation. By the end, you should know what to prepare, how to recognize a working state and what the next useful step is.

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

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.

After installation, SUSE Multi-Linux Manager becomes valuable once real systems are connected. This guide shows step by step how to prepare a SLES 16 client for production use, register it with an activation key, accept the Salt key and verify the client in the manager.

The examples use neutral host names. Transfer them to your real manager FQDN, certificate model and network design.

SUSE series: from server to managed Linux estate

This article is the third part of the series. You start after the SLES 16 base article and the manager installation so the first client lands in the system reproducibly.

• 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-on-sl-micro
• 3. Onboard first Linux clients for production - /en/tech/suse-multi-linux-manager-5-2-onboard-linux-clients - this article.
• 4. Patch and lifecycle management - is planned as a later operational step.
• 5. Manage mixed Linux estates - is planned as a later operational step.
• 6. Harden production operations - is planned as a later operational step.

Target state

At the end, the manager knows the client as a Salt system, the client uses the manager channel instead of direct SCC repositories, time is synchronized, HTTPS and Salt connectivity works, and first patches or package differences are visible.

Client onboarding is the point where an installed Manager becomes a real operations platform. The Manager must not merely show a system in a list; it must detect the client correctly, assign suitable channels, establish Salt communication and report package and patch state reliably.

Prerequisites

Before every onboarding run, verify time, DNS, name resolution, firewall and HTTPS reachability. Time drift or wrong FQDNs later look like Salt, certificate or repository problems even when the root cause is in the baseline.

• SUSE Multi-Linux Manager 5.2 is installed, reachable by FQDN and usable through the web UI.
• Required products and channels can be synchronized from the SCC Product Catalog.
• The client can reach the manager via HTTPS and the Salt ports 4505 and 4506.
• DNS or internal name resolution is reliable for the environment.
• NTP is active on manager and client.
• You have admin access to the manager and root or sudo access to the client.

Example topology

• Manager: <mlm-fqdn>
• Client: <client-fqdn>
• Network: internal server network
• Roles: manager synchronizes channels, client registers through bootstrap and Salt

In production, do not use the temporary names from this article. Use your real internal FQDN. The FQDN must be consistent for client, manager, certificates and web UI.

1. Prepare product and channel

Open the Product Catalog in the manager and select the matching base channel for the client distribution, architecture and version. For this test, that is SLES 16.0 for x86_64.

A client can only be registered cleanly when its base channel and matching Client Tools are available. For SUSE systems, channels come from SCC. For Debian, Ubuntu, Rocky or Alma, the exact path depends on the supported product catalog and synchronized ManagerTools.

The same step is possible through the CLI. In production, document channel decisions because they influence patch management, lifecycle and reporting later.

mgr-sync add --no-optional --no-recommends --no-sync channel sle-product-sles-16.0-x86_64
spacewalk-repo-sync --channel sle-product-sles-16.0-x86_64 --type yum --non-interactive

2. Create bootstrap repository

The bootstrap process installs the appropriate Salt minion on the client and then registers the system with the manager. For that, the manager must provide a bootstrap repository for the target platform.

mgr-create-bootstrap-repo -l
mgr-create-bootstrap-repo -c SLE-16.0-x86_64

If bootstrap later fails with a 404 for `/pub/repositories/.../bootstrap`, this repository is missing or the channel sync has not completed yet.

3. Create activation key

An activation key bundles registration properties for clients: base channel, optional child channels, groups, add-ons and additional defaults. Use descriptive keys per distribution, version, architecture and operational role instead of a generic default key.

Activation keys are the controlled handover point between operating model and client. They define organization, base channel, child channels, system groups and optional parameters. In production, create keys by role, distribution and lifecycle target, not as one universal catch-all key.

spacecmd -q -u admin -p '[PASSWORD]' activationkey_create -- \ -n 'sles16-x86_64-prod' \ -d 'SLES 16 x86_64 production onboarding key' \ -b sle-product-sles-16.0-x86_64

Depending on the organization, the final key can be displayed with an organization ID prefix. Use the key in bootstrap exactly as the manager displays it.

4. Prepare the client

Before bootstrap, the client needs a stable host name, must resolve the manager by FQDN, needs synchronized time and must reach the manager via HTTPS.

hostnamectl
timedatectl
getent hosts <mlm-fqdn>
curl -kI https://<mlm-fqdn>/rhn/Login.do

5. Generate bootstrap script

The bootstrap script is generated on the manager and published under `/srv/www/htdocs/pub/bootstrap/`. The client downloads it via HTTPS.

mgr-bootstrap \ --activation-keys='[ORG]-sles16-x86_64-prod' \ --hostname=<mlm-fqdn> \ --script=bootstrap-sles16-client01.sh \ --force

6. Run bootstrap on the client

Run the script as root or with sudo on the client. A successful run detects the distribution, downloads the bootstrap repository, installs the venv Salt minion, registers the system and starts the minion.

The bootstrap script connects the client to the Manager, installs required tooling, sets repository information and prepares Salt. The client is not accepted just because the script exits: Salt key, system detail page, channel assignment and first check-in show whether onboarding is actually complete.

curl -kfsS https://<mlm-fqdn>/pub/bootstrap/bootstrap-sles16-client01.sh \ -o /root/bootstrap-sles16-client01.sh
chmod 700 /root/bootstrap-sles16-client01.sh
/root/bootstrap-sles16-client01.sh

Expected result:

• CA certificate is fetched from the manager
• SLE 16.0 is detected
• bootstrap repository is used
• venv-salt-minion is installed
• system is registered
• venv-salt-minion is enabled and started
• bootstrap complete

7. Accept Salt key

After bootstrap, the minion usually waits with an unaccepted key on the manager. Only accept keys when hostname and origin are clearly identifiable.

salt-key -L
salt-key -a <client-fqdn> -y
salt <client-fqdn> test.ping --out=txt

A successful `test.ping` returns `True`. That proves the Salt communication path is technically established.

8. Verify client in the manager

Open Systems -> System List -> All. The client should be visible with system type Salt, base channel, last check-in and package and patch information.

9. Inspect first patch and package status

After the first check-in, the manager can evaluate package and patch information. The actual patch run belongs in the next article, but at this stage it must be visible whether the client is manageable.

Troubleshooting from the real test

• Bootstrap repository is missing: If the client cannot find the bootstrap repository, synchronize the matching channel first and run `mgr-create-bootstrap-repo -c...`.
• Large channel sync fails: Check RAM, storage and swap. For production installations, SUSE recommends sufficiently fast persistent volumes and 8 to 12 GB swap.
• Salt key remains unaccepted: Check the key list, validate the hostname and then accept the exact key.
• Client still uses old repositories: Check the repository list. After successful registration, the manager channel should be active.
• Name resolution is unstable: Clean up FQDN, reverse DNS, `/etc/hosts` in small labs and firewall rules before bootstrapping again.

Production check before the next step

• Manager FQDN is stable and reachable with a proper certificate.
• SLES 16 channel is synchronized and bootstrap repository exists.
• Activation key is clearly named and documented.
• Client time is synchronized.
• HTTPS, 4505 and 4506 are reachable from client to manager.
• Salt key was accepted intentionally.
• Client appears in the system list with the correct base channel.
• Package and patch information becomes visible.

Next: patch and lifecycle management

The next article builds on this state: evaluate updates, classify patches, plan maintenance windows, use test groups and run the first controlled patch cycle.

Sources

• SUSE Multi-Linux Manager 5.2 documentation: client onboarding
• SUSE Multi-Linux Manager 5.2 documentation: registration methods
• SUSE Multi-Linux Manager 5.2 documentation: activation keys
• SUSE Multi-Linux Manager 5.2 documentation: server deployment and system requirements

Acceptance with multiple distributions

In the real test, SLES 16, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10 and AlmaLinux 10 were registered as Salt clients. All five systems returned `True` for `test.ping` and appeared in the system list with a current check-in.

Important onboarding differences

Multi-Linux does not mean every distribution is handled identically. SLES and SL Micro follow the SUSE entitlement and channel model, Debian and Ubuntu have their own package and security streams, and RHEL-compatible systems require deliberate content and support decisions. The Manager standardizes operations and visibility, but it does not erase distribution differences.

• ManagerTools are distribution-specific. A base channel alone is not reliable enough for bootstrap.
• Create the bootstrap repository only after content and ManagerTools sync have completed.
• Verify Product Catalog labels in your own manager. In the test, Rocky Linux 10 used `rockylinux-10-x86_64`, even though documentation examples can look different.
• Ubuntu needs an intentional sudo/root model because direct root login is often not available.
• Before rollout, Oracle Linux needs special attention around repository model, kernel variant and bootstrap support.

• 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
• 3. Onboard first Linux clients for production: /en/tech/suse-multi-linux-manager-5-2-onboard-linux-clients - this article.
• 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

Multi-distro onboarding: validated clients

Five different client families were successfully connected in the test: SLES 16, Debian 13, Ubuntu 24.04 LTS, Rocky Linux 10 and AlmaLinux 10. The manager sees them as Salt minions, reads OS grains and can display package and patch information centrally.

salt '*client01.lab.example' test.ping --out=txt
salt '*client01.lab.example' grains.item os osrelease osfinger --out=json

What activation keys do

Activation keys combine registration, base channel, child channels, system groups and contact method. In production, use separate keys per distribution, environment and responsibility area instead of one universal key for everything.

• SLES clients receive SUSE channels and the direct SCC/SLES lifecycle.
• Debian and Ubuntu remain apt-based systems and need suitable bootstrap and repository logic.
• Rocky and AlmaLinux follow the RHEL-compatible package model, but remain their own distributions.
• Oracle Linux is a valid target, but needs clean repository and support boundaries.
• SL Micro fits appliance, edge and container-host scenarios; transactional updates must be understood operationally.

Acceptance after onboarding

1. The client appears under Systems -> System List -> All.
2. Last check-in is current.
3. Salt test.ping returns True.
4. OS grains show the expected distribution and version.
5. Base channel and system group fit the distribution.
6. Patch or package status is visible.
7. A test command through the manager succeeds.

Screenshots from the 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.

1. Install SLES 16 for production
2. Install SUSE Multi-Linux Manager 5.2 for production
3. Onboard first Linux clients for production - this article
4. Build production patch and lifecycle management
5. Manage mixed Linux estates in production
6. Use OpenSCAP, compliance and audit in production
7. Build proxies for sites and distributed Linux estates
8. Integrate SSO with Keycloak, SAML and MFA
9. Use Ansible alongside Salt in production
10. Build reporting, inventory and subscription audit
11. Operate and harden the manager in production

https://mlm01.example.test/rhn/manager/systems/list/all

https://mlm01.example.test/rhn/activationkeys/List.do

https://mlm01.example.test/rhn/manager/systems/bootstrap

https://mlm01.example.test/rhn/groups/GroupDetail.do?sgid=13

• SLES 16: system ID 1000010000, SLES 16 base channel, relevant security advisory visible.
• Debian 13: registered as a Debian client, foundation for apt-oriented fleet processes.
• Ubuntu 24.04 LTS: registered as an Ubuntu client, LTS systems become visible centrally.
• Rocky Linux 10 and AlmaLinux 10: RHEL-compatible systems are included in the same operations space.
• Oracle Linux 10: channel content is prepared; production use should follow a matching support and repository model.

https://mlm01.example.test/rhn/software/channels/All.do