Welcome back to 

SUSE Solutions on Azure: The Technical Series

Bridging the Gap Between Linux Freedom and Azure Scale

Architecting enterprise Linux on Azure requires balancing open-source innovation with rigorous corporate control. This series provides the technical blueprints to help you shift from managing individual distributions to building a unified, secure, and resilient Linux stack at any scale.

We had setup the SUSE Mulit-Linux Manger in the last two episodes. With the management foundation established we now shift from deployment to governance.

Part 3: SUSE Multi-Linux Manager onboarding: Best Practices

Understanding SUSE Multi-Linux Manager onboarding within Azure

With the management foundation established (via BYOS Part 1 or PAYG Part2), we now pivot from deployment to governance.

In this installment, we address the fundamental requirement of SUSE Multi-Linux Manager onboarding to ensure a solid foundation before we advance. Although originally slated for a later stage, I have prioritized this topic to ensure a solid foundation before we advance. Consequently, Part 4 will then focus on patch management for CVEs and the automation of security audits via OpenSCAP, enabling you to maintain a hardened and compliant environment across your entire estate.

Key Takeaways: What You Will Accomplish

• Infrastructure Governance: Pivot from deployment to ongoing governance by setting up repository synchronization.
• Credential Management: Understand the critical role of a “Credential Master” instance for PAYG environments to maintain update access.
• Network Requirements: Configure firewall rules for inbound/outbound traffic (Ports 443, 4505, 4506) to ensure the management heartbeat is uninterrupted.
• At-Scale Onboarding: Use Activation Keys and standardized bootstrap scripts to eliminate manual registration bottlenecks.

First a short check of our repositories. 

Managing BYOS client systems

You should have under Admin -> Setup Wizard -> Products the following parts enable (Similar for other version too)

Since you are in a public cloud environment, verify that the “Public Cloud Module” is also selected. Other modules should be tagged automatically if you select the latest version (e.g., SP7).

Click Add Products (X). (The X is the number of selected products and can be different for you)

This initiates the sync process for selected channels and products. If a sync is in progress, you will see a spinning blue circle in the Channels column.

Expanding Your Infrastructure

Managing SUSE PAYG client systems

SUSE PAYG instances embed subscriptions directly into the instance. Consequently, we require a separate source for patches. Navigate to Admin -> Setup Wizard -> PAYG Connections and click Add PAYG Connection.

A configuration page will open. Fill in the required fields to utilize an existing Azure PAYG instance as the source for your PAYG repositories.

Ensure you select the appropriate PAYG instance for your SUSE products (e.g., SLES for SLES instances, SLES for SAP for SLES for SAP instances), verify that the Service Pack (SP) matches and that the instance uses an SSH private key with a passphrase. SMLM requires the private key to perform administrative actions.

Note: This instance will function as your “Credential Master” and must remain powered on.

Additionally, a SUSE Customer Center (SCC) account is required to mirror the core venv-salt-minion onboarding packages. Create an account at scc.suse.com, retrieve your “Organization Credentials,” and enter them under Admin > Setup Wizard > Organization Credentials.

Critical Considerations for SUSE PAYG Connections

There are a few critical “gotchas” before establishing the PAYG connection:

• Protect the Master: The “Credential Master” instance must retain its original Azure-provided registercloudguest packages and cloud certificates. Never run registercloudguest –clean on this instance, nor delete Azure-specific entries from /etc/hosts. Doing so will break credential harvesting.
• Avoid Spot Instances: Do not use spot instances for the Credential Master, as they may be deallocated.
• Network Line-of-Sight: Your SMLM server requires direct inbound/outbound access to the Credential Master instance’s IP on port 22 (SSH). If your SMLM instance resides in another VNet, configure VNet peering.
• SSH Key Authentication: Ensure SSH is permitted in your Azure Network Security Group (NSG) and the private key is secured with a passphrase.

High Availability for Credential Sources

SMLM utilizes a background service (task-o-matic) to refresh harvested Azure credentials every 10 minutes.

• If the Credential Master is stopped or isolated, SMLM uses the last known valid credentials. If the instance remains unreachable for two consecutive refresh cycles (approx. 20 minutes), SMLM marks the credentials as invalid.
• Once invalid, cloud channel synchronization fails, and updates for PAYG clients mapped to those credentials will cease.
• Recommendation: Dedicate a highly available, continuously running, minimally spec’d instance (such as an Azure B-series VM) purely for this heartbeat function.

Open up Network for Management of the clients

To finalize your SMLM 5.1 setup, you must ensure your Azure Network Security Groups (NSGs) allow the “management heartbeat” to flow. Without these, the onboarding scripts later, will install the agent, but the systems will remain “Unreachable” in SMLM.

Remember: Using SMLM requires that the server and target instances can resolve each other’s FQDN via DNS.

Completing your SMLM 5.1 configuration requires adjusting your Azure Network Security Groups (NSGs) to permit the “management heartbeat.” Failing to do so means that while onboarding scripts may install the agent, your systems will be listed as “Unreachable” within SMLM.

DNS Configuration Challenges and Solutions

Best is you have your own DNS zones.

In the absence of a custom DNS setup, Azure provides a default internal DNS. VMs within a single Resource Group typically share a default FQDN format, such as <your-vm-name>.internal.cloudapp.net. However, this implicit Azure DNS is restricted to the boundaries of a single VNet.

• The default DNS is sufficient only if your SMLM server and all managed instances remain within the same VNet indefinitely.
• As your Azure environment grows—incorporating separate Production, DMZ, or Dev VNets connected via VNet Peering—the default DNS will fail to resolve hostnames across these boundaries.
• Linking an Azure Private DNS Zone to multiple VNets ensures seamless communication between your SMLM server and clients across your entire Azure ecosystem.

To avoid unpredictable behavior or failure in SUSE Manager, you must ensure hostnames resolve dynamically in both forward and backward directions.

Recommended Implementation Steps

• Establish an Azure Private DNS Zone: Create a zone using an internal naming convention, such as mlm.azure.local.
• Configure Virtual Network Links: Connect this Private DNS zone to your VNet and enable the auto-registration feature.
• Expected Outcome: As your SMLM server (mlm-server) and clients (vm-client01) initialize, Azure will automatically manage their DNS records (e.g., mlm-server.mlm.azure.local). This fulfills SMLM’s bidirectional FQDN requirements without the need for a dedicated custom DNS server.

Inbound Security Rules

Apply these rules to the NSG protecting your SMLM server to let client heartbeats and management traffic through.

Source	Source Port Ranges	Dest.	Dest.Port Ranges	Port	Action	Prio	Name	Description
IP Addresses or Classless Inter-Domain Routing (CIDR) (Client Fleet Subnet)	*	IP Addresses (SMLM Server Private IP)	443	TCP	Allow	100	AllowSMLM_UI_API	HTTPS for Web UI, API, and package downloads.
IP Addresses or CIDR (Client Fleet Subnet)	*	IP Addresses (SMLM Server Private IP)	4505	TCP	Allow	110	AllowSalt_Pub	Salt Master “Publisher” for client connection tracking.
IP Addresses or CIDR (Client Fleet Subnet)	*	IP Addresses (SMLM Server Private IP)	4506	TCP	Allow	120	AllowSalt_Req	Salt Master “Request Server” for pushing execution actions.

 

Outbound Security Rules

Configure these rules to allow the SMLM server to talk outward to Azure resource wrappers and SUSE patch mirrors.

Source	Source Port Ranges	Dest.	Dest. Port Ranges	Port	Action	Prio	Name	Desc.
IP Addresses (SMLM Server Private IP)	*	Service Tag (AzureResourceManager)	443	TCP	Allow	130	AllowSMLM_Azure_API	Outbound access for VM discovery and automated PAYG validation.
IP Addresses (SMLM Server Private IP)	*	Service Tag (Internet)	443	TCP	Allow	140	AllowSMLM_SCC_Sync	Outbound connection to sync patch channels from SUSE Customer Center.

 

Client Fleet Subnet NSG — Outbound Security Rules

Apply this rule to your managed client workloads

Source	Source Port Ranges	Dest	Dest Port Ranges	Port	Action	Prio	Name	Description
IP Addresses or CIDR (Client Fleet Subnet)	*	IP Addresses (SMLM Server Private IP)	443, 4505,4506	TCP	Allow	100	AllowOutboundToSMLM	Direct outbound lane for client payloads reach the management layer.

Once the infrastructure is up and your SUSE Mulit-Linux Manager software is configured with its FQDN, verify the network layer using this plan:

Test 1: Bidirectional FQDN Resolution (Internal)

Log into your SMLM server via SSH and perform a forward/reverse lookup against a client VM, then repeat the test from the client VM.

From SMLM Server:

host client-vm.mlm.azure.local

# Should return the client's internal Azure IP (e.g., 10.0.2.4)

From a Client VM:

host mlm-server.mlm.azure.local

# Should return the server's internal Azure IP (e.g., 10.0.1.4)

Test 2: Client-to-Server Port Connectivity

Ensure the clients can reach the critical Salt framework ports on the SUSE Manager server. Run this from a client VM:

nc -zv mlm-server.mlm.azure.local 4505
nc -zv mlm-server.mlm.azure.local 4506
nc -zv mlm-server.mlm.azure.local 443

If all connections state Connection to … port [tcp/*] succeeded!, your clients are ready to be bootstrapped.

Strategic Planning for Activation Keys and System Groups

Before you begin registering servers, define your organizational structure.

Bundling servers into System Groups creates administrative economies of scale, particularly when different teams manage specific production environments.

We recommend creating distinct Activation Keys for every combination of distribution, vendor, and architecture. These keys act as the bridge connecting your Azure VMs to their specific environment tiers. Use descriptive labels (e.g., azure-payg-prod-sles15sp7) to clarify OS version, server role, and location.

Why License Separation Matters

You must maintain separate Activation Keys for different licensing models. Applying a BYOS key to a PAYG instance forces the system to pull updates from standard SUSE Customer Center (SCC) channels. Because Azure PAYG instances lack SCC entitlements, these updates will fail, dropping your infrastructure out of compliance.

Key characteristics of Activation Keys:

• Registration Focus: Keys are used only during the initial registration phase; subsequent changes to the client do not affect the key’s original specifications.
• Workflow Dependency: You must generate the Activation Key first, as it must be linked to your Bootstrap methods or scripts in later steps.

Step-by-Step Activation Key Creation

1. Log into the SMLM Web UI
2. Navigate to Systems > Activation Keys.
3. Click Create Key (in the top right corner)
4. Enter a descriptive Description (e.g., Azure PAYG Prod. SLES 15 SP7).
5. Assign a Key name (e.g., azure-payg-prod-SLES15sp7). MLM will prepend your organization number (e.g., 1-azure-payg-prod-SLES15sp7).
6. Leave Usage Limit blank unless you need to restrict VM registration counts.
7. Select the appropriate Base Channel (e.g., your harvested Azure SLES 15 SP7 channel).
8. Click Create Activation Key
9. Navigate to the Groups tab, select your desired system group (e.g., Azure-Production), and click Join Selected Groups for automatic organization.

The Activation Key must be created first because as the next step, the Bootstrap script needs to be linked to it.

1. Log into the SMLM Web UI.
2. Navigate to Systems > Activation Keys.
3. Click Create Key at top right.
4. Enter a highly descriptive Description (e.g., Azure PAYG Prod. SLES 15 SP7 ).
5. Enter a Key name (e.g., azure-payg-prod-SLES15sp7). SMLM will automatically prepend your organization number to it, making the final key 1-azure-payg-prod-SLES15sp7.
6. Leave Usage Limit blank unless you want to restrict how many VMs can use this key.
7. Select your required Base Channel (e.g., your harvested Azure SLES 15 SP5 channel).
8. Click Create Activation Key.
9. Navigate to the Groups tab on the newly created key page.
10. Select a system group (e.g., Azure-Production) to ensure onboarding servers are grouped automatically, then click Join Selected Groups.

Bootstrap the Clients

Before onboarding, categorize your machine inventory. Your management strategy depends on the license model (BYOS vs. PAYG) and the instance state (New vs. Existing).

Case	License Model	Lifecycle State	Channel Source	Onboarding Artifact	Key Used
1	BYOS	New (Provisioning)	SCC	YAML (Cloud-Init)	1-byos-key
2	BYOS	Running (SCC)	SCC	Shell (Standard)	1-byos-key
3	BYOS	Running (Cloud-Repo)	SCC	Shell (Standard)	1-byos-key
4	PAYG	New (Provisioning)	HarvestedCloud Repo	YAML (Cloud-Init)	1-payg-key
5	PAYG	Running (Cloud-Repo)	HarvestedCloud Repo	Shell (Standard)	1-payg-key
6	CentOS BYOS	Running (Live)	SUSE Liberty	Shell (Liberty)	1-liberty-key

There are several methods for bootstrap clients

• Register With the Web UI
  • Which is good for onboarding several clients
• Register With a Bootstrap Script
  • Similar but from CLI
• Use the API
  • Need to create own tools. Good for programmatic onboard several clients
• Register on the Command Line
  • The way to mass onboard clients

Scalability and Security Considerations

UI and API-based onboarding rely on a server-driven “push” architecture that requires opening inbound SSH ports into production subnets—a significant security risk. Native bootstrap scripts also create performance bottlenecks, as concurrently booting VMs hitting the central server simultaneously can trigger resource queuing.

We recommend the CLI/File-Based Method. It utilizes a decentralized, client-driven “pull” architecture (via Cloud-Init or Custom Data) where VMs configure themselves independently. This maintains a zero-trust security posture, requires only outbound traffic (Ports 443, 4505, 4506), and integrates natively with automation tools like Terraform.

The Mechanical Sequence

Every system executes this uniform sequence to ensure a clean hand-off from native cloud management to SMLM governance:

1. Establish Trust: Dynamically fetch the SMLM Root CA and inject it into the local trust store.
2. Secure Download: Retrieve the “venv-salt-minion” package using system-trusted stores.
3. Clean & Archive: Unregister native cloud billing paths and archive existing repository files.
4. Local Configuration: Inscribe the SMLM Master FQDN and Activation Key directly to disk.
5. Enrollment: Launch the management heartbeat to initiate the outbound connection

Deployment Methods: How to Execute

You do not need to maintain separate YAML (for cloud-init) and Bash files. If you feed the Azure “Custom Data” or “User Data” field a script that begins with a standard shebang (#!/bin/bash), cloud-init automatically recognizes it as a shell script, writes it to disk, and executes it during the first boot phase

Scenario A: Deploying New VMs (Terraform / Azure Portal)

1. Navigate to the Azure Portal VM creation wizard.
2. Locate the Advanced tab.
3. Paste the full onboarding script into the Custom Data field.
4. The VM will auto-register and appear in your SMLM console approximately 3 minutes after booting.

Scenario B: Onboarding Running VMs

You can run the script without logging into each machine individually using the Azure Run Command feature:

1. Navigate to your VM in the Azure Portal.
2. Go to Operations > Run Command > RunShellScript.
3. Paste the script and click Run.

Alternatively, via CLI/SSH:

1. scp onboarding.sh azureuser@<sles_instance>:/tmp/
2. ssh azureuser@<sles_instance> “sudo bash /tmp/onboarding.sh”

Scenario C: Mass Onboarding (Azure CLI)

For large fleets, leverage the Azure CLI to loop the Run Command across a specific Resource Group or list of VMs, pushing the script execution programmatically.

The script installs the agent and configures the connection silently. Note that for PAYG, we add the “cleanup” commands to ensure Azure native services don’t interfere.

The Onboarding Blueprint Example Script

Adapt the SMLM_HOST, ACTIVATION_KEY, and PACKAGE variables below to match your specific SMLM version and installation path found at https://<your-smlm-server>/pub/repositories/

#!/bin/bash
#==================================================================
# Example SMLM Onboarding Blueprint: Multi-Linux Client Enrollment
#==================================================================
set -e # Terminate execution upon any command failure

# Check: Automatically elevate if run manually by standard user
if [ "$EUID" -ne 0 ]; then
   echo "==> Admin privileges required. Elevating via sudo..."
   exec sudo "$0" "$@"
fi

# --- CORE ARCHITECTURAL VARIABLES
SMLM_HOST="your-smlm-server.domain.internal"
ACTIVATION_KEY="1-your-activation-key-here"

# --- CONFIGURABLE OS ENDPOINT 
# Uncomment only ONE pair matching your target OS
# You get this from https:///pub/repositories/

# SLES Blueprint:
PACKAGE="sle/15/7/bootstrap/x86_64/venv-salt-minion-3006.0-150002.5.12.2.x86_64.rpm"
LOCAL_FILE="/tmp/venv-salt-minion.rpm"

# CentOS/Liberty Blueprint:
#PACKAGE="centos/8/bootstrap/x86_64/venv-salt-minion-3006.0-80002.5.12.3.x86_64.rpm"
#LOCAL_FILE="/tmp/venv-salt-minion.rpm"

# Ubuntu Blueprint:
#PACKAGE="ubuntu/24/4/bootstrap/pool/main/v/venv-salt-minion/venv-salt-minion_3006.0-240402.3.18.1_amd64.deb"
#LOCAL_FILE="/tmp/venv-salt-minion.deb"

# =================================================================
# CORE EXECUTION LAYER, normally no change needed below this line
# =================================================================

# Multi-distro package helper
install_package() {
    if command -v zypper &>/dev/null; then zypper --non-interactive install "$1"
    elif command -v dnf &>/dev/null;  then dnf install -y "$1"
    elif command -v yum &>/dev/null;  then yum localinstall -y "$1"
    elif command -v dpkg &>/dev/null; then dpkg -i "$1" || apt-get install -f -y
    else echo "ERROR: No supported package manager found" >&2; exit 1; fi
}

echo "==> Step 1: Provisioning management configuration..."
mkdir -p /etc/venv-salt-minion/minion.d
cat << EOF > /etc/venv-salt-minion/minion.d/susemanager.conf
master: ${SMLM_HOST}

grains:
  susemanager:
    activation_key: "${ACTIVATION_KEY}"

server_id_use_crc: adler32
enable_legacy_startup_events: False
enable_fqdns_grains: False
EOF

echo "==> Step 2: Integrating SMLM Root CA into local trust stores..."
mkdir -p /usr/share/pki/trust/anchors/ /etc/pki/ca-trust/source/anchors/ /usr/local/share/ca-certificates/
curl -kfsL "https://${SMLM_HOST}/pub/RHN-ORG-TRUSTED-SSL-CERT" -o /tmp/smlm-ca.crt

# Drop the certificate into all possible OS directories safely
cp /tmp/smlm-ca.crt /usr/share/pki/trust/anchors/smlm-ca.crt 2>/dev/null || true
cp /tmp/smlm-ca.crt /etc/pki/ca-trust/source/anchors/smlm-ca.crt 2>/dev/null || true
cp /tmp/smlm-ca.crt /usr/local/share/ca-certificates/smlm-ca.crt 2>/dev/null || true

# Rebuild trust keychains if the respective tools exist
command -v update-ca-certificates &>/dev/null && update-ca-certificates || true
command -v update-ca-trust        &>/dev/null && update-ca-trust        || true

echo "==> Step 3: Retrieving management engine installation bundle..."
curl -fsL "https://${SMLM_HOST}/pub/repositories/$PACKAGE" -o "$LOCAL_FILE"
test -s "$LOCAL_FILE" || { echo "ERROR: Retrieval of package failed. Check your VERSION string or network paths." >&2; exit 1; }

echo "==> Step 4: Initializing local agent installation..."
install_package "$LOCAL_FILE"

echo "==> Step 5: Decommissioning native paths & isolating old repos..."
if [ -f /usr/sbin/registercloudguest ]; then
   registercloudguest --clean
   systemctl disable --now guestregister.service
fi

# dumb Multi-OS Repository Backup: Flat and non-destructive
mkdir -p /etc/zypp/repos.d/backup-old/ /etc/yum.repos.d/backup-old/ /etc/apt/sources.list.d/backup-old/
# SUSE user repos
mv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/backup-old/ 2>/dev/null || true
# RH
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup-old/ 2>/dev/null || true
# DEB
[ -f /etc/apt/sources.list ] && mv /etc/apt/sources.list /etc/apt/sources.list.backup 2>/dev/null || true
for r in /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources; do 
    [ -f "$r" ] && mv "$r" /etc/apt/sources.list.d/backup-old/
done 2>/dev/null || true

echo "==> Step 6: Launching management heartbeat service..."
systemctl enable --now venv-salt-minion || systemctl enable --now salt-minion

echo "[SUCCESS] Client lifecycle onboarding executed successfully."

Cloud-Native Decommissioning details: SLES vs. CentOS vs. Ubuntu

When taking control of package management via SUSE Multi-Linux Manager, you must cleanly detach the VM from other update infrastructures. Below you find how the script achieves this for each operating system:

• SUSE Linux Enterprise Server (SLES): Azure SLES PAYG images use a background daemon (guestregister.service) and billing tools to dynamically check in with Azure’s local SMT/RMT patch mirrors. Step 5 explicitly executes registercloudguest –clean to scrub these assignments and disables the timer so it never turns back on. It only removes the specific enterprise repository channels managed by the cloud-regionsrv-client plugin. It does not aggressively sweep or clean up the entire /etc/zypp/repos.d/ directory.
• CentOS / RHEL and variants: Azure Red Hat family images connect to the Azure RHUI (Red Hat Update Infrastructure) mirrors. They do not use a continuous background daemon like SLES. Instead, they rely purely on the configuration files located inside /etc/yum.repos.d/ (such as rh-cloud.repo).
  • Because they are file-based, the flat repository backup loop in Step 5 (mv /etc/yum.repos.d/*.repo …) is 100% sufficient to safely sever the native Azure RHUI connection and hand package authority completely to SMLM.
• Ubuntu Server: Azure Ubuntu instances pull updates from regional, Azure-hosted Canonical mirrors mapped inside standard text configuration structures. Like CentOS, Ubuntu does not utilize a cloud guest-registration daemon.
  • Moving /etc/apt/sources.list and archiving the contents of /etc/apt/sources.list.d/ directly into the backup-old/ folder cleanly isolates the machine from Canonical’s mirrors, leaving SMLM as the sole source of truth for updates.

Summary Checklist

You have established the governance framework required for enterprise-scale Linux management on Azure.

Here, as recap, the steps you had done:

• Repository Governance: Configured SMLM repository synchronization endpoints for both BYOS (Public Cloud Module) and PAYG (using the dedicated “Credential Master” architecture).
• Network Hardening: Implemented the required Azure NSG security rules (443, 4505, 4506) to ensure secure, uninterrupted management heartbeats across all subnets.
• Identity & Compliance: Defined a distinct activation key strategy that enforces licensing compliance (BYOS/PAYG) across your distribution fleet.
• Automated Onboarding: Deployed the standardized bootstrap methodology, effectively severing native cloud update dependencies and handing lifecycle authority to SMLM.

Outlook: What’s Next?

Part 4: Proactive Patch Management & Compliance

Now that your infrastructure is fully governed and your clients are reporting back to SMLM, the real work of system administration begins. In our next installment, we will shift focus from onboarding to maintenance. We will cover how to automate CVE patch management across your fleet and how to utilize OpenSCAP to perform automated security audits, ensuring your environment remains compliant and hardened against vulnerabilities at scale.