Hoe stel je een lokale SUSE RMT-server in (vervanging voor SMT)?

Als u een lokale server instelt voor bestaande SUSE Linux Enterprise-systemen, gebruik dan de Repository Mirroring Tool (RMT) en geen nieuwe SMT-installatie. SUSE heeft de Subscription Management Tool (SMT) vervangen door RMT vanaf SLE 15. RMT synchroniseert product- en repository-informatie vanuit SUSE Customer Center (SCC), spiegelt geselecteerde pakketten en stelt ondersteunde clients in staat zich te registreren via uw lokale server. Deze handleiding volgt de SUSE Linux Enterprise Server 15 SP7 RMT-documentatie, gecontroleerd op 6 oktober 2026. Opdrachten en pakketbeschikbaarheid kunnen verschillen in andere releases, dus gebruik de handleiding voor de exacte serverversie die u implementeert.

Moet je RMT gebruiken of SMT behouden?

Kies RMT voor een nieuwe lokale registratie- en updateservice voor SLES 12 en nieuwere clients. RMT is inbegrepen bij SLES vanaf versie 15 en kan SUSE-repositories en aangepaste repositories spiegelen. Het vermindert herhaalde downloads en kan voorkomen dat clientmachines rechtstreeks verbinding maken met SCC.

SMT blijft relevant voor oudere omgevingen, maar SUSE beschouwt SLE 12 als de laatste codestream voor SMT. RMT ondersteunt geen clients van SLE 11 en ouder, en SUSE waarschuwt dat RMT geen volledige vervanging is: de migratiehandleiding vermeldt bijvoorbeeld staged repositories, SMT-clientbeheer en rapportage als functionaliteiten die niet op dezelfde manier worden overgezet. Als uw omgeving SLE 11 bevat of afhankelijk is van workflows die uitsluitend op SMT gebaseerd zijn, ga er dan niet vanuit dat een directe vervanging mogelijk is. Raadpleeg de migratiehandleiding en de ondersteuningsopties van SUSE voordat u de service wijzigt.

RMT verschilt ook van een offline pakketrepository. Een standaard RMT-server heeft uitgaande toegang nodig tot SCC en SUSE-updateservices om metadata en pakketten te synchroniseren. Een offline implementatie vereist een apart export-/importproces of een offline-mirroringproces.

Wat moet je voorbereiden vóór de installatie?

• Een ondersteunde host: Plan een SLES 15-server voor de RMT-service. Voor migratie van SMT raadt SUSE aan een nieuw geïnstalleerde SLES 15-host te gebruiken.
• Organisatiegegevens van SCC: RMT gebruikt de spiegelingsgegevens van de organisatie, niet een normale clientregistratiecode. Selecteer in SCC de juiste organisatie en open 'Proxy's' om deze te vinden.
• Een stabiele DNS-naam en TLS-plan: Kies de volledig gekwalificeerde domeinnaam (FQDN) die clients zullen gebruiken, bijvoorbeeld rmt.example.com. Zorg ervoor dat deze vanuit clientnetwerken wordt opgelost en overeenkomt met de naam op het HTTPS-certificaat.
• Opslagruimte voor de repository: De benodigde opslagruimte voor de producten, modules, versies en architecturen die u wilt spiegelen. SUSE geeft als algemene richtlijn ongeveer 1,5 keer de totale grootte van de ingeschakelde repository aan en merkt op dat dit ongeveer 200 GB per SLE-release is, inclusief extensies. De werkelijke behoeften variëren; houd de beschikbare ruimte in de gaten, met name de tijdelijke ruimte onder /tmp.
• Netwerktoegang: Zorg ervoor dat de RMT-host de SUSE-eindpunten kan bereiken die vereist zijn voor uw release. De SLES 15 SP7-handleiding vermeldt scc.suse.com, updates.suse.com, en installer-updates.suse.comvia poorten 80 en 443. Beperk de clienttoegang tot de RMT-service tot de netwerken die deze nodig hebben.

Combineer de RMT-rol niet met de SLES-installatieserverrol op dezelfde machine zonder eerst de SUSE-waarschuwing te controleren: de twee configuraties gebruiken verschillende webservers op poort 80 en zijn niet ontworpen om samen ingeschakeld te worden.

Hoe installeer en configureer ik RMT?

1. Installeer het RMT-pakket

Installeer op een bestaande SLES 15-host met de benodigde repositories het serverpakket en pas de huidige onderhoudsupdates toe:

sudo zypper in rmt-server
sudo zypper patch

De exacte pakketset kan verschillen afhankelijk van de minimale installatie-image en de implementatiemethode. Volg de installatie-instructies voor de door u gekozen SLES-release in plaats van een commando van een ander platform te kopiëren.

2. Voer de YaST RMT-configuratie uit.

Start de configuratiemodule:

sudo yast2 rmt

Voer de gebruikersnaam en het wachtwoord van de SCC-organisatie in wanneer daarom wordt gevraagd. YaST vraagt ​​ook om een ​​MariaDB-database en -gebruiker, en om een ​​algemene naam voor het certificaat. Gebruik de FQDN (Fully Qualified Domain Name) van de RMT-server als algemene naam. Voeg alle andere namen of IP-adressen die clients daadwerkelijk zullen gebruiken toe als alternatieve namen op het certificaat. Een client die verbinding maakt met een naam die niet in de lijst staat, kan een certificaatfout melden, zelfs als de service bereikbaar is.

Als firewalldYaST is ingeschakeld, gebruik dan de YaST-optie om de benodigde RMT-poorten te openen. Beperk de toegang waar mogelijk tot de juiste netwerkinterface of -zone. Voltooi de wizard en bekijk het overzicht; SUSE geeft aan dat YaST de benodigde systemd-services en timers inschakelt en start.

3. Controleer de servernaam, het certificaat en de service.

Controleer vanuit een clientnetwerk of de gekozen FQDN verwijst naar de RMT-host en of HTTPS een certificaat presenteert dat door de client wordt vertrouwd. Het door RMT gegenereerde CA-certificaat is opgeslagen op /etc/rmt/ssl/rmt-ca.crt; het servercertificaat en de bijbehorende sleutel zijn opgeslagen op /etc/rmt/ssl/rmt-server.crten /etc/rmt/ssl/rmt-server.key. Bescherm de privésleutel en zorg ervoor dat het CA-certificaat beschikbaar blijft voor clients die erop moeten kunnen vertrouwen. Gebruik voor de registratie exact dezelfde FQDN als die in het servercertificaat staat.

Hoe selecteer en spiegel je alleen de repositories die je nodig hebt?

4. Synchroniseer product- en repositorymetadata

Na de installatie synchroniseert u de lokale RMT-database met SCC:

sudo rmt-cli sync

Dit werkt de product- en repository-informatie bij die beschikbaar is voor RMT; het betekent niet dat elk pakket al is gedownload. De automatische synchronisatie van metadata wordt beheerd door rmt-server-sync.timer. Controleer de status ervan met:

systemctl status rmt-server-sync.timer

5. Zoek de productidentificaties voor uw nalatenschap.

Geef een lijst van de beschikbare producten en repositories voordat u iets inschakelt:

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

Gebruik de ID's of productstrings die door uw eigen server worden gerapporteerd. De ID's in online voorbeelden kunnen afwijken, omdat de beschikbaarheid afhankelijk is van abonnementen, productversies, architecturen en de metadata die door SCC worden geretourneerd.

6. Schakel de benodigde producten in.

Schakel de producten in die klanten daadwerkelijk gebruiken. Nadat u bijvoorbeeld hebt gecontroleerd of de productnaam in uw uitvoer voorkomt, kunt u het volgende uitvoeren:

sudo rmt-cli products enable SLES/15/x86_64

Door een product in te schakelen, worden ook de bijbehorende repositories ingeschakeld, zoals pool- en update-repositories. Als uw systemen gebruikmaken van extra modules of extensies, controleer dan of deze producten beschikbaar zijn en schakel de benodigde in. Vermijd het spiegelen van elk product "voor de zekerheid": dit verbruikt opslagruimte en verlengt de synchronisatietijd.

7. Spiegel de pakketten en controleer het resultaat.

Start de eerste spiegeling handmatig, zodat u de voltooiing kunt observeren en eventuele problemen kunt opsporen voordat u op het schema vertrouwt:

sudo rmt-cli mirror

RMT slaat gespiegelde inhoud /var/lib/rmt/public/repostandaard op in de opgegeven map. Controleer de beschikbare schijfruimte en bekijk de uitvoer van de opdracht. Het dagelijkse spiegelschema wordt beheerd door rmt-server-mirror.timer; controleer de status ervan met:

systemctl status rmt-server-mirror.timer

Een succesvolle synchronisatie van metadata is op zich geen bewijs dat clients updates kunnen installeren. De geselecteerde repositories moeten gespiegeld zijn, de client moet de server kunnen bereiken en de producttoegang moet geldig zijn voor de organisatie.

Hoe registreer je een client bij de lokale server?

8. Test eerst met één klant.

Registreer de SLES-client op een ondersteunde client met de RMT-hostnaam. SUSE beschrijft deze opdrachtvorm als volgt:

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

Vervang de voorbeeldhost door de FQDN die onder uw certificaat valt. Clients hebben normaal gesproken de SCC-spiegelingsreferenties niet nodig; de RMT-host gebruikt deze referenties om namens de organisatie te synchroniseren. Voor systemen die hulp nodig hebben bij het importeren van de RMT CA, biedt SUSE een rmt-client-setupscript vanaf de server. Raadpleeg de huidige clienthandleiding en controleer de certificaatvingerafdruk of de vertrouwensketen voordat u een certificaat accepteert.

U kunt de registratie ook tijdens de installatie configureren met de regurl=https://rmt.example.comopstartparameter, of de productregistratiemodule van YaST gebruiken en de lokale registratieserver selecteren. Voor geautomatiseerde installaties beschrijft SUSE een AutoYaST-optie. Kies een methode die past bij de manier waarop uw systemen worden geconfigureerd.

9. Controleer de registratie en de toegang tot het pakket.

Controleer aan de clientzijde of de registratie is voltooid, of de verwachte producten en repositories verschijnen en of de metadata van de repository kunnen worden vernieuwd. Inspecteer bijvoorbeeld de repositorydefinities zypper lren vernieuw ze met sudo zypper refresh. Test vervolgens een pakketquery of -update tijdens een onderhoudsvenster. Als een module ontbreekt, controleer dan of deze is ingeschakeld en gespiegeld op RMT voordat u repositorybestanden aan de clientzijde wijzigt.

Test een standaard updatepad eerst op één representatieve client voordat u een grote vloot omleidt. Nadat die test is geslaagd, kunt u de provisioningprofielen, installatie-opstartparameters of configuratiebeheer bijwerken, zodat nieuwe en opnieuw opgebouwde systemen dezelfde RMT-URL gebruiken.

Wat moet je controleren als er iets misgaat?

Wat verandert er als je migreert van SMT?

Beschouw migratie als een wijziging van gegevens en workflows, niet als een upgrade van pakketten. SUSE raadt een nieuwe SLES 15-host aan. Het gedocumenteerde export-/importproces wordt uitgevoerd smt-data-exportop SMT en rmt-data-importop de nieuwe server nadat RMT is gesynchroniseerd met SCC. Instellingen van de staging-repository worden niet geëxporteerd; alleen repositories die zijn gemarkeerd voor mirroring worden overgezet en verlopen producten zijn niet beschikbaar op RMT. SMT-clienttaken en patchstatus worden niet geëxporteerd. Plan om operationele processen die afhankelijk zijn van deze functies opnieuw te creëren en controleer registratiegegevens voordat u productieclients omleidt.

Houd de oude service beschikbaar tijdens een gecontroleerde overgang als uw ondersteunings- en beveiligingsbeleid dit toestaat. Migreer een kleine groep klanten, controleer de registratie, repositories, certificaatvertrouwen en updategedrag, en breid vervolgens uit. Schakel de SMT-host niet uit totdat verouderde klanten en niet-ondersteunde workflows een expliciete bestemming hebben.

Hoe weet je of de installatie gereed is?

• De RMT FQDN wordt correct opgelost en HTTPS maakt gebruik van een certificaat dat door clients wordt vertrouwd.
• De RMT-host synchroniseert de actuele SCC-metadata en spiegelt elke productrepository die nodig is voor de pilotklanten.
• Een ondersteunde client registreert zich bij de lokale URL en krijgt toegang tot de beoogde productrepository's.
• Een client kan de metagegevens van de repository vernieuwen en een gecontroleerde pakketbewerking voltooien.
• Schijfcapaciteit, tijdelijke opslagruimte, timers, logboeken, back-ups en certificaatvernieuwing hebben een eigenaar en een monitoringplan.

RMT centraliseert de registratie en pakketlevering, maar neemt niet de noodzaak weg om abonnementen, productselectie, de levenscyclus van de client, certificaatvertrouwen, back-ups en updatetesten te beheren. Raadpleeg voor de exacte procedures en releasespecifieke verschillen de SUSE SLES 15 SP7 Repository Mirroring Tool Guide , het hoofdstuk over SMT-naar-RMT-migratie , het hoofdstuk over RMT-clientconfiguratie en het SUSE- hoofdstuk over repository mirroring .