Un serveur sans accès Internet direct peut recevoir des correctifs KernelCare par une architecture adaptée. Cela nécessite toutefois une source de correctifs accessible, une licence appropriée et un processus de mise à jour suivi. L’isolement du réseau ne fournit pas, à lui seul, les nouveaux correctifs.
Ce guide aide les responsables d’un serveur ou d’une infrastructure à préparer ce fonctionnement. Si vous utilisez simplement un hébergement partagé, faites vérifier la situation par votre fournisseur plutôt que de tenter d’installer un agent ou de modifier le réseau.
Choisir le bon chemin de distribution
- Accès sortant contrôlé : un serveur peut joindre les services nécessaires par une passerelle ou un proxy approuvé. Une adresse privée ne signifie donc pas forcément une absence d’accès Internet.
- Distribution interne : ePortal centralise les correctifs pour les machines qui peuvent le joindre sur le réseau privé. Les accès externes peuvent être concentrés sur cette infrastructure.
- Environnement complètement déconnecté : prévoyez un transfert contrôlé de correctifs obtenus depuis une source autorisée. Un cache existant ne suffit pas pour recevoir des correctifs encore inconnus.
La documentation officielle d’ePortal décrit la distribution et l’importation de correctifs. Son mode cache récupère certains contenus à la demande : il ne constitue pas, à lui seul, une solution autonome pour un réseau entièrement déconnecté.
Valider les prérequis avant le déploiement
- Compatibilité : identifiez la distribution, l’architecture et le noyau réellement utilisé. Faites confirmer leur prise en charge; le nom de la distribution ne suffit pas.
- Licences : confirmez les droits KernelCare, l’accès ePortal, les produits couverts et le nombre de serveurs. Le portail d’abonnement TuxCare distingue licences et clés d’activation. Ne supposez pas qu’une licence liée à une adresse IP couvre plusieurs machines derrière la même passerelle.
- Exploitation : désignez qui obtient les correctifs, contrôle leur provenance, les transfère, autorise leur diffusion et traite les échecs.
- Continuité : prévoyez le stockage, la supervision, la sauvegarde de l’infrastructure de gestion et une procédure de reprise. Documentez aussi les responsabilités en cas d’indisponibilité.
Suivre les correctifs jusqu’aux serveurs
Un fichier téléchargé ou une machine visible dans une console ne démontre pas que le correctif est appliqué. Pour chaque noyau concerné, vérifiez la disponibilité du correctif, son autorisation dans le canal prévu, son application et la fraîcheur du dernier contrôle. Un déploiement progressif demande un responsable et des critères de passage entre validation et production.
Maintenez aussi l’agent et ePortal à des versions compatibles. TuxCare a notamment introduit un format de correctifs signés nécessitant des composants adaptés. Ne contournez pas une vérification de signature pour importer une archive.
Comprendre les limites du live patching
KernelCare traite les correctifs disponibles pour les noyaux pris en charge. Cela ne remplace ni les mises à jour de PHP, des applications et des extensions, ni les sauvegardes. Les nouvelles fonctions du noyau et certains changements exigent encore une maintenance classique. TuxCare rappelle que des redémarrages peuvent rester nécessaires. Les autres produits de live patching ont leur propre couverture et leurs droits d’utilisation.
Pour un problème de communication, consultez notre guide des connexions KernelCare. Pour évaluer une architecture privée ou clarifier la gestion de votre service, contactez Nuagerie avec vos contraintes et le résultat attendu, sans clé de licence ni identifiant de proxy.
