Comment enregistrer une machine SLES 15 auprès de SUSE Manager hors ligne

Une machine SLES 15 n'a pas besoin d'un accès Internet direct pour devenir un client SUSE Manager géré. Elle nécessite en revanche un accès réseau fiable au serveur ou proxy SUSE Manager interne, ainsi que les canaux de produits SLES appropriés, le dépôt d'amorçage, la clé d'activation et les éléments de confiance déjà disponibles dans cet environnement.

Cette distinction est importante. L'« enregistrement client hors ligne » signifie généralement que l'hôte SLES ne peut pas accéder au SUSE Customer Center ni aux dépôts publics, mais qu'il peut accéder à un système SUSE Manager interne. Un déploiement SUSE Manager entièrement isolé du réseau pose un problème d'architecture plus complexe : le contenu des dépôts doit d'abord être importé dans l'environnement déconnecté à l'aide de méthodes de mise en miroir prises en charge. SUSE documente cette procédure séparément dans son guide d'installation hors ligne .

L'objectif de cette procédure n'est pas simplement de faire apparaître le client dans la liste des systèmes. Un résultat satisfaisant présente quatre signes visibles : l'hôte est enregistré avec la clé d'activation et le canal de base prévus, le client Salt est en cours d'exécution et communique avec le gestionnaire, les métadonnées des paquets proviennent de SUSE Manager et non de dépôts publics, et une action de gestion simple, telle qu'une actualisation ou une vérification d'état, s'exécute avec succès.

Que signifie « hors ligne » avant de commencer ?

Dans ce guide, le client SLES 15 n'a pas d'accès direct à Internet. Il peut se connecter au serveur SUSE Manager interne ou au proxy via le réseau grâce à son nom de domaine complet (FQDN). Le serveur SUSE Manager contient déjà le contenu SLES 15 requis, synchronisé. Si votre serveur SUSE Manager est déconnecté d'Internet, préparez et synchronisez ce contenu au préalable en suivant la procédure documentée par SUSE pour les environnements déconnectés, avant de tenter l'installation du client.

La documentation client actuelle de SUSE indique également que SLE 15 utilise Python 3 par défaut et que les scripts d'amorçage créés pour Python 2 doivent être régénérés. Après une mise à niveau ou une migration de SUSE Manager, il est également recommandé de régénérer les scripts d'amorçage avant l'intégration de nouveaux systèmes. Voir « Enregistrer des clients avec un script d'amorçage » .

Étape 1 : Vérifier que les canaux SLES corrects sont synchronisés.

Avant toute intervention sur le client, vérifiez que SUSE Manager dispose de la version SLES, du Service Pack, de l'architecture et des modules requis exacts pour cette machine. Par exemple, un hôte SLES 15 SP7 x86_64 ne doit pas être initialisé avec un contenu destiné à un Service Pack ou une architecture différents.

Dans l'interface web de SUSE Manager, vérifiez les canaux de produits et l'état de la synchronisation. Les noms de canaux varient selon la version et les modules activés ; ne copiez donc pas un nom de canal depuis un autre environnement sans l'avoir vérifié.

Vue d'ensemble du canal : vérifiez que la famille de produits SLES 15 et les modules requis sont synchronisés avant de créer le référentiel d'amorçage.

Contrôle qualité : le produit de base et tous les canaux requis par votre clé d’activation sont entièrement synchronisés. Si la synchronisation est incomplète, arrêtez-vous ici. L’enregistrement peut fonctionner partiellement, puis échouer si les packages clients requis ne peuvent pas être téléchargés.

Étape 2 : Confirmer ou générer le dépôt Bootstrap

Chaque client a besoin d'accéder à un dépôt d'amorçage contenant les paquets nécessaires à son installation initiale. SUSE Manager crée et régénère généralement ces dépôts automatiquement une fois les canaux de produits requis synchronisés, mais vous pouvez également en créer un manuellement.

Sur un serveur SUSE Manager 5.x conteneurisé, commencez par accéder au conteneur du serveur :

mgrctl term

Ensuite, listez les cibles de dépôt Bootstrap disponibles :

mgr-create-bootstrap-repo -l

Utilisez la liste des référentiels pour identifier la cible correspondant à la version SLES et à l'architecture que vous intégrez.

Créez le dépôt Bootstrap correspondant s'il est manquant ou s'il doit être régénéré :

mgr-create-bootstrap-repo -c SLE-version-x86_64

SUSE indique l'emplacement du dépôt Bootstrap sous /srv/www/htdocs/pub/repositories/. Si plusieurs produits partagent une base de code, l'outil peut vous demander de spécifier le canal parent approprié. La procédure actuelle est documentée dans le dépôt Bootstrap .

La réussite de la création du dépôt signifie que les packages initiaux Salt et d'enregistrement peuvent être servis depuis l'intérieur du réseau géré.

Quand changer d'approche : si le dépôt ne peut être généré en raison de l'absence de canaux obligatoires, ne tentez pas de contourner le problème en copiant des RPM aléatoires sur le client. Corrigez d'abord la synchronisation des produits ou l'importation de contenu déconnecté.

Étape 3 : Créer une clé d’activation avec l’attribution de canal souhaitée

Une clé d'activation est plus qu'un simple jeton d'enregistrement. Elle détermine des aspects importants du processus d'intégration, notamment les canaux logiciels et les groupes attribués au client. Créez une clé spécifique à la version SLES et au rôle que vous enregistrez.

Dans l'interface Web, ouvrez la configuration de la clé d'activation et vérifiez que son canal principal et ses canaux secondaires correspondent à la machine SLES cible. Évitez de réutiliser une clé créée pour un autre Service Pack, même si l'enregistrement réussit.

La clé d'activation doit associer le nouvel hôte SLES 15 aux canaux internes exacts que vous souhaitez qu'il utilise.

Contrôle qualité : la clé d’activation correspond à un canal de base unique et sans ambiguïté pour le système d’exploitation et l’architecture du client. Si plusieurs canaux parents rendent la correspondance ambiguë, corrigez-la avant d’exécuter le script d’amorçage.

Étape 4 : Générer un nouveau script Bootstrap

SUSE recommande d'utiliser cet outil mgr-bootstrappour créer un script d'enregistrement. Dans SUSE Multi-Linux Manager 5.1, les deux arguments obligatoires sont --activation-keyset --script.

mgrctl term
mgr-bootstrap --activation-keys=<ACTIVATION_KEY> --script=bootstrap-sles15-offline.sh

Le script généré peut également être créé depuis l'interface web, sous Administration > Configuration du gestionnaire > Script d'amorçage . Dans le cas d'une architecture basée sur un proxy, il est préférable de générer le script pour le nom de domaine complet (FQDN) du proxy plutôt que de modifier ultérieurement les références au serveur.

Générez un nouveau script lié à la clé d'activation et au serveur ou proxy que le client hors ligne peut effectivement atteindre.

Laissez le protocole SSL activé. SUSE déconseille formellement sa désactivation lors de la configuration initiale. Même sur un réseau isolé, la confiance accordée aux certificats reste essentielle, car le client doit vérifier qu'il communique bien avec le système de gestion prévu.

Étape 5 : Tester la résolution de noms, le routage et l’accessibilité du certificat depuis le client

Avant d'exécuter le script, testez le chemin interne entre SLES 15 et SUSE Manager. Les vérifications exactes dépendent de votre topologie, mais vérifiez au minimum la résolution DNS et l'accessibilité HTTPS vers le gestionnaire ou le nom de domaine complet (FQDN) du proxy utilisé par le script.

getent hosts suma.example.com
curl -I https://suma.example.com/pub/

Si l'environnement utilise la méthode de contact Salt par défaut, le client doit également pouvoir établir la connexion Salt requise avec le gestionnaire. La documentation SUSE relative à l'enregistrement manuel en ligne de commande indique les ports 4505 et 4506 pour la communication Salt. Voir « Enregistrer des clients en ligne de commande » .

L'étape de transfert doit utiliser l'adresse du gestionnaire interne ou du proxy ; l'accès direct à Internet n'est pas requis pour le client.

Contrôle qualité : le client résout le même nom de domaine pleinement qualifié (FQDN) intégré au script d’amorçage et peut y accéder sans recourir à une route publique. En cas d’échec, corrigez les problèmes de DNS, de pare-feu, de routage proxy ou de confiance de l’autorité de certification avant de poursuivre.

Étape 6 : Copiez le script d’amorçage dans le réseau isolé

Si le client peut accéder directement au service web SUSE Manager, téléchargez le script d'amorçage depuis ce dernier. Si le client se trouve sur un segment de réseau plus restrictif, transférez le fichier via un mécanisme interne autorisé, tel que SCP, par l'intermédiaire d'un serveur de rebond ou d'un support amovible. Le script lui-même ne dispense pas d'une connexion permanente au gestionnaire interne ; il gère uniquement la configuration initiale.

curl -O https://suma.example.com/pub/bootstrap/bootstrap-sles15-offline.sh
chmod 700 bootstrap-sles15-offline.sh

Lorsque le transfert HTTP direct est interdit, vérifiez la somme de contrôle du script après son passage dans votre processus de transfert contrôlé. Ceci est particulièrement utile dans les environnements isolés ou à haute sécurité.

Étape 7 : Exécutez le script d’amorçage en tant que superutilisateur (root) et surveillez les défaillances du dépôt ou du certificat.

Exécutez le script localement sur le client SLES :

sudo ./bootstrap-sles15-offline.sh

Le script installe les composants Salt requis, place les éléments de confiance, applique la clé d'activation et lance le processus d'intégration. Les noms exacts des paquets peuvent varier selon SUSE Manager et la version de SLES. La documentation SUSE actuelle utilise de plus en plus le Salt Bundle, venv-salt-miniontandis que certains chemins d'amorçage de SLES 15 peuvent commencer par un autre paquet salt-minionet évoluer ensuite au cours de l'intégration.

Surveillez la sortie de bootstrap pour détecter les erreurs de certificat, les paquets indisponibles, les incompatibilités de dépôt ou les problèmes de clé d'activation au lieu de juger du succès uniquement par la dernière ligne.

Vérification qualité : aucune erreur de résolution de paquets, aucun échec de confiance TLS et aucune référence à des dépôts publics inaccessibles au client hors ligne. Si le script tente d’utiliser des dépôts incorrects, reprenez les étapes 1 à 4 plutôt que de le relancer.

Étape 8 : Vérifiez le client dans SUSE Manager et testez le trafic de gestion.

Une fois l'intégration terminée, ouvrez « Systèmes » dans SUSE Manager et recherchez le nouveau client. Vérifiez son nom d'hôte, son canal de base, son groupe de systèmes et son état actuel. La présence d'un système listé est une étape nécessaire, mais ne constitue pas l'intégralité du test d'acceptation.

L'enregistrement est considéré comme terminé uniquement lorsque le système affiche l'attribution de canal attendue et que le client Salt reste actif.

Sur le client, vérifiez le nom du service qui correspond à la pile Salt installée :

systemctl status venv-salt-minion
# or, where applicable:
systemctl status salt-minion

Effectuez ensuite une action de gestion à faible risque depuis SUSE Manager, comme l'actualisation des données des paquets ou l'exécution d'une requête sans conséquence. Vérifiez que l'action est terminée et que le client se reconnecte ensuite.

Comment juger si l'inscription hors ligne est réellement efficace ?

Schémas de défaillance courants et leur signification habituelle

Le script ne peut pas télécharger de paquet

Commencez par comparer le dépôt d'amorçage et le canal de la clé d'activation avec la version SLES exacte du client. SUSE avertit que les informations du dépôt doivent correspondre au canal de base ; sinon, le processus d'amorçage ne pourra pas récupérer les paquets corrects.

Le client s'enregistre, mais les opérations sur les paquets échouent.

Vérifiez si des dépôts locaux subsistent d'une configuration précédente. Le processus d'amorçage Salt de SUSE est conçu autour des dépôts gérés par SUSE Manager, et les dépôts attribués localement peuvent perturber la gestion cohérente des canaux. Dans un environnement hors ligne, toute référence restante à un dépôt public est particulièrement susceptible d'échouer.

Le service Salt démarre mais le système reste inactif

Vérifiez la configuration DNS, la politique de pare-feu et le mode de contact. Si la connectivité Salt standard est impossible à travers le réseau, SUSE recommande l'utilisation de SSH Push comme alternative pour les clients situés dans des zones protégées par pare-feu ou déconnectées. Il s'agit d'une modification de conception, et non d'un simple ajustement au démarrage ; utilisez-la donc uniquement lorsque le modèle réseau l'exige.

Un script Bootstrap copié fonctionnait avant une mise à jour, mais ne fonctionne plus.

Régénérez-le. SUSE recommande de recréer les scripts d'amorçage après les migrations et lors de l'intégration de systèmes SLE 15 susceptibles d'hériter d'anciennes hypothèses Python.

Limites de cette méthode

Cette procédure ne fait pas apparaître comme par magie le contenu de SUSE Manager au sein d'un réseau isolé. Si le gestionnaire ne peut accéder à SUSE Customer Center, vous avez toujours besoin d'un flux de travail de contenu déconnecté pris en charge, tel que la mise en miroir assistée par RMT/SMT ou une autre méthode de synchronisation documentée. Le script d'amorçage ne remplace pas non plus l'accès réseau entre le client et son gestionnaire ou proxy interne après l'enregistrement.

Enfin, les noms des commandes et des services peuvent varier selon les générations de SUSE Manager et les Service Packs SLES. Cet article utilise la procédure d'installation de SUSE 5.x comme référence, mais vous devez vous référer à la documentation correspondant à la version exacte installée dans votre environnement.

Références officielles

• SUSE : Enregistrer des clients avec un script Bootstrap
• SUSE : dépôt Bootstrap
• SUSE : Enregistrement des clients en ligne de commande
• SUSE : Configuration déconnectée