Comment configurer un serveur RMT SUSE local (remplacement de SMT)

Si vous configurez un serveur local pour les systèmes SUSE Linux Enterprise actuels, utilisez l'outil de mise en miroir des dépôts (RMT) et non une nouvelle installation de SMT. SUSE a remplacé l'outil de gestion des abonnements (SMT) par RMT à partir de SLE 15. RMT synchronise les informations sur les produits et les dépôts depuis SUSE Customer Center (SCC), met en miroir les paquets sélectionnés et permet aux clients compatibles de s'enregistrer via votre serveur local. Ce guide suit la documentation RMT de SUSE Linux Enterprise Server 15 SP7, vérifiée le 6 octobre 2026. Les commandes et la disponibilité des paquets peuvent différer selon les versions ; consultez donc le guide correspondant à la version exacte du serveur que vous déployez.

Faut-il utiliser RMT ou conserver SMT ?

Choisissez RMT pour un nouveau service d'enregistrement et de mise à jour local pour les clients SLES 12 et versions ultérieures. Intégré à SLES à partir de la version 15, RMT permet de dupliquer les dépôts SUSE et les dépôts personnalisés. Il réduit les téléchargements répétés et empêche les machines clientes de se connecter directement au SCC.

SMT reste pertinent pour les environnements plus anciens, mais SUSE indique que SLE 12 est la dernière version compatible avec SMT. RMT ne prend pas en charge SLE 11 et les versions antérieures, et SUSE précise que RMT ne constitue pas un remplacement complet, fonctionnalité par fonctionnalité : par exemple, son guide de migration mentionne les dépôts intermédiaires, la gestion des clients SMT et la génération de rapports comme des fonctionnalités qui ne sont pas transférées à l’identique. Si votre infrastructure inclut SLE 11 ou dépend de flux de travail exclusivement SMT, ne présumez pas qu’un remplacement direct est possible. Consultez le guide de migration et les options d’assistance SUSE avant de changer de service.

RMT diffère également d'un dépôt de paquets isolé du réseau. Un serveur RMT standard nécessite un accès sortant aux services de mise à jour SCC et SUSE pour synchroniser les métadonnées et les paquets. Un déploiement déconnecté requiert une procédure d'exportation/importation ou de duplication hors ligne distincte.

Que devez-vous préparer avant l'installation ?

• Serveur compatible : prévoyez un serveur SLES 15 pour le service RMT. Pour la migration depuis SMT, SUSE recommande l’utilisation d’un serveur SLES 15 nouvellement installé.
• Identifiants de l'organisation SCC : RMT utilise les identifiants de mise en miroir de l'organisation, et non un code d'enregistrement client standard. Dans SCC, sélectionnez l'organisation appropriée et ouvrez la section « Proxies » pour la trouver.
• Un nom DNS stable et un plan TLS : choisissez le nom de domaine pleinement qualifié (FQDN) que les clients utiliseront, par exemplermt.example.com : . Assurez-vous qu’il est résolu depuis les réseaux clients et qu’il correspond au nom figurant sur le certificat HTTPS.
• Espace de stockage des dépôts : dimensionnez l’espace de stockage nécessaire pour les produits, modules, versions et architectures que vous souhaitez mettre en miroir. SUSE recommande, à titre indicatif, environ 1,5 fois la taille totale des dépôts activés, soit environ 200 Go par version SLE, extensions comprises. Les besoins réels varient ; surveillez l’espace libre, en particulier l’espace temporaire sous le répertoire `/etc/sleep` /tmp.
• Accès réseau : autorisez l’hôte RMT à accéder aux points de terminaison SUSE requis par votre version. Le guide SLES 15 SP7 mentionne scc.suse.comles updates.suse.comports installer-updates.suse.com80 et 443. Limitez l’accès client au service RMT aux réseaux qui en ont besoin.

Ne combinez pas le rôle RMT avec le rôle de serveur d'installation SLES sur la même machine sans vérifier l'avertissement SUSE : les deux configurations utilisent des serveurs Web différents sur le port 80 et ne sont pas conçues pour être activées ensemble.

Comment installer et configurer RMT ?

1. Installez le package RMT

Sur un hôte SLES 15 existant disposant des dépôts requis, installez le package serveur et appliquez les mises à jour de maintenance actuelles :

sudo zypper in rmt-server
sudo zypper patch

La configuration exacte des paquets peut varier selon les images minimales et les méthodes de déploiement. Suivez les instructions d'installation correspondant à votre version SLES plutôt que de copier une commande d'une autre plateforme.

2. Exécutez la configuration YaST RMT

Démarrer le module de configuration :

sudo yast2 rmt

Saisissez le nom d'utilisateur et le mot de passe de la mise en miroir de l'organisation SCC lorsque vous y êtes invité. YaST demande également une base de données et un utilisateur MariaDB, ainsi qu'un nom commun pour le certificat. Utilisez le nom de domaine complet (FQDN) du serveur RMT accessible aux clients comme nom commun. Ajoutez tout autre nom ou adresse IP que les clients utiliseront comme noms alternatifs sur le certificat. Un client se connectant via un nom non répertorié peut signaler une incohérence de certificat, même si le service est accessible.

Si firewalldcette option est activée, utilisez YaST pour ouvrir les ports RMT requis. Dans la mesure du possible, limitez l'accès à l'interface réseau ou à la zone appropriée. Terminez l'assistant et consultez son résumé ; SUSE indique que YaST active et démarre les services et minuteurs systemd nécessaires.

3. Vérifiez le nom du serveur, le certificat et le service.

Depuis le réseau client, vérifiez que le nom de domaine complet (FQDN) choisi pointe bien vers l'hôte RMT et que le protocole HTTPS présente un certificat approuvé par le client. Le certificat d'autorité de certification (CA) généré par RMT est stocké à l'emplacement indiqué/etc/rmt/ssl/rmt-ca.crt ; le certificat et la clé du serveur sont stockés aux /etc/rmt/ssl/rmt-server.crtemplacements indiqués /etc/rmt/ssl/rmt-server.key. Protégez la clé privée et conservez le certificat CA à disposition des clients qui doivent lui faire confiance. Utilisez le même FQDN pour l'enregistrement que celui figurant dans le certificat du serveur.

Comment sélectionner et dupliquer uniquement les dépôts dont vous avez besoin ?

4. Synchroniser les métadonnées du produit et du référentiel

Après la configuration, synchronisez la base de données RMT locale avec SCC :

sudo rmt-cli sync

Cette opération met à jour les informations sur les produits et les dépôts disponibles pour RMT ; cela ne signifie pas que tous les paquets ont déjà été téléchargés. La synchronisation automatique des métadonnées est gérée par [nom du service/outil] rmt-server-sync.timer. Vérifiez son état avec : [commande/outil].

systemctl status rmt-server-sync.timer

5. Trouvez les identifiants de produit de votre succession

Veuillez lister les produits et les dépôts disponibles avant d'activer quoi que ce soit :

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

Utilisez les identifiants ou les chaînes de produits renvoyés par votre serveur. Les identifiants des exemples en ligne peuvent différer, car la disponibilité dépend des abonnements, des versions de produits, des architectures et des métadonnées renvoyées par SCC.

6. Activer les produits requis

Activez les produits réellement utilisés par les clients. Par exemple, après avoir vérifié que la chaîne de produit figure bien dans votre résultat, vous pouvez exécuter :

sudo rmt-cli products enable SLES/15/x86_64

L'activation d'un produit active également ses dépôts associés, tels que les dépôts de pool et de mise à jour. Si vos systèmes utilisent des modules ou extensions supplémentaires, vérifiez leur disponibilité et activez ceux nécessaires. Évitez de dupliquer systématiquement chaque produit « par précaution » : cela consomme de l'espace de stockage et allonge le temps de synchronisation.

7. Mettez les paquets en miroir et examinez le résultat

Démarrez manuellement la première synchronisation afin de pouvoir observer la fin de l'opération et résoudre les problèmes avant de vous fier à la planification :

sudo rmt-cli mirror

RMT stocke le contenu dupliqué /var/lib/rmt/public/repopar défaut sous . Vérifiez l'espace disque disponible et consultez le résultat de la commande. La planification quotidienne des miroirs est gérée parrmt-server-mirror.timer ; consultez son état avec :

systemctl status rmt-server-mirror.timer

Une synchronisation réussie des métadonnées ne garantit pas à elle seule que les clients peuvent installer les mises à jour. Les référentiels sélectionnés doivent être répliqués, le client doit pouvoir accéder au serveur et l'accès au produit doit être valide pour l'organisation.

Comment enregistrer un client auprès du serveur local ?

8. Commencez par tester avec un seul client.

Sur un client SLES compatible, enregistrez-le auprès du nom d'hôte RMT. SUSE documente cette commande :

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

Remplacez l'hôte d'exemple par le nom de domaine complet (FQDN) couvert par votre certificat. Les clients n'ont généralement pas besoin des informations d'identification de la mise en miroir SCC ; l'hôte RMT les utilise pour la synchronisation au nom de l'organisation. Pour les systèmes nécessitant une assistance lors de l'importation de l'autorité de certification RMT, SUSE fournit un rmt-client-setupscript depuis le serveur. Consultez le guide client actuel et vérifiez l'empreinte du certificat ou la chaîne de confiance avant d'accepter un certificat.

Vous pouvez également configurer l'enregistrement lors de l'installation à l'aide du regurl=https://rmt.example.comparamètre de démarrage, ou utiliser le module d'enregistrement de produits de YaST et choisir le serveur d'enregistrement local. Pour les installations automatisées, SUSE propose l'option AutoYaST. Choisissez la méthode qui convient le mieux à la configuration de vos systèmes.

9. Vérifier l'inscription et l'accès au colis

Sur le client, vérifiez que l'enregistrement est terminé, que les produits et dépôts attendus apparaissent et que les métadonnées des dépôts peuvent être actualisées. Par exemple, consultez les définitions des dépôts zypper lret actualisez-les sudo zypper refresh. Testez ensuite une requête ou une mise à jour de paquet pendant une fenêtre de maintenance. Si un module est manquant, vérifiez s'il est activé et répliqué sur RMT avant de modifier les fichiers de dépôt côté client.

Avant de rediriger un parc important de systèmes, effectuez un test de procédure de mise à jour standard sur un client représentatif. Une fois le test concluant, mettez à jour les profils de provisionnement, les paramètres de démarrage de l'installation ou la gestion de la configuration afin que les systèmes nouveaux et reconstruits utilisent la même URL RMT.

Que faut-il vérifier en cas de panne ?

Quels changements surviennent lors d'une migration depuis SMT ?

Considérez la migration comme une modification des données et des flux de travail, et non comme une simple mise à niveau des paquets. SUSE recommande un nouvel hôte SLES 15. Sa procédure d'exportation/importation documentée s'applique smt-data-exportà SMT et rmt-data-importau nouveau serveur après la synchronisation de RMT avec SCC. Les paramètres des dépôts intermédiaires ne sont pas exportés ; seuls les dépôts marqués pour la mise en miroir sont conservés, et les produits expirés ne sont pas disponibles sur RMT. Les tâches client SMT et l'état des correctifs ne sont pas exportés. Prévoyez de recréer les processus opérationnels qui dépendaient de ces fonctionnalités et de valider les enregistrements avant de rediriger les clients de production.

Si vos politiques de support et de sécurité le permettent, maintenez le service existant disponible pendant une transition contrôlée. Migrez un petit groupe de clients, vérifiez l'enregistrement, les référentiels, la confiance des certificats et le comportement des mises à jour, puis étendez la migration. Ne mettez pas hors service l'hôte SMT tant que les clients existants et les flux de travail non pris en charge n'ont pas de destination explicite.

Comment savoir si l'installation est prête ?

• Le nom de domaine complet RMT est correctement résolu et le protocole HTTPS utilise un certificat approuvé par les clients.
• L'hôte RMT synchronise les métadonnées SCC actuelles et met en miroir chaque référentiel de produits requis par les clients pilotes.
• Un client compatible s'enregistre auprès de l'URL locale et visualise les référentiels de produits prévus.
• Un client peut actualiser les métadonnées du référentiel et effectuer une opération de paquetage contrôlée.
• La capacité disque, l'espace temporaire, les minuteurs, les journaux, la sauvegarde et le renouvellement des certificats ont un responsable et un plan de surveillance.

RMT centralise l'enregistrement et la distribution des paquets, mais ne dispense pas de la gestion des abonnements, de la sélection des produits, du cycle de vie des clients, de la confiance des certificats, des sauvegardes et des tests de mise à jour. Pour connaître les procédures exactes et les différences propres à chaque version, consultez le guide de l'outil de mise en miroir du dépôt SLES 15 SP7 de SUSE , le chapitre sur la migration de SMT vers RMT , le chapitre sur la configuration du client RMT et le chapitre sur la mise en miroir du dépôt de SUSE .