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 :

getent ahosts cockpit-srv.example.net
curl -vI --connect-timeout 5 https://cockpit-srv.example.net:9090/
Exemple de recherche de terminal pour cockpit-srv.example.net renvoyant l'adresse d'exemple réservée 192.0.2.25
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'
Exemple de sortie de la commande systemctl status montrant que cockpit.socket est actif et écoute sur le port 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 :

sudo journalctl -u cockpit.socket -u cockpit.service -b --no-pager

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 :

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=ZONE --list-services
Exemples de commandes firewalld montrant la zone active et les services autorisés dans la zone publique
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 :

sudo firewall-cmd --zone=ZONE --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=ZONE --query-service=cockpit

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.

Terminal illustratif montrant la commande de vérification cockpit-certificate-ensure de SUSE dans une invite de commande.
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 :

sudo /usr/libexec/cockpit-certificate-ensure --check

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.

Laisser un commentaire

Activez le patchage en direct SLES et vérifiez une correction du noyau

Activez le patchage en direct SLES et vérifiez une correction du noyau

Configurez le chemin de mise à jour en direct approprié pour SLES 16.0 ou 15 SP7, appliquez les correctifs de noyau éligibles et confirmez ce qui est actif sans le confondre avec une mise à jour de noyau nécessitant un redémarrage.

Maintenir la disponibilité des services pendant une mise à niveau de SLES 15 SP5 vers SP6

Maintenir la disponibilité des services pendant une mise à niveau de SLES 15 SP5 vers SP6

SLES 15 SP5 peut être migré en ligne vers SP6, mais chaque nœud doit être redémarré. Utilisez une mise à niveau progressive éprouvée ou une bascule bleue-verte pour garantir la disponibilité des charges de travail.

Créer un profil AppArmor personnalisé sous SUSE Linux

Créer un profil AppArmor personnalisé sous SUSE Linux

Créer, affiner et vérifier un profil AppArmor à privilèges minimaux sur SLES 15 SP7, avec une note claire sur la valeur par défaut de SELinux de SLES 16.

Appliquez le STIG SLES 15 en toute sécurité avec OpenSCAP

Appliquez le STIG SLES 15 en toute sécurité avec OpenSCAP

Utilisez le profil STIG pris en charge par SUSE pour analyser SLES 15, tester la correction, examiner les résultats restants et conserver les preuves d'évaluation.

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

Tracez une connexion Cockpit défaillante via DNS, port 9090, socket systemd, firewalld, TLS et paramètres de connexion en utilisant les instructions SUSE actuelles.

Configurer un basculement Ethernet fiable avec l'agrégation de liens SLES 15

Configurer un basculement Ethernet fiable avec l'agrégation de liens SLES 15

Créez une connexion Ethernet redondante sur SLES 15 avec YaST et Wicked, configurez l'agrégation active-sauvegarde et vérifiez les deux ports et le basculement.

Créer un profil AutoYaST réutilisable pour les installations SLES 15

Créer un profil AutoYaST réutilisable pour les installations SLES 15

Transformez un système SLES 15 existant en un profil AutoYaST vérifié, validez-le et utilisez-le pour déployer un serveur de test avec moins d'étapes manuelles.

Configuration KVM de SLES 15 : Configurer les machines virtuelles sélectionnées pour qu’elles démarrent au démarrage du système.

Configuration KVM de SLES 15 : Configurer les machines virtuelles sélectionnées pour qu’elles démarrent au démarrage du système.

Installez les outils SLES 15 KVM et libvirt, activez le service hôte approprié et configurez les machines virtuelles sélectionnées pour qu'elles démarrent après un redémarrage.

Diagnostic d'un serveur SUSE bloqué sur l'écran d'arrêt de systemd

Diagnostic d'un serveur SUSE bloqué sur l'écran d'arrêt de systemd

Utilisez les tâches systemd et le journal de démarrage précédent pour localiser un service, un montage ou une dépendance de stockage lents, puis corrigez-les sans masquer la cause.

N'ouvrez que le trafic Web dont votre serveur SLES 15 a besoin.

N'ouvrez que le trafic Web dont votre serveur SLES 15 a besoin.

Utilisez firewall-cmd pour inspecter la zone active, autoriser HTTP en toute sécurité, préserver l'accès SSH et vérifier que la règle survit à un rechargement sur SLES 15.