A SUSE Multi-Linux Manager Proxy is the site component for distributed Linux estates. The central Manager remains the control, reporting and compliance system. The proxy brings package content, bootstrap proximity and Salt communication into a site or separated security zone.

This turns Multi-Linux Manager from a central web interface into a scalable operations architecture: branch offices do not pull all content over WAN, clients can bootstrap locally, and reporting stays centralized.

https://mlm01.example.test

When a proxy makes sense

A proxy is useful for branch offices, DMZ networks, isolated server zones, slow WAN links, many parallel patch runs or strict firewall boundaries. It reduces bandwidth, keeps client traffic local and makes larger rollouts more controlled.

The proxy is not a second Manager. It does not provide independent reporting and it does not replace governance. It is a controlled mediator between clients and parent Manager.

Architecture and naming model

Plan Manager, proxies and clients with stable FQDNs. The validated lab used mlm01.example.test for the Manager. A site proxy can use mlm-proxy-vienna01.example.test. In production these names must resolve before installation.

yaml
manager_fqdn: mlm01.example.test
proxy_fqdn: mlm-proxy-vienna01.example.test
client_example: debian13-client01.example.test
https_port: 443
proxy_ssh_port: 8022
bootstrap_source_for_site_clients: https://mlm-proxy-vienna01.example.test/pub/bootstrap/bootstrap.sh

Check prerequisites

For SUSE Multi-Linux Manager 5.2, the proxy container runs on a supported platform. Current SUSE documentation lists SL Micro 6.2 and SLES 15 SP7 for the container path. You also need time sync, DNS, storage for cache and container data, and firewall rules.

bash
hostnamectl
hostname -f
getent hosts mlm01.example.test
getent hosts mlm-proxy-vienna01.example.test
timedatectl status

Prepare channels

Parent, proxy and client channels must be synchronized before setup. Missing channels later look like installation failures although the real problem is missing content.

bash
spacewalk-repo-sync --channel sle-micro-6.2-pool-x86_64 --type yum --non-interactive
spacewalk-repo-sync --channel suse-multi-linux-manager-proxy-5.2-pool-x86_64 --type yum --non-interactive
spacewalk-repo-sync --channel suse-multi-linux-manager-tools-5.2-pool-x86_64 --type yum --non-interactive

Onboard the proxy host as a client

The proxy host is first onboarded as a normal managed client. Use a dedicated activation key for proxy hosts with the correct base platform and proxy extension.

https://mlm01.example.test
bash
curl -k -o bootstrap.sh https://mlm01.example.test/pub/bootstrap/bootstrap.sh
sudo sh bootstrap.sh
salt 'mlm-proxy-vienna01.example.test' test.ping
salt 'mlm-proxy-vienna01.example.test' grains.item os osrelease fqdn

Generate proxy configuration

The Manager generates the proxy configuration: parent FQDN, proxy FQDN, SSH port, cache size, certificate model, registry source and admin contact. SUSE recommends proxy SSH port 8022. Productive web and client communication uses HTTPS on port 443.

Do not write local browser tunnels, localhost addresses or temporary ports into production configuration. Use the FQDNs that clients, monitoring and certificates will use later.

Install and verify the proxy

Transfer the generated configuration archive to the proxy host. Installation uses the values created by the Manager. Afterwards verify containers, certificates, parent connectivity, cache and Manager visibility.

bash
scp proxy-config.tar.gz root@mlm-proxy-vienna01.example.test:/root/
ssh root@mlm-proxy-vienna01.example.test
mkdir -p /root/proxy-config
tar -xzf /root/proxy-config.tar.gz -C /root/proxy-config
cd /root/proxy-config
mgradm proxy install --help
mgradm status

Attach clients through the proxy

For site clients, create a dedicated activation key and bootstrap script that uses the proxy as contact point. New systems then land in the right site group and use the local proxy.

bash
curl -k -o bootstrap.sh https://mlm-proxy-vienna01.example.test/pub/bootstrap/bootstrap.sh
sudo sh bootstrap.sh
salt 'debian13-client01.example.test' test.ping
salt 'ubuntu2404-client01.example.test' test.ping

Reports and operations view

Operations must show which clients use which proxy. Combine proxy overview, system groups, inventory, inactive systems and patch reports so the proxy remains visible in central operations.

bash
spacewalk-report proxies-overview
spacewalk-report system-groups-systems
spacewalk-report inventory
spacewalk-report inactive-systems
spacewalk-report packages-updates-newest

Acceptance criteria

The proxy is complete when the proxy host is managed, the proxy role is visible, clients bootstrap through it, package and patch data is delivered locally, central reports remain correct and the fallback path is documented.

Common errors

Typical issues are wrong FQDNs, missing DNS records, blocked ports, unsynchronized proxy channels, certificate-chain problems, small cache sizing or a bootstrap script still pointing to the parent Manager.

Proxy cache sizing

Cache size depends on how many products, architectures and patch states the site really needs. A proxy for a few SLES systems needs much less storage than a site that also serves Ubuntu, Debian, Rocky, AlmaLinux and large application packages. Production sizing must include future patch cycles and rollback needs, not only the current package set.

Separate system disk, container data and cache. If the cache fills up, the operating system should not become unstable at the same time. For larger sites we therefore plan dedicated volumes, capacity monitoring and cleanup procedures.

Firewall and communication paths

Between client and proxy, bootstrap, HTTPS and Salt communication must work. Between proxy and parent Manager, synchronization, certificate validation, Salt return path and registry access must be correct. Document these flows as a matrix before requesting firewall rules.

yaml
flows: clients_to_proxy: - https_443 - salt_client_path proxy_to_manager: - https_443 - proxy_ssh_8022 - registry_access operations: - monitoring - backup - log_collection

Certificates and trust chain

Certificates are not decorative in a proxy setup. Clients must trust the proxy, the proxy must trust the parent Manager, and browser access must not rely on temporary exceptions. Enterprise environments decide upfront whether internal PKI or public certificates are used.

After installation, verify more than page loading. Check that bootstrap works without manual certificate exceptions, that the certificate chain is documented, and that renewal or replacement is part of operations.

Operating multiple proxies

With multiple sites, each proxy needs a clear name, its own system group, monitoring rules and preferably dedicated activation keys. That makes it visible later whether a problem affects a site, an operating-system family or the central Manager.

Proxies should not grow as random exceptions. Once they are productive, they belong into backup, monitoring, patch planning, certificate calendar and operations documentation.

Troubleshooting incidents

When a site stops receiving updates, check client to proxy first, then proxy to parent Manager, then content synchronization. This order prevents debugging the central Manager when the actual issue is DNS or a firewall path at the site.

bash
salt 'mlm-proxy-vienna01.example.test' test.ping
curl -vk https://mlm-proxy-vienna01.example.test/pub/bootstrap/bootstrap.sh
curl -vk https://mlm01.example.test/rhn/manager/login
spacewalk-report proxies-overview
spacewalk-report inactive-systems

Step sequence for production implementation

Deployment starts with a decision, not with a command: which systems will use the proxy, which bandwidth is available, which products must be local and who operates the proxy after go-live? Only then do platform, storage, FQDN, certificates and firewall rules follow.

The proxy host is then prepared like a normal server: patch state, time, DNS, monitoring, backup and traceable admin access. A proxy is part of the operations platform and must not become an unmanaged side system.

Next the host is onboarded into the Manager. That lets the Manager inventory the host, verify channels, establish Salt communication and later report on the proxy host itself. This step prevents the proxy from existing outside management.

Then proxy configuration is generated on the parent Manager. These generated values are authoritative. Many production errors happen when FQDNs, certificates or registry paths are modified manually. Therefore the generated configuration is documented, not freely reinterpreted.

Finally, site clients bootstrap through the proxy. Afterwards verify more than a single visible client: groups, patch state, last contact, available updates and central report consistency.

What the proxy improves day to day

Patch runs become more predictable because package content is closer to clients. Network and security teams get clearer communication paths because not every client needs every central connection. Management and operations keep a central view because reports still originate at the parent Manager.

This is especially useful in mixed Linux environments: Debian and Ubuntu clients, RHEL-compatible systems and SUSE systems have different package sources and lifecycles. The proxy does not remove these differences, but it makes delivery and network paths more controlled.

Operations handover

The handover includes FQDNs, certificate lifetimes, cache volume, monitoring, backup, firewall matrix, activation keys, affected system groups, expected clients, report names and a patch-window test plan. Without this, the proxy may be technically installed but operations are not complete.

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.

  1. Install SLES 16 for production
  2. Install SUSE Multi-Linux Manager 5.2 for production
  3. Onboard first Linux clients for production
  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 - this article
  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

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.

https://mlm01.example.test/rhn/manager/schedule/maintenance/calendars
https://mlm01.example.test/rhn/manager/schedule/maintenance/schedules
https://mlm01.example.test/rhn/schedule/PendingActions.do
https://mlm01.example.test/rhn/schedule/CompletedActions.do
https://mlm01.example.test/rhn/schedule/FailedActions.do
  • 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.

TLS acceptance: when proxy-httpd reports CERTIFICATE_VERIFY_FAILED

A running proxy pod is not yet proof that the proxy can trust the parent manager. If proxy-httpd fails with CERTIFICATE_VERIFY_FAILED during startup or configuration, first compare the certificate chain actually presented by the manager with the Root CA uploaded in the proxy form.

The lab showed exactly this failure pattern: uyuni-configure.py could not retrieve the parent manager version via HTTPS although the proxy services had started. The HTTPD_EXTRA_CONF warning was not the root cause; the hard failure was TLS verification.

bash
# on the proxy: show the parent manager certificate chain
openssl s_client -connect mlm01.example.test:443 \
  -servername mlm01.example.test \
  -showcerts </dev/null


# inspect the active manager certificate
openssl s_client -connect mlm01.example.test:443 \
  -servername mlm01.example.test </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -fingerprint -sha256


# compare the uploaded Root CA
openssl x509 \
  -in root-ca-RHN-ORG-TRUSTED-SSL-CERT.pem \
  -noout -subject -issuer -fingerprint -sha256

  • Manager certificate: Subject is the manager FQDN, Issuer is the MLM CA.

  • Proxy certificate: Subject is the proxy FQDN, Issuer is the same trusted CA chain.

  • Root CA in the form: CA that validates the active manager certificate, not just any newly generated proxy certificate.

  • Intermediate CAs: only leave empty when the chain is direct and fully validatable.

This makes CA validation part of the technical acceptance for every proxy rollout: verify the certificate chain first, apply the proxy configuration afterwards, then test container state, ports, Salt connectivity and client registration.

Practice note: changing the manager or proxy FQDN later

Plan the manager and proxy FQDNs before installation and keep them stable. A later change is possible, but it touches more than hostnamectl and DNS. With proxies, Salt, repository URLs, certificates and the proxy container configuration depend on each other.

Important: a successful Salt ping only proves that the minion can reach the master. It does not prove that package sources, proxy configuration, the certificate chain and container services already use the new name.

  • DNS and /etc/hosts must resolve the new manager and proxy names consistently.
  • On the manager, java.hostname, serverURL and bootstrap overrides must point to the production FQDN.
  • On the proxy, /etc/uyuni/proxy/config.yaml, replace_fqdns and server must match.
  • Zypper repositories under /etc/zypp/repos.d/ must not keep old manager URLs.
  • The manager certificate, root CA and proxy certificate must represent the same expected chain and the correct FQDNs.
  • After a failed bootstrap or rename, the manager may show duplicate systems, for example an old Foreign Proxy entry and a new Salt Proxy entry.

Validation after a rename

  • salt <proxy-fqdn> test.ping checks Salt reachability only.
  • salt <proxy-fqdn> pkg.refresh_db additionally checks whether repository URLs and channel access work.
  • mgrpxy status on the proxy shows whether the proxy containers and parent manager are configured correctly.
  • grep -R <old-fqdn> /etc/uyuni /etc/zypp/repos.d /etc/venv-salt-minion helps find leftover references.
  • In the web UI, old incorrectly named proxy entries should be cleaned up before configuring the final proxy again.