So richten Sie einen lokalen SUSE RMT-Server ein (SMT-Ersatz)

Wenn Sie einen lokalen Server für aktuelle SUSE Linux Enterprise-Systeme einrichten, verwenden Sie das Repository Mirroring Tool (RMT) und keine neue SMT-Installation. SUSE hat das Subscription Management Tool (SMT) ab SLE 15 durch RMT ersetzt. RMT synchronisiert Produkt- und Repository-Informationen vom SUSE Customer Center (SCC), spiegelt ausgewählte Pakete und ermöglicht es unterstützten Clients, sich über Ihren lokalen Server zu registrieren. Diese Anleitung basiert auf der RMT-Dokumentation von SUSE Linux Enterprise Server 15 SP7 (Stand: 6. Oktober 2026). Befehle und Paketverfügbarkeit können in anderen Versionen abweichen. Verwenden Sie daher die Anleitung für die exakte Serverversion, die Sie einsetzen.

Sollten Sie RMT verwenden oder SMT beibehalten?

Wählen Sie RMT für einen neuen lokalen Registrierungs- und Aktualisierungsdienst für SLES 12 und neuere Clients. RMT ist ab SLES Version 15 enthalten und kann SUSE-Repositories sowie benutzerdefinierte Repositories spiegeln. Dadurch werden wiederholte Downloads reduziert und verhindert, dass Client-Rechner direkt eine Verbindung zum SCC herstellen.

SMT ist für ältere Umgebungen weiterhin relevant, SUSE gibt jedoch SLE 12 als letzten Codestream für SMT an. RMT unterstützt keine Clients von SLE 11 und früheren Versionen. SUSE weist außerdem darauf hin, dass RMT kein vollständiger Ersatz für SMT ist: Beispielsweise werden in der Migrationsanleitung Staging-Repositories, die SMT-Clientverwaltung und die Berichtsfunktion als Funktionen aufgeführt, die nicht ohne Weiteres übernommen werden können. Wenn Ihre Umgebung SLE 11 umfasst oder ausschließlich auf SMT-Workflows basiert, sollten Sie nicht davon ausgehen, dass ein direkter Austausch möglich ist. Lesen Sie die Migrationsanleitung und informieren Sie sich über die Supportoptionen von SUSE, bevor Sie den Dienst wechseln.

RMT unterscheidet sich auch von einem isolierten Paket-Repository. Ein Standard-RMT-Server benötigt ausgehenden Zugriff auf SCC und die SUSE-Update-Dienste, um Metadaten und Pakete zu synchronisieren. Eine nicht-stationäre Bereitstellung erfordert einen separaten Export-/Import- oder Offline-Mirroring-Prozess.

Was sollten Sie vor der Installation vorbereiten?

• Ein unterstützter Host: Planen Sie einen SLES 15-Server für den RMT-Dienst. Für die Migration von SMT empfiehlt SUSE die Verwendung eines neu installierten SLES 15-Hosts.
• SCC-Organisationszugangsdaten: RMT verwendet die Spiegelungszugangsdaten der Organisation, nicht einen normalen Client-Registrierungscode. Wählen Sie in SCC die richtige Organisation aus und öffnen Sie die Proxys , um diese zu finden.
• Ein stabiler DNS-Name und ein geeigneter TLS-Plan: Wählen Sie den vollqualifizierten Domänennamen (FQDN), den Clients verwenden werden, z. B. „ rmt.example.comexample.com“. Stellen Sie sicher, dass er aus Client-Netzwerken aufgelöst werden kann und mit dem Namen im HTTPS-Zertifikat übereinstimmt.
• Repository-Speicher: Berechnen Sie die benötigte Speicherkapazität für die Produkte, Module, Versionen und Architekturen, die Sie spiegeln möchten. SUSE empfiehlt als allgemeine Planungsrichtlinie das 1,5-Fache der gesamten aktivierten Repository-Größe. Dies entspricht etwa 200 GB pro SLE-Release inklusive Erweiterungen. Der tatsächliche Bedarf kann variieren; überwachen Sie daher den freien Speicherplatz, insbesondere den temporären Speicherplatz /tmp.
• Netzwerkzugriff: Gewähren Sie dem RMT-Host Zugriff auf die für Ihre Version erforderlichen SUSE-Endpunkte. Die SLES 15 SP7-Anleitung listet scc.suse.comdie updates.suse.comentsprechenden installer-updates.suse.comPorts 80 und 443 auf. Beschränken Sie den Clientzugriff auf den RMT-Dienst auf die Netzwerke, die ihn benötigen.

Kombinieren Sie die RMT-Rolle nicht mit der SLES-Installationsserverrolle auf demselben Rechner, ohne vorher die SUSE-Warnung zu beachten: Die beiden Konfigurationen verwenden unterschiedliche Webserver auf Port 80 und sind nicht für die gleichzeitige Aktivierung vorgesehen.

Wie installiert und konfiguriert man RMT?

1. Installieren Sie das RMT-Paket

Installieren Sie auf einem bestehenden SLES 15-Host mit den erforderlichen Repositories das Serverpaket und wenden Sie die aktuellen Wartungsupdates an:

sudo zypper in rmt-server
sudo zypper patch

Die genauen Paketbestände können je nach Minimalimage und Bereitstellungsmethode variieren. Befolgen Sie die Installationsanleitung für Ihre gewählte SLES-Version, anstatt einen Befehl von einer anderen Plattform zu kopieren.

2. Führen Sie die YaST RMT-Konfiguration aus

Starten Sie das Konfigurationsmodul:

sudo yast2 rmt

Geben Sie bei Aufforderung den Benutzernamen und das Passwort für die SCC-Organisationsspiegelung ein. YaST fragt außerdem nach einer MariaDB-Datenbank und einem Benutzer sowie nach einem allgemeinen Namen für das Zertifikat. Verwenden Sie den clientseitigen FQDN des RMT-Servers als allgemeinen Namen. Fügen Sie alle weiteren Namen oder IP-Adressen, die Clients tatsächlich verwenden, als alternative Namen im Zertifikat hinzu. Ein Client, der sich über einen nicht aufgeführten Namen verbindet, kann eine Zertifikatsabweichung melden, selbst wenn der Dienst erreichbar ist.

Wenn firewallddie Option aktiviert ist, verwenden Sie YaST, um die benötigten RMT-Ports zu öffnen. Beschränken Sie den Zugriff nach Möglichkeit auf die richtige Netzwerkschnittstelle oder Zone. Schließen Sie den Assistenten ab und überprüfen Sie die Zusammenfassung. Laut SUSE aktiviert und startet YaST die erforderlichen systemd-Dienste und Timer.

3. Servernamen, Zertifikat und Dienst bestätigen.

Prüfen Sie im Clientnetzwerk, ob der gewählte FQDN zum RMT-Host aufgelöst wird und ob HTTPS ein vom Client als vertrauenswürdig eingestuftes Zertifikat bereitstellt. Das von RMT generierte CA-Zertifikat befindet sich unter [Pfad einfügen] /etc/rmt/ssl/rmt-ca.crt; Serverzertifikat und -schlüssel befinden sich unter [Pfad einfügen] /etc/rmt/ssl/rmt-server.crtund [ /etc/rmt/ssl/rmt-server.keyPfad einfügen]. Schützen Sie den privaten Schlüssel und stellen Sie das CA-Zertifikat für Clients bereit, die ihm vertrauen müssen. Verwenden Sie für die Registrierung exakt denselben FQDN, der im Serverzertifikat erscheint.

Wie wählt man die benötigten Repositories aus und spiegelt sie?

4. Produkt- und Repository-Metadaten synchronisieren

Nach der Einrichtung synchronisieren Sie die lokale RMT-Datenbank mit SCC:

sudo rmt-cli sync

Dadurch werden die für RMT verfügbaren Produkt- und Repository-Informationen aktualisiert; dies bedeutet nicht, dass bereits alle Pakete heruntergeladen wurden. Die automatische Metadatensynchronisierung wird von [Name der Software/des Tools] verwaltet rmt-server-sync.timer. Überprüfen Sie den Status mit folgendem Befehl:

systemctl status rmt-server-sync.timer

5. Ermitteln Sie die Produktkennungen für Ihr Anwesen.

Bevor Sie irgendetwas aktivieren, listen Sie die verfügbaren Produkte und Repositories auf:

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

Verwenden Sie die IDs oder Produktbezeichnungen, die von Ihrem eigenen Server gemeldet werden. Die IDs in Online-Beispielen können abweichen, da die Verfügbarkeit von Abonnements, Produktversionen, Architekturen und den von SCC zurückgegebenen Metadaten abhängt.

6. Aktivieren Sie die erforderlichen Produkte

Aktivieren Sie die Produkte, die Ihre Kunden tatsächlich verwenden. Nachdem Sie beispielsweise bestätigt haben, dass die Produktzeichenfolge in Ihrer Ausgabe vorhanden ist, könnten Sie Folgendes ausführen:

sudo rmt-cli products enable SLES/15/x86_64

Durch die Aktivierung eines Produkts werden auch die zugehörigen Repositories, wie z. B. Pool- und Update-Repositories, aktiviert. Falls Ihre Systeme zusätzliche Module oder Erweiterungen verwenden, prüfen Sie, ob diese Produkte verfügbar sind, und aktivieren Sie die benötigten. Vermeiden Sie es, jedes Produkt vorsorglich zu spiegeln: Dies verbraucht Speicherplatz und verlängert die Synchronisierungszeit.

7. Spiegeln Sie die Pakete und überprüfen Sie das Ergebnis.

Starten Sie den ersten Spiegelvorgang manuell, um den Abschluss zu beobachten und Fehler zu beheben, bevor Sie sich auf den Zeitplan verlassen:

sudo rmt-cli mirror

RMT speichert gespiegelte Inhalte /var/lib/rmt/public/repostandardmäßig unter [Pfad einfügen]. Prüfen Sie den verfügbaren Speicherplatz und die Ausgabe des Befehls. Der tägliche Spiegelungsplan wird von [Befehl einfügen] verwaltet rmt-server-mirror.timer; prüfen Sie seinen Status mit:

systemctl status rmt-server-mirror.timer

Eine erfolgreiche Metadatensynchronisierung allein beweist nicht, dass Clients Updates installieren können. Die ausgewählten Repositories müssen gespiegelt sein, der Client muss den Server erreichen können und der Produktzugriff muss für die Organisation gültig sein.

Wie registriert man einen Client auf dem lokalen Server?

8. Testen Sie zunächst mit einem Kunden.

Registrieren Sie einen unterstützten SLES-Client unter dem RMT-Hostnamen. SUSE dokumentiert diese Befehlsform wie folgt:

sudo SUSEConnect --url https://rmt.example.com

Ersetzen Sie den Beispielhost durch den FQDN, der von Ihrem Zertifikat abgedeckt wird. Clients benötigen normalerweise keine SCC-Spiegelungsanmeldeinformationen; der RMT-Host verwendet diese Anmeldeinformationen zur Synchronisierung im Namen der Organisation. Für Systeme, die Unterstützung beim Importieren der RMT-CA benötigen, stellt SUSE ein rmt-client-setupSkript vom Server bereit. Lesen Sie die aktuelle Client-Anleitung und überprüfen Sie den Zertifikat-Fingerabdruck oder die Vertrauenskette, bevor Sie ein Zertifikat akzeptieren.

Sie können die Registrierung auch während der Installation über den regurl=https://rmt.example.comBootparameter konfigurieren oder das Produktregistrierungsmodul von YaST verwenden und den lokalen Registrierungsserver auswählen. Für automatisierte Installationen bietet SUSE die Option AutoYaST an. Wählen Sie die Methode, die am besten zu Ihrer Systembereitstellung passt.

9. Registrierung und Paketzugriff überprüfen

Überprüfen Sie auf dem Client, ob die Registrierung abgeschlossen ist, die erwarteten Produkte und Repositories angezeigt werden und die Repository-Metadaten aktualisiert werden können. Prüfen Sie beispielsweise die Repository-Definitionen mit `repository_definitions` zypper lrund aktualisieren Sie sie mit ` sudo zypper refreshrepository_definitions`. Testen Sie anschließend eine Paketabfrage oder -aktualisierung in einem Wartungsfenster. Falls ein Modul fehlt, prüfen Sie, ob es auf RMT aktiviert und gespiegelt ist, bevor Sie Änderungen an den clientseitigen Repository-Dateien vornehmen.

Testen Sie einen regulären Aktualisierungspfad auf einem repräsentativen Kunden, bevor Sie eine große Anzahl von Systemen umleiten. Nach erfolgreichem Test aktualisieren Sie die Bereitstellungsprofile, die Installationsstartparameter oder die Konfigurationsverwaltung, sodass neue und neu installierte Systeme dieselbe RMT-URL verwenden.

Was sollten Sie überprüfen, wenn etwas fehlschlägt?

Was ändert sich bei einer Migration von SMT?

Behandeln Sie die Migration als Daten- und Workflowänderung, nicht als Paketaktualisierung. SUSE empfiehlt einen neuen SLES 15-Host. Der dokumentierte Export-/Importprozess wird smt-data-exportauf SMT und rmt-data-importauf dem neuen Server angewendet, nachdem RMT mit SCC synchronisiert wurde. Einstellungen für bereitgestellte Repositories werden nicht exportiert; nur für die Spiegelung markierte Repositories werden übernommen, und abgelaufene Produkte sind auf RMT nicht verfügbar. SMT-Client-Jobs und Patch-Status werden nicht exportiert. Planen Sie, operative Prozesse, die von diesen Funktionen abhängen, neu zu erstellen und Registrierungsdatensätze zu validieren, bevor Sie Produktionsclients umleiten.

Sofern Ihre Support- und Sicherheitsrichtlinien dies zulassen, sollte der alte Dienst während einer kontrollierten Übergangsphase weiterhin verfügbar sein. Migrieren Sie zunächst eine kleine Clientgruppe, überprüfen Sie Registrierung, Repositories, Zertifikatsvertrauen und Aktualisierungsverhalten und erweitern Sie die Migration anschließend. Schalten Sie den SMT-Host erst dann ab, wenn für ältere Clients und alle nicht unterstützten Workflows ein eindeutiges Ziel festgelegt wurde.

Woran erkennt man, dass die Einrichtung abgeschlossen ist?

• Der RMT-FQDN wird korrekt aufgelöst und HTTPS verwendet ein von den Clients als vertrauenswürdig eingestuftes Zertifikat.
• Der RMT-Host synchronisiert die aktuellen SCC-Metadaten und spiegelt jedes von den Pilotkunden benötigte Produktrepository.
• Ein unterstützter Client registriert sich an der lokalen URL und sieht die gewünschten Produkt-Repositories.
• Ein Client kann Repository-Metadaten aktualisieren und eine kontrollierte Paketoperation abschließen.
• Für Festplattenkapazität, temporären Speicherplatz, Timer, Protokolle, Datensicherung und Zertifikatserneuerung gibt es einen Verantwortlichen und einen Überwachungsplan.

RMT zentralisiert Registrierung und Paketbereitstellung, ersetzt aber nicht die Verwaltung von Abonnements, Produktauswahl, Client-Lebenszyklus, Zertifikatsvertrauen, Backups und Update-Tests. Genaue Vorgehensweisen und versionsspezifische Unterschiede finden Sie im SUSE-Handbuch „ SLES 15 SP7 Repository Mirroring Tool Guide“ , im Kapitel zur Migration von SMT zu RMT , im Kapitel zur RMT-Clientkonfiguration und im SUSE- Kapitel zur Repository-Spiegelung .