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.example.test

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.example.test betrieben. Für einen Standort-Proxy verwenden wir beispielsweise mlm-proxy-vienna01.example.test. In produktiven Umgebungen müssen diese Namen vor der Installation per DNS auflösbar sein.

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

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.

bash
hostnamectl
hostname -f
getent hosts mlm01.example.test
getent hosts mlm-proxy-vienna01.example.test
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.

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

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.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

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.

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

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.

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 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.

bash
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.

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

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.

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

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.

Belastbare Belege aus der getesteten Manager-Umgebung

Die folgenden Abschnitte beschreiben nicht nur die Befehle. Sie zeigen reale Zustände aus der getesteten SUSE-Multi-Linux-Manager-5.2-Umgebung: registrierte Clients, Channel-Zuordnung, Paket- und Patchzahlen, geplante Aktionen sowie den Stand der Audit-Funktionen. Zugangsdaten, Registrierungscodes und interne Infrastruktur sind bewusst nicht sichtbar.

  1. SLES 16 produktiv installieren
  2. SUSE Multi-Linux Manager 5.2 produktiv installieren
  3. Erste Linux-Clients produktiv onboarden
  4. Patch- und Lifecycle-Management produktiv aufbauen
  5. Mixed Linux produktiv verwalten
  6. OpenSCAP, Compliance und Audit produktiv nutzen
  7. Proxies für Standorte und verteilte Linux-Flotten aufbauen - dieser Beitrag
  8. SSO mit Keycloak, SAML und MFA integrieren
  9. Ansible neben Salt produktiv nutzen
  10. Reporting, Inventar und Subscription Audit aufbauen
  11. Produktiv betreiben und härten

Wartungsfenster, Kalender und echte Scheduled Actions

Im Lab ist ein iCalendar-basierter Maintenance-Kalender angelegt. Die technische Ausführung wird weiterhin über geplante Aktionen sichtbar: Paketlisten-Refresh, Reboots, Patchläufe und Audit-Jobs müssen in Produktion je Systemgruppe geprüft werden.

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
  • Wartungskalender definieren erlaubte Zeitfenster.
  • Scheduled Actions zeigen die technische Umsetzung.
  • Systemgruppen bestimmen, welche Systeme betroffen sind.
  • Reports und Audit-Auswertungen belegen nach dem Fenster das Ergebnis.

TLS-Abnahme: wenn proxy-httpd CERTIFICATE_VERIFY_FAILED meldet

Ein laufender Proxy-Pod ist noch kein Beweis, dass der Proxy den Parent-Manager vertrauenswuerdig erreicht. Wenn proxy-httpd beim Start oder bei der Konfiguration mit CERTIFICATE_VERIFY_FAILED abbricht, ist zuerst die tatsaechlich praesentierte Zertifikatskette des Managers gegen die im Proxy-Formular hochgeladene Root CA zu pruefen.

Im Lab zeigte sich genau dieses Fehlerbild: uyuni-configure.py konnte die Server-Version des Parent-Managers per HTTPS nicht abrufen, obwohl die Proxy-Services grundsaetzlich gestartet waren. Die HTTPD_EXTRA_CONF-Warnung war dabei nicht die Ursache; der harte Abbruch lag in der TLS-Verifikation.

bash
# auf dem Proxy: Zertifikatskette des Parent-Managers anzeigen
openssl s_client -connect mlm01.example.test:443 \
  -servername mlm01.example.test \
  -showcerts </dev/null


# aktives Manager-Zertifikat technisch einordnen
openssl s_client -connect mlm01.example.test:443 \
  -servername mlm01.example.test </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -fingerprint -sha256


# hochgeladene Root CA dagegen halten
openssl x509 \
  -in root-ca-RHN-ORG-TRUSTED-SSL-CERT.pem \
  -noout -subject -issuer -fingerprint -sha256

  • Manager-Zertifikat: Subject ist der Manager-FQDN, Issuer ist die MLM-CA.

  • Proxy-Zertifikat: Subject ist der Proxy-FQDN, Issuer ist dieselbe vertrauenswuerdige CA-Kette.

  • Root CA im Formular: CA, die das aktive Manager-Zertifikat validiert, nicht irgendein neu erzeugtes Proxy-Zertifikat.

  • Intermediate CAs: nur leer lassen, wenn die Kette direkt und vollstaendig validierbar ist.

Damit gehoert die CA-Pruefung in die technische Abnahme jedes Proxy-Rollouts: erst Zertifikatskette pruefen, dann Proxy-Konfiguration anwenden, danach Containerstatus, Ports, Salt-Verbindung und Client-Registrierung testen.

Praxisnotiz: Manager- oder Proxy-FQDN nachträglich ändern

Plane Manager- und Proxy-FQDN vor der Installation stabil ein. Ein späterer Wechsel ist möglich, betrifft aber mehr als hostnamectl und DNS. Gerade bei Proxies greifen Salt, Repository-URLs, Zertifikate und die Proxy-Containerkonfiguration ineinander.

Wichtig: Ein erfolgreicher Salt-Ping beweist nur, dass der Minion den Master erreicht. Er beweist nicht, dass Paketquellen, Proxy-Konfiguration, Zertifikatskette und Containerdienste bereits auf den neuen Namen umgestellt sind.

  • DNS und /etc/hosts müssen den neuen Manager- und Proxy-Namen konsistent auflösen.
  • Auf dem Manager müssen java.hostname, serverURL und Bootstrap-Overrides auf den produktiven FQDN zeigen.
  • Auf dem Proxy müssen /etc/uyuni/proxy/config.yaml, replace_fqdns und server zusammenpassen.
  • Zypper-Repositories unter /etc/zypp/repos.d/ dürfen keine alten Manager-URLs enthalten.
  • Manager-, Root-CA- und Proxy-Zertifikat müssen dieselbe erwartete Kette und die richtigen FQDNs abbilden.
  • Nach einem Bootstrap- oder Rename-Fehler können im Manager doppelte Systeme auftauchen, etwa ein alter Foreign-Proxy-Eintrag und ein neuer Salt-Proxy-Eintrag.

Prüfung nach einem Rename

  • salt <proxy-fqdn> test.ping prüft nur die Salt-Erreichbarkeit.
  • salt <proxy-fqdn> pkg.refresh_db prüft zusätzlich, ob Repository-URLs und Channel-Zugriff funktionieren.
  • mgrpxy status auf dem Proxy zeigt, ob die Proxy-Container und der Parent-Manager sauber konfiguriert sind.
  • grep -R <alter-fqdn> /etc/uyuni /etc/zypp/repos.d /etc/venv-salt-minion hilft, verbliebene Altverweise zu finden.
  • In der Weboberfläche sollten alte, falsch benannte Proxy-Einträge bereinigt werden, bevor der finale Proxy erneut konfiguriert wird.