SUSE Manager Production Guide

SUSE Manager (rebranded as SUSE Multi-Linux Manager starting with version 5.1) is an enterprise systems management solution for large-scale Linux infrastructure. It provides patch management, configuration management, compliance auditing, and system provisioning from a single web-based console. Built on the Uyuni open-source upstream (which itself descends from Spacewalk), SUSE Manager adds enterprise support, certified content, and tight integration with the SUSE Linux Enterprise ecosystem. Starting with version 5.0, both the server and proxy are delivered as containers managed by mgradm and mgrpxy tools respectively.

Organizations use SUSE Manager to manage hundreds or thousands of Linux systems across datacenters, cloud environments, and edge locations. It supports SUSE Linux Enterprise Server (SLES), SUSE Linux Micro, RHEL, CentOS, Ubuntu, Debian, Rocky Linux, AlmaLinux, Oracle Linux, Amazon Linux, and openSUSE — making it a viable single-pane-of-glass for heterogeneous Linux estates.

Core capabilities

• Patch management — Centralized errata and package updates across all managed systems with scheduled maintenance windows
• Configuration management — Deploy configuration files, Salt states, and formulas to groups of systems
• Compliance auditing — OpenSCAP integration for security benchmarks (CIS, DISA STIG) with automated scanning and reporting
• System provisioning — Bare-metal and VM provisioning with AutoYaST, Kickstart, and PXE boot support
• Content lifecycle management — Promote patches through dev/test/prod environments before production deployment
• CVE auditing — Track which systems are affected by specific CVEs and their patch status

SUSE Manager follows a hub-and-spoke architecture. The central SUSE Manager Server handles all management operations, content synchronization, and the web interface. Proxy nodes extend reach to remote sites. Managed systems run the Salt minion agent (or legacy traditional client) and connect to the server or a proxy.

Core components

• SUSE Manager Server — The central management host. Runs the web UI (Java/Tomcat), API layer, task scheduler (Taskomatic), and Salt master. As of version 5.0, delivered as containers running on SL Micro 5.5 or SLES 15 SP6+ as the host OS, managed via the mgradm tool.
• PostgreSQL database — Stores system inventory, patch data, channel metadata, audit logs, and scheduling information. This is the single most critical data store.
• Salt master — Embedded in the server. All Salt minion communication flows through this. Uses ZeroMQ for transport by default.
• Taskomatic — Java-based task scheduler that handles channel sync, errata cache updates, report generation, and recurring jobs.
• Proxy servers — Lightweight caching proxies for remote sites. Cache packages and act as Salt broker. In version 5.0+, proxies are containerized and managed via the mgrpxy tool (running on Podman or K3s).
• Salt minions — Agents on managed systems. Lightweight, persistent connection to Salt master via ZeroMQ.

Hardware requirements

Content Lifecycle Management (CLM) is SUSE Manager's mechanism for controlling how patches and packages flow from vendor repositories to production systems. Instead of applying vendor updates directly, CLM lets you create filtered snapshots of content and promote them through a sequence of environments.

Key concepts

• Content project — A named project that defines which source channels to include, what filters to apply, and which environments to promote through
• Source channels — The upstream vendor channels (e.g., SLES 15 SP5 Pool, SLES 15 SP5 Updates) that feed into the project
• Filters — Rules that include or exclude specific patches, packages, or errata types (security, bugfix, enhancement). Filters can match by name, CVE ID, advisory type, or date
• Environments — Ordered stages (e.g., dev → test → prod) that represent points in your release pipeline. Each environment gets its own set of cloned channels
• Build & Promote — Building a project creates a snapshot. Promoting moves that snapshot to the next environment

Typical workflow

# Using the SUMA API to build and promote content projects
# Build the project (creates snapshot in first environment)
spacecmd -- contentmanagement_build "sles15sp5-standard"

# Promote from DEV to TEST
spacecmd -- contentmanagement_promote "sles15sp5-standard" "dev"

# Promote from TEST to PROD
spacecmd -- contentmanagement_promote "sles15sp5-standard" "test"

# List all content projects
spacecmd -- contentmanagement_listprojects

Patch management is the primary reason most organizations deploy SUSE Manager. The system tracks errata (vendor advisories) across all managed systems, shows which systems are affected by which CVEs, and provides scheduling and approval workflows for applying patches at scale.

How patching works

1. Channel sync — Taskomatic periodically syncs vendor channels from SUSE Customer Center (SCC). New errata and packages are downloaded and cached locally.
2. Errata cache update — After sync, Taskomatic recalculates which systems need which patches based on their installed package versions.
3. Dashboard visibility — The web UI shows patch counts per system, per group, and per severity (critical, important, moderate, low).
4. Scheduling — Administrators schedule patch actions for individual systems, groups, or via recurring actions. Patches can be applied immediately or during defined maintenance windows.
5. Execution — The Salt master sends patch commands to minions. Minions execute zypper patch (SLES) or dnf update / yum update (RHEL/CentOS — dnf on RHEL 8+, yum on RHEL 7) and report results back.
6. Reporting — Success/failure status is recorded per system. Failed patches can be retried or investigated.

CVE auditing

SUSE Manager includes a dedicated CVE Audit page. Given a CVE ID (e.g., CVE-2024-1234), it shows every managed system and its status:

Maintenance windows

SUSE Manager supports maintenance schedules that restrict when patches can be applied to a system. This is critical for production environments where patching must happen during approved change windows.

# Create a maintenance schedule via API
spacecmd -- schedule_create "prod-patch-window" \
  --start "2026-03-21 22:00" \
  --end "2026-03-22 04:00" \
  --recurrence "monthly"

# Assign systems to maintenance window
spacecmd -- system_setmaintenanceschedule server01.example.com "prod-patch-window"
spacecmd -- system_setmaintenanceschedule server02.example.com "prod-patch-window"

SUSE Manager uses Salt as its core management backend. Every managed system runs a Salt minion that maintains a persistent connection to the Salt master embedded in the SUSE Manager server. This architecture enables real-time command execution, event-driven automation, and declarative configuration management.

Salt concepts in SUSE Manager

• States — Declarative YAML files that describe the desired state of a system (packages installed, services running, files present). SUSE Manager can apply Salt states to systems and groups.
• Grains — Static data about a minion (OS, CPU, memory, network). SUSE Manager uses grains for hardware/software inventory and system grouping.
• Pillars — Confidential or system-specific data (passwords, configuration values) that is delivered only to the targeted minion. Stored on the Salt master.
• Formulas — Parameterized Salt states that can be configured through the SUSE Manager web UI. SUSE provides a catalog of pre-built formulas (monitoring, DHCP, BIND, etc.).
• Remote execution — Run arbitrary Salt commands on one or many systems in real time. Equivalent to salt '*' cmd.run 'uptime' but through the web UI.

Salt vs. Traditional management

# Example Salt state managed through SUSE Manager
# /srv/salt/webserver/init.sls

apache_installed:
  pkg.installed:
    - name: apache2

apache_running:
  service.running:
    - name: apache2
    - enable: True
    - require:
      - pkg: apache_installed

apache_config:
  file.managed:
    - name: /etc/apache2/httpd.conf
    - source: salt://webserver/files/httpd.conf
    - user: root
    - group: root
    - mode: 644
    - watch_in:
      - service: apache_running

Registering (or "bootstrapping") systems into SUSE Manager is the first step in managing them. SUSE Manager supports multiple registration methods, with the bootstrap script being the most common for Salt minions.

Registration methods

• Web UI bootstrap — Enter the system's hostname/IP in the SUSE Manager UI. The server pushes Salt minion installation and configuration via SSH.
• Bootstrap script — Generate a shell script from SUSE Manager, copy it to the target system, and run it. The script installs the Salt minion, configures it to point to the SUSE Manager server, and registers the system.
• Manual Salt minion install — Install salt-minion manually, point it at the SUSE Manager server in /etc/salt/minion.d/susemanager.conf, and accept the key on the server.
• AutoYaST / Kickstart — Include registration in the automated installation profile for new system deployments.

Activation keys

Activation keys are the mechanism for assigning channels, configuration, and entitlements to systems at registration time. Every system should be registered with an activation key.

# Generate and run bootstrap script
# On SUSE Manager server:
mgr-bootstrap --activation-keys=1-sles15sp5-prod \
  --hostname=suma-server.example.com \
  --ssl-cert=/srv/www/htdocs/pub/RHN-ORG-TRUSTED-SSL-CERT

# On target system:
curl -Sks https://suma-server.example.com/pub/bootstrap/bootstrap.sh | bash

# Or via the API:
spacecmd -- system_bootstrap -H client01.example.com \
  -u root -a 1-sles15sp5-prod

System groups

System groups organize managed systems by function, location, or environment. Groups are used for targeting patch actions, applying Salt states, generating reports, and delegating management to team-specific administrators.

SUSE Manager Proxy is a lightweight component deployed at remote sites, in DMZs, or at branch offices. It caches packages locally, brokers Salt communication, and reduces bandwidth consumption between remote sites and the central SUSE Manager server.

When to use a proxy

• Remote sites with WAN links — Avoid pulling the same package over a slow link for every system. The proxy caches it locally after the first download.
• DMZ deployments — Place a proxy in the DMZ so managed systems never need direct access to the internal SUSE Manager server.
• Branch offices — Each branch gets its own proxy, reducing central bandwidth and improving patch install speed.
• Scale-out — Distribute Salt minion connections across proxies to reduce load on the central Salt master.

Proxy architecture

# SUSE Manager 5.0+ (containerized proxy with mgrpxy)
# 1. Install SL Micro 5.5 or SLES 15 SP6+ on the proxy host
# 2. Install mgrpxy tool
# 3. Deploy containerized proxy
mgrpxy install podman proxy01.example.com

# Legacy (SUSE Manager 4.3 and earlier):
# 1. Register the system as a regular Salt minion first
# 2. Install proxy pattern
zypper in -t pattern suma_proxy
# 3. Run proxy setup
configure-proxy.sh --host=proxy01.example.com \
  --suma-server=suma-server.example.com \
  --ssl-city="Frankfurt" \
  --ssl-country="DE" \
  --ssl-org="ACME Corp" \
  --ssl-email="admin@example.com"
# 4. Activate the proxy in SUSE Manager UI
#    Systems -> proxy01 -> Details -> Proxy -> Activate

SUSE Manager provides configuration management through two mechanisms: Salt states (for Salt-managed systems) and configuration channels (legacy, for traditional clients). For all new deployments, Salt states and formulas are the recommended approach.

Salt states management

Salt states are YAML files that declare the desired state of a system. SUSE Manager can store, version, and deploy states to individual systems or groups.

• State catalog — Browse and assign states from the SUSE Manager UI under Configuration → Salt States
• Highstate — Apply all assigned states to a system. Can be run on-demand or scheduled.
• Custom states — Place custom .sls files in /srv/salt/ on the SUSE Manager server. They appear in the UI automatically.
• Git integration — Use a gitfs backend to pull Salt states from a Git repository, enabling version control and CI/CD workflows.

Formulas

Formulas are parameterized Salt states with a form-based UI for configuration. SUSE provides a growing catalog of pre-built formulas:

# Example formula form.yml
# /usr/share/susemanager/formulas/myapp/form.yml
myapp:
  $type: group
  app_port:
    $type: number
    $default: 8080
    $help: "Port the application listens on"
  enable_ssl:
    $type: boolean
    $default: true
  allowed_hosts:
    $type: edit-group
    $itemtype: text
    $help: "List of allowed hostnames"

SUSE Manager provides built-in reporting capabilities and integrates with external monitoring stacks for infrastructure observability.

Prometheus integration

SUSE Manager includes the Prometheus monitoring formula that deploys and configures the Prometheus node exporter on managed systems. The formula can also configure the Prometheus server's scrape targets, creating a fully automated monitoring pipeline.

• Deploy prometheus-node_exporter to all systems via formula
• Auto-generate Prometheus scrape configuration based on system groups
• Pre-built Grafana dashboards for SUSE Manager system inventory
• Alert on patch compliance, system health, and Salt minion connectivity

Built-in reports

OpenSCAP integration

SUSE Manager can schedule OpenSCAP scans on managed systems and store the results centrally. This provides automated compliance checking against industry benchmarks.

# Schedule OpenSCAP scan via SUSE Manager
# Using spacecmd:
spacecmd -- system_runscap server01.example.com \
  --profile "ssg-sle15-ds.xml" \
  --content "/usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml" \
  --tailoring-id "xccdf_org.ssgproject.content_profile_cis"

# Results are viewable in:
# Systems -> server01 -> Audit -> OpenSCAP -> Scan Results

Understanding the licensing model is critical for budgeting and architecture decisions. SUSE Manager is a commercial product with an open-source upstream (Uyuni).

SUSE Manager vs. Uyuni

Subscription model

Use this checklist when scoping, deploying, or auditing a SUSE Manager environment.