Une erreur de communication KernelCare peut empêcher la récupération de correctifs, même si le site web reste accessible. Le diagnostic dépend du chemin utilisé : accès direct aux services TuxCare, proxy ou ePortal interne. Une règle limitée au port 80 d’un seul serveur ne décrit pas ces configurations.
Ces vérifications s’adressent à l’administrateur responsable. Sur un service géré par Nuagerie, signalez l’erreur avant de modifier les résolveurs DNS, le pare-feu ou l’enregistrement de licence.
Identifier les destinations réellement utilisées
La documentation KernelCare distingue notamment, pour une configuration directe courante :
cln.cloudlinux.compour les échanges liés à l’enregistrement et aux licences;patches.kernelcare.compour les correctifs;repo.cloudlinux.compour les paquets d’installation ou de mise à jour de l’agent.
Avec ePortal, les clients peuvent utiliser l’adresse interne configurée, tandis qu’ePortal accède à ses propres sources. La documentation ePortal décrit notamment downloads.kernelcare.com, les dépôts et les destinations conditionnelles. Les URL personnalisées et les fonctions activées doivent aussi être prises en compte.
Ces exemples ne constituent pas une liste complète de règles de pare-feu. Les échanges HTTPS utilisent généralement TCP 443, mais l’adresse et le port d’un proxy ou d’un service interne dépendent de votre configuration. Les dépôts du système et les autres dépendances peuvent ajouter des besoins distincts. Ne créez pas d’accès d’administration entrant depuis Internet pour résoudre un problème de téléchargement sortant.
Contrôler chaque étape du chemin réseau
- DNS : vérifiez que l’environnement de l’agent résout la destination prévue. Un nom ePortal privé doit utiliser le chemin DNS interne approprié. Notre guide de diagnostic des erreurs de résolution distingue une panne DNS d’autres erreurs réseau.
- Connexion : examinez routage, filtrage sortant et accès au proxy depuis le serveur concerné. Un test réussi depuis un poste de travail ne valide pas ce chemin.
- TLS : vérifiez le nom présenté, la validité du certificat, la chaîne de confiance et l’horloge. Si une inspection HTTPS intervient, faites valider la configuration par son responsable. Ne désactivez pas la vérification des certificats.
- Proxy : comparez la configuration réellement utilisée par l’exécution automatique avec celle du terminal. Un proxy défini dans une session interactive peut manquer dans la tâche planifiée. Gardez ses identifiants confidentiels.
- Redirections : identifiez les destinations finales des dépôts. TuxCare documente des redirections vers des miroirs et des CDN; une adresse IP figée ou une liste de noms incomplète peut bloquer le téléchargement. Faites adapter la politique réseau au périmètre validé, sans ouverture générale.
Distinguer connexion, autorisation et application
Un délai dépassé, une erreur TLS et un refus HTTP 401 ou 403 n’appellent pas la même correction. Un refus peut provenir du service ou d’un intermédiaire. Vérifiez l’étape précise et la destination, puis faites examiner les droits et la licence sans supprimer ni réenregistrer celle-ci à répétition.
TuxCare décrit un cas de refus du téléchargement malgré une licence indiquée valide. Inversement, recevoir les métadonnées ne prouve pas que le fichier du correctif a été obtenu et appliqué. Contrôlez le résultat sur le noyau concerné et la date du dernier succès.
Transmettre les informations utiles
Notez l’heure, l’étape en échec, le message, les versions de l’agent et du système ainsi que le recours éventuel à un proxy ou ePortal. Retirez clés, mots de passe et données privées avant de joindre des extraits à une demande dans votre espace client. Ne lancez pas automatiquement un outil qui transmet un rapport au fournisseur.
Pour un réseau sans accès direct, consultez notre guide KernelCare et ePortal en environnement isolé. Pour une infrastructure externe, contactez Nuagerie afin de définir le diagnostic et les responsabilités.
