SUSE Multi-Linux Manager 5.2: Proxies für Standorte und verteilte Linux-Flotten aufbauen

Ein SUSE Multi-Linux Manager Proxy ist der Baustein für verteilte Linux-Flotten. Der zentrale Manager bleibt Steuerungs-, Reporting- und Compliance-System. Der Proxy bringt Paketcontent, Bootstrap-Nähe und Salt-Kommunikation in den Standort oder in eine getrennte Sicherheitszone.

Damit wird Multi-Linux Manager nicht nur zu einem zentralen Webinterface, sondern zu einer skalierbaren Betriebsarchitektur: Außenstellen müssen nicht jede Paketquelle direkt über WAN erreichen, Clients können lokal gebootstrappt werden, und Reporting bleibt trotzdem zentral.

https://mlm01.lab.example

Kompletter Ablauf der Serie

Diese Reihe führt dich Schritt für Schritt durch den produktiven Aufbau: 1. SLES 16 produktiv installieren · 2. SUSE Multi-Linux Manager 5.2 installieren · 3. Erste Linux-Clients onboarden · 4. Patch- und Lifecycle-Management · 5. Mixed Linux verwalten · 6. OpenSCAP, Compliance und Audit · 7. Proxies für Standorte aufbauen · 8. SSO mit Keycloak integrieren · 9. Ansible neben Salt nutzen · 10. Reporting, Inventar und Audit · 11. Produktiv betreiben und härten

Wann ein Proxy sinnvoll ist

Ein Proxy ist sinnvoll bei mehreren Standorten, DMZ-Netzen, isolierten Serverzonen, langsamen WAN-Strecken, vielen parallelen Patchläufen oder klaren Firewall-Grenzen. Er reduziert Bandbreite, hält Client-Verkehr lokal und macht große Rollouts kontrollierbarer.

Der Proxy ist kein zweiter Manager. Er besitzt kein eigenständiges fachliches Reporting und ersetzt keine zentrale Governance. Er vermittelt kontrolliert zwischen Clients und Parent Manager.

Architektur und Namensmodell

Plane Manager, Proxies und Clients mit stabilen FQDNs. Im validierten Lab wurde der Manager als mlm01.lab.example betrieben. Für einen Standort-Proxy verwenden wir beispielsweise mlm-proxy-vienna01.lab.example. In produktiven Umgebungen müssen diese Namen vor der Installation per DNS auflösbar sein.

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

Voraussetzungen prüfen

Für SUSE Multi-Linux Manager 5.2 wird der Proxy-Container auf einer unterstützten Plattform betrieben. In der aktuellen SUSE-Dokumentation sind SL Micro 6.2 und SLES 15 SP7 die relevanten Plattformen für den Containerpfad. Zusätzlich brauchst du Zeitsynchronisation, korrekte Namensauflösung, ausreichend Speicher für Cache und Containerdaten sowie passende Firewall-Regeln.

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

Kanäle vorbereiten

Vor dem Proxy-Setup müssen Parent-, Proxy- und Client-Channels synchronisiert sein. Fehlen diese Kanäle, sieht der Fehler später wie ein Installationsproblem aus, obwohl eigentlich Content fehlt.

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

Proxy-Host als Client aufnehmen

Der Proxy-Host wird zuerst als normaler verwalteter Client aufgenommen. Dafür verwendest du einen eigenen Activation Key für Proxy-Hosts. Dieser Key bekommt die passende Basisplattform und die Proxy Extension, nicht die gleichen Einstellungen wie normale Anwendungsserver.

https://mlm01.lab.example

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

Proxy-Konfiguration erzeugen

Die Proxy-Konfiguration wird am Manager erzeugt. Dort werden Parent FQDN, Proxy FQDN, SSH-Port, Cachegröße, Zertifikatsmodell, Registry-Quelle und Admin-Kontakt festgelegt. Der von SUSE empfohlene Proxy-SSH-Port ist 8022. Die produktive Web- und Client-Kommunikation läuft über HTTPS auf Port 443.

Achte darauf, keine lokalen Browser-Tunnel, localhost-Adressen oder temporären Ports in die Konfiguration zu schreiben. Der Proxy muss mit den FQDNs funktionieren, die später auch Clients, Monitoring und Zertifikate verwenden.

Proxy installieren und prüfen

Nach dem Erzeugen wird das Konfigurationsarchiv auf den Proxy-Host übertragen. Die Installation verwendet die vom Manager erzeugten Werte. Nach der Installation prüfst du Containerstatus, Zertifikate, Parent-Verbindung, Cache und die Sichtbarkeit des Proxys im Manager.

scp proxy-config.tar.gz root@mlm-proxy-vienna01.lab.example:/root/
ssh root@mlm-proxy-vienna01.lab.example
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

Clients über den Proxy anbinden

Für Standort-Clients erzeugst du einen eigenen Activation Key und ein Bootstrap-Script, das den Proxy als Kontaktpunkt nutzt. Neue Systeme landen dadurch direkt in der richtigen Standortgruppe und verwenden den lokalen Proxy statt des zentralen Managers.

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

Reports und Betriebssicht

Im Betrieb muss sichtbar sein, welche Clients über welchen Proxy laufen. Dafür kombinierst du Proxy-Übersicht, Systemgruppen, Inventory, inaktive Systeme und Patchreports. So wird aus dem Proxy keine Blackbox, sondern ein nachvollziehbarer Standortbaustein.

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

Abnahmekriterien

Der Proxy ist erst fertig, wenn der Proxy-Host selbst verwaltet ist, die Proxy-Rolle im Manager sichtbar ist, Clients über den Proxy gebootstrappt werden können, Patch- und Paketdaten lokal ausgeliefert werden, Reports weiterhin zentral stimmen und ein Ausfallpfad dokumentiert ist.

Häufige Fehler

Typische Fehler sind falsche FQDNs, fehlende DNS-Einträge, blockierte Ports, nicht synchronisierte Proxy-Channels, eine falsche Zertifikatskette, zu kleiner Cache oder ein Bootstrap-Script, das noch auf den Parent Manager zeigt.

Dimensionierung des Proxy-Caches

Die Cachegröße hängt davon ab, wie viele Produkte, Architekturen und Patchstände der Standort wirklich braucht. Ein Proxy für wenige SLES-Systeme braucht deutlich weniger Speicher als ein Standort, der zusätzlich Ubuntu, Debian, Rocky, AlmaLinux und große Applikationspakete hält. Für produktive Planung rechnest du nicht nur mit dem heutigen Paketbestand, sondern mit mehreren Patchzyklen und Rollback-Bedarf.

Wichtig ist außerdem die Trennung von Systemdisk, Containerdaten und Cache. Wenn der Cache voll läuft, soll nicht gleichzeitig das Betriebssystem instabil werden. Für größere Standorte planen wir deshalb eigene Volumes, Monitoring auf Füllstand und klare Aufräumprozesse.

Firewall und Kommunikationswege

Zwischen Client und Proxy müssen Bootstrap, HTTPS und Salt-Kommunikation funktionieren. Zwischen Proxy und Parent Manager müssen Synchronisation, Zertifikatsprüfung, Salt-Rückkanal und Registry-Zugriff passen. Dokumentiere diese Flüsse als Matrix, bevor du Firewall-Regeln beantragst.

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

Zertifikate und Vertrauenskette

Zertifikate sind beim Proxy nicht Dekoration, sondern Betriebsgrundlage. Clients müssen dem Proxy vertrauen, der Proxy muss dem Parent Manager vertrauen, und Browserzugriffe dürfen nicht auf temporäre Zertifikatsausnahmen angewiesen sein. In Enterprise-Umgebungen wird vorab entschieden, ob die interne PKI oder ein öffentliches Zertifikat genutzt wird.

Nach der Installation prüfen wir deshalb nicht nur, ob die Oberfläche lädt. Wir prüfen, ob Bootstrap ohne manuelle Zertifikatsausnahme funktioniert, ob die Zertifikatskette dokumentiert ist und ob Verlängerung beziehungsweise Austausch des Zertifikats in den Betriebsprozess passt.

Mehrere Proxies betreiben

Bei mehreren Standorten bekommt jeder Proxy einen klaren Namen, eine eigene Systemgruppe, eigene Monitoring-Regeln und möglichst eigene Activation Keys. Dadurch bleibt später erkennbar, ob ein Problem einen Standort, eine Betriebssystemfamilie oder den zentralen Manager betrifft.

Proxies sollten nicht als zufällige Ausnahme wachsen. Sobald sie produktiv eingesetzt werden, gehören sie in Backup, Monitoring, Patchplanung, Zertifikatskalender und Betriebshandbuch.

Troubleshooting im Störfall

Wenn ein Standort keine Updates bekommt, prüfst du zuerst den Client gegen den Proxy, dann den Proxy gegen den Parent Manager und zuletzt die Content-Synchronisation. Diese Reihenfolge verhindert, dass man sofort am zentralen Manager sucht, obwohl nur DNS oder ein Firewall-Pfad am Standort fehlerhaft ist.

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

Schrittfolge für produktive Umsetzung

Der Aufbau beginnt mit einer Entscheidung, nicht mit einem Befehl: Welche Systeme sollen über den Proxy laufen, welche Bandbreite steht zur Verfügung, welche Produkte müssen lokal verfügbar sein und wer betreibt den Proxy nach dem Go-live? Erst danach werden Plattform, Storage, FQDN, Zertifikate und Firewall-Regeln umgesetzt.

Im zweiten Schritt wird der Proxy-Host wie ein normaler Server vorbereitet. Dazu gehören Patchstand, Zeit, DNS, Monitoring, Backup und ein nachvollziehbarer Admin-Zugang. Ein Proxy ist Teil der Betriebsplattform und darf nicht als ungepflegte Nebeninstanz laufen.

Im dritten Schritt wird der Host in den Manager aufgenommen. Dadurch kann der Manager den Host inventarisieren, Channel-Zuordnung prüfen, Salt-Kommunikation herstellen und später Reports über den Proxy-Host ausgeben. Dieser Zwischenschritt ist wichtig, weil der Proxy dadurch nicht außerhalb des Managements entsteht.

Im vierten Schritt wird die Proxy-Konfiguration am Parent Manager erzeugt. Die dort generierten Werte sind maßgeblich. Genau hier entstehen oft Fehler, wenn FQDNs, Zertifikate oder Registry-Pfade manuell verändert werden. In produktiven Projekten wird die erzeugte Konfiguration deshalb dokumentiert und nicht frei interpretiert.

Im fünften Schritt werden Standort-Clients über den Proxy gebootstrappt. Danach prüfst du nicht nur, ob ein einzelner Client sichtbar ist. Du prüfst Gruppen, Patchstatus, letzte Kontaktzeit, verfügbare Updates und ob Reports weiterhin zentral konsistent sind.

Was der Proxy im Alltag verbessert

Für Administratoren wird der Patchlauf planbarer, weil Paketcontent näher an den Clients liegt. Für Netzwerk- und Security-Teams wird die Kommunikation verständlicher, weil nicht jeder Client direkt jede zentrale Verbindung braucht. Für Management und Betrieb bleibt die Sicht zentral, weil Reports weiterhin am Parent Manager entstehen.

Gerade in Multi-Linux-Umgebungen ist das hilfreich: Debian- und Ubuntu-Clients, RHEL-kompatible Systeme und SUSE-Systeme haben unterschiedliche Paketquellen und Lifecycles. Der Proxy ändert diese Unterschiede nicht, aber er macht die Auslieferung und den Netzwerkpfad kontrollierbarer.

Betriebsübergabe

Zur Übergabe gehören FQDNs, Zertifikatslaufzeiten, Cache-Volume, Monitoring, Backup, Firewall-Matrix, Activation Keys, betroffene Systemgruppen, erwartete Clients, Reportnamen und ein Testplan für Patchfenster. Ohne diese Informationen ist ein Proxy zwar technisch installiert, aber betrieblich nicht abgeschlossen.