Accueil
» Comment faire
»
Rétablir l'accès au cockpit sur le serveur SUSE Linux Enterprise
Rétablir l'accès au cockpit sur le serveur SUSE Linux Enterprise
Sur SUSE Linux Enterprise Server 16.0, le guide d'installation de Cockpit, publié le 8 octobre 2026, confirme le cockpitmodèle, l' cockpit.socketunité systemd et le port HTTPS par défaut 9090. Pour résoudre un problème de connexion à la console, vérifiez d'abord le DNS et l'accessibilité, puis le socket, le pare-feu, le certificat et le compte. Ces commandes d'installation sont spécifiques à SLES 16 ; sur une version antérieure de SLES, consultez les instructions relatives aux paquets et au pare-feu avant toute installation ou modification des règles.
Utilisez cet exemple hypothétique tout au long de ce document : Maya, administratrice système, ouvre une page https://cockpit-srv.example.net:9090depuis son poste de travail, mais le navigateur expire. L’hôte et toute adresse ou statut affiché sont donnés à titre d’illustration et ne constituent pas un compte rendu de test de serveur réel.
1. Distinguer une panne de nom ou de réseau d'une panne du cockpit
Commencez par le poste de travail de Maya. Vérifiez que le nom est résolu, puis testez le point de terminaison HTTPS avec un court délai d'attente :
L'exemple de résultat DNS utilise une adresse de documentation réservée ; vérifiez le nom d'hôte et l'adresse réels dans votre environnement.
Si la résolution de nom échoue ou renvoie une adresse obsolète, corrigez l'enregistrement DNS ou le résolveur du client avant d'utiliser Cockpit. Si curl signale « connexion refusée », cela signifie que l'hôte a répondu, mais qu'aucun serveur n'a accepté la connexion sur ce port, ou qu'un pare-feu l'a bloquée. Un délai d'attente dépassé indique généralement une interruption de trafic, un problème de routage ou un pare-feu en amont. Si curl atteint la connexion TLS et signale un avertissement de certificat, cela signifie que du trafic réseau a atteint Cockpit ; examinez le certificat plutôt que d'ouvrir d'autres ports.
Vérifiez que Maya utilise bien le nom d'hôte et le réseau de gestion prévus. Le port TCP 9090 est celui par défaut, mais il est personnalisable. Si l'accès direct est restreint, utilisez un serveur Cockpit principal approuvé pour accéder à l'hôte secondaire via SSH plutôt que d'exposer le port publiquement.
2. Vérifiez le paquet et le socket sur le serveur
Utilisez SSH ou une console locale pour vérifier le paquet Cockpit installé, le socket systemd et si quelque chose écoute sur le port 9090 :
sudo zypper se -i cockpit
sudo systemctl status cockpit.socket
sudo ss -ltnp 'sport = :9090'
Une écoute active cockpit.socketest attendue même lorsque le service Cockpit à la demande est inactif entre deux sessions de navigation.
Cockpit utilise l'activation des sockets systemd : cockpit.socketil accepte la connexion du navigateur et démarre le service web lorsque nécessaire. Par conséquent, une connexion inactive cockpit.servicen'indique pas nécessairement une panne. Si Cockpit est installé mais que le socket est inactif, démarrez-le et activez-le.
sudo systemctl enable --now cockpit.socket
Si le paquet est absent sur SLES 16, SUSE documente son installation sudo zypper in -t pattern cockpit. Ne présumez pas que ce modèle est disponible dans les dépôts configurés pour SLES 15 ou une autre version. Consultez les messages relatifs aux sockets et aux services avec :
Si le socket écoute localement mais que Maya expire toujours, vérifiez le pare-feu et le routage. S'il n'écoute pas, corrigez l'erreur de paquet ou de socket consignée dans le journal.
3. Autoriser l'accès via la zone de pare-feu appropriée
Sur SLES 16 avec firewalld activé, commencez par identifier la zone active et examinez les services autorisés :
Vérifiez la zone active réelle et ses services avant de modifier le pare-feu hôte ; la zone publique affichée n’est qu’un exemple.
Remplacez ZONEpar la zone associée à l'interface de gestion. Si Cockpit est absent et que cette zone est destinée à un accès d'administration sécurisé, ajoutez le service Cockpit et rechargez les règles :
Cette règle affecte toutes les sources autorisées par cette zone ; par conséquent, limitez la zone de gestion au réseau de l’administrateur. Vérifiez également les groupes de sécurité cloud, les listes de contrôle d’accès réseau, la politique VPN et les pare-feu en amont pour le port TCP 9090.
Le guide SUSE Cockpit pour SLES 16 documente également la procédure d'actualisation cockpit-selinux-policieset de redémarrage cockpit.socketdans le cadre de la configuration du pare-feu. Si vous utilisez SLES 16 et que la politique relative aux paquets/sockets ou à SELinux semble incohérente après avoir suivi les étapes de configuration du pare-feu, utilisez les commandes du guide SUSE correspondant :
sudo zypper in -f cockpit-selinux-policies
sudo systemctl restart cockpit.socket
N’appliquez pas cette étape de configuration à une autre version de SLES sans consulter ses instructions de configuration. Si l’accès direct aux ports est intentionnellement restreint, utilisez un hôte principal Cockpit approuvé et connectez-vous à la cible en tant que serveur secondaire via SSH plutôt que d’étendre le pare-feu de la cible.
4. Résoudre les avertissements TLS et les refus de connexion
Ouvrir Cockpit via HTTPS : https://cockpit-srv.example.net:9090Sous SLES 16, Cockpit génère un certificat auto-signé si aucun n'est installé. Un avertissement du navigateur concernant un émetteur inconnu ou une incohérence de nom indique un problème de confiance ou d'identité TLS, et non une défaillance de la connexion TCP. La désactivation de la vérification des certificats par le navigateur n'est pas une solution permanente.
La commande affichée vérifie quel certificat Cockpit utilisera ; cette illustration ne prétend pas fournir de résultat de vérification.
Examinez le certificat sélectionné par Cockpit à l'aide de la commande documentée par SUSE :
SLES 16 charge les certificats depuis un fichier/etc/cockpit/ws-certs.d ; une clé privée correspondante utilise le même nom de fichier de base avec un .keysuffixe. Pour les serveurs gérés, installez un certificat dont le nom alternatif du sujet correspond au nom d'hôte saisi par Maya, incluez sa chaîne intermédiaire et ajoutez l'autorité de certification émettrice à la liste des autorités de certification approuvées par le poste de travail. Si curl accède au service mais signale un certificat auto-signé, corrigez la confiance ou déployez un certificat approprié plutôt que de modifier le pare-feu.
Cockpit utilise les identifiants de compte habituels du serveur ; aucun mot de passe Cockpit spécifique n'est requis. Sur les nouvelles installations SLES, rootla connexion par mot de passe est désactivée par défaut. Si Maya accède à la page de connexion mais ne parvient pas à se connecter en tant que root, utilisez un compte utilisateur autorisé plutôt que d'activer la connexion par mot de passe root uniquement pour le dépannage de Cockpit. Les actions d'administration pourront ensuite être effectuées avec les privilèges autorisés de ce compte.
Vérifiez le chemin complet
Rechargez l'URL HTTPS depuis le poste de travail de Maya. Vérifiez que le DNS renvoie bien le serveur attendu, que le port TCP 9090 est accessible, que le certificat est valide et approuvé, et qu'un compte autorisé peut se connecter. Si l'écoute locale fonctionne mais que la requête distante expire, communiquez à l'équipe réseau les deux adresses, le port et la durée du test.
La documentation SUSE la plus récente concernant l'installation, le pare-feu, les certificats et l'authentification est le guide d'administration de Cockpit pour SLES 16.0 , publié le 8 octobre 2026. Pour plus d'informations sur le comportement général du protocole HTTPS et des certificats dans les différentes versions de Cockpit, consultez le guide SSL/TLS de Cockpit . La disponibilité exacte des paquets et l'intégration au pare-feu restent spécifiques à chaque version.