Version de cPanel & WHM : nouvelles fonctionnalités et stratégies de mise à jour sécurisées

Distinguer clairement cPanel et WHM

Bien que cPanel et WHM fassent partie du même produit, ils interviennent à des niveaux différents d'un serveur d'hébergement. cPanel Il s'agit de l'interface dédiée à un compte d'hébergement individuel : les clients y gèrent notamment leurs noms de domaine, leurs boîtes e-mail, leurs fichiers, leurs bases de données ainsi que les fonctionnalités de sécurité mises à leur disposition pour ce compte. Ce sont principalement les listes de fonctionnalités, les forfaits, le thème, les droits d'accès au compte et la configuration du fournisseur d'hébergement qui déterminent quelles sections sont visibles et utilisables.

WHM, quant à lui, constitue le niveau administratif du panneau d'hébergement. Les administrateurs de serveurs y configurent les comptes, les forfaits, les listes de fonctionnalités et les services à l'échelle du serveur, tandis que les fournisseurs d'hébergement géré définissent en outre des normes en matière de provisionnement, de mises à jour et d'assistance. Les revendeurs travaillent avec un espace WHM limité, en fonction des droits qui leur sont délégués ; cela ne leur donne pas automatiquement accès au système d'exploitation, aux services globaux ou à l'ensemble des politiques du serveur.

A Mise à jour de cPanel Cela ne concerne donc pas uniquement un nouvel affichage dans le compte client. Les modifications peuvent avoir une incidence sur l'attribution des thèmes, les fonctionnalités disponibles dans les modèles de forfait et les processus automatisés. Au niveau du système, il faut également tenir compte des interfaces, des contrôles d'accès, des extensions installées et de l'interaction avec le système d'exploitation. Le niveau de version (Release Tier) détermine la version du produit et la build qui seront mises à disposition pour le serveur, et non pas directement la visibilité des différentes fonctionnalités dans un compte client donné.

Prenons l'exemple concret de la mise en place de Meridian : si le thème est défini via un pack WHM, ce choix a une incidence sur l'interface des comptes nouveaux ou attribués. Si les scripts de provisionnement utilisent également des API ou si les guides d’assistance supposent des chemins de menu spécifiques, la politique de thème, le modèle de pack et l’automatisation doivent être vérifiés conjointement. Sinon, un changement de thème isolé peut avoir des conséquences fonctionnellement correctes, mais inattendues pour les clients et le service d’assistance.

Distinguer les versions, les builds et les niveaux de publication

Pour établir un planning de mises à jour fiable, il faut Version principale, les niveaux « Build » et « Release » doivent être considérés séparément. D’après les informations disponibles, cPanel & WHM 138 est la dernière version majeure de production publiée. La version 134 correspond à la branche LTS actuelle, qui bénéficie d’une période de support plus longue et prévisible. Bien que la version 136 explique l’origine de certaines modifications, la fin de son support régulier était déjà prévue pour août 2026 ; elle ne constitue donc pas une nouvelle cible de mise à niveau pertinente.

Une version majeure désigne une branche de publication, par exemple 138. Le numéro de build précise un état spécifique au sein de cette branche ; le journal des modifications répertorie, pour la version 138, les modifications apportées jusqu'au build 138.0.13. Cela ne signifie pas pour autant que chaque serveur reçoive cette version ou soit mis à jour vers la version 138. Le canal de distribution public utilisé par le serveur joue également un rôle déterminant.

Le Niveau de publication détermine le niveau de test et la fréquence de déploiement des mises à jour. Les versions LTS, STABLE, RELEASE, CURRENT et EDGE ne sont donc pas de simples étiquettes désignant la même version logicielle. Un serveur du niveau LTS peut délibérément se trouver sur une branche de version majeure différente de celle d’un système du niveau RELEASE, bien que la version majeure 138 soit généralement la plus récente en production.

Une prudence particulière s'impose avec les numéros de version dont le numéro principal est impair. Ceux-ci font partie de la version de développement de la branche EDGE et ne doivent pas être assimilés à une version de production publiée. Leur existence ne prouve ni que le développement est achevé, ni qu’elles sont adaptées aux serveurs des clients. Pour la gestion des changements et la communication avec le support technique, les administrateurs doivent donc toujours consigner conjointement la version installée, la build spécifique et le niveau (tier) sélectionné.

Pourquoi une mise à jour de cPanel nécessite une planification

A Changement de version Avec cPanel & WHM, il n'est pas possible d'annuler une mise à jour sans conséquences : la rétrogradation vers une version majeure antérieure ou un niveau de version antérieur n'est pas prise en charge. En cas de sauts importants, le programme de mise à jour passe par les versions intermédiaires nécessaires et vérifie la compatibilité avant chaque étape. Cela réduit les tentatives de mise à niveau inappropriées, mais ne remplace pas une vérification préalable par un expert de votre propre environnement.

Certaines conditions techniques peuvent bloquer une mise à jour ou déterminer son chemin d'accès. Parmi celles-ci figurent le système d'exploitation utilisé, un espace libre suffisant sous /usr/local/cpanel et les blocages actifs du gestionnaire de paquets. À titre d’exemple documenté, Ubuntu 22 ne peut pas être mis à jour vers cPanel & WHM 136. Ces remarques ne constituent pas une invitation à se rabattre sur une ancienne branche, mais une occasion de clarifier au préalable la version du système d’exploitation et la stratégie de migration prévue.

Outre le système de base, la mise à jour comprend une liste de contrôle opérationnelle. Les modifications documentées apportées aux autorisations de l'API SSL et aux aides de comptabilité supprimées indiquent que vos propres automatisations ou intégrations de facturation peuvent être concernées. Les modifications apportées à Meridian et CSF font également des attributions de thèmes, des listes de fonctionnalités, des ajustements du pare-feu local et des extensions associées des points de contrôle pertinents. Il ne s'agit pas de vérifications garanties par le programme de mise à jour, mais de dépendances que vous devez évaluer de manière ciblée dans votre environnement.

Par mesure de précaution, la mise à jour ne devrait être lancée qu’après avoir mis en place un plan de reprise adapté à votre environnement, vérifié au préalable l’état des sauvegardes et défini clairement les responsabilités de chacun. La documentation du fabricant recommande de tester dans un premier temps une nouvelle version majeure sur un système de test compatible ; ce n’est qu’après avoir effectué vos propres tests fonctionnels que la mise en production doit suivre de manière contrôlée. Étant donné qu’aucune rétrogradation n’est prévue, une éventuelle restauration à partir de sauvegardes ne doit pas être confondue avec le retour à un niveau de version antérieur.

Sélectionner les niveaux de mise en production en fonction de l'objectif opérationnel

Le niveau de version détermine la version de développement et de test attribuée à un serveur ; il s'agit donc d'une décision opérationnelle et non d'un simple paramètre pour les mises à jour automatiques. Pendant sa durée de vie, la version LTS se concentre sur les mises à jour de sécurité, les mises à jour critiques et celles liées à la compatibilité. STABLE est publié moins fréquemment que RELEASE, tandis que RELEASE est la norme documentée pour les nouvelles installations.

La branche CURRENT est mise à jour plus fréquemment et peut contenir des fonctionnalités encore en cours de développement. La branche EDGE ne fait l'objet que de tests de base et doit donc être utilisée exclusivement dans des environnements de test contrôlés. Les numéros de version principaux impairs désignent les versions de développement de la branche EDGE ; ils ne garantissent ni la maturité pour la production ni la disponibilité sûre d’une fonctionnalité particulière.

Pour l'hébergement mutualisé prépayé, LTS C'est judicieux lorsqu'un niveau de fonctionnalité prévisible à long terme prime sur une nouvelle interface ou des fonctionnalités d'automatisation précoces. Cela ne signifie pas pour autant de suspendre les mises à jour : les correctifs de sécurité et les corrections critiques continuent de faire partie de l'exploitation. RELEASE préconise l'utilisation de nouveaux serveurs, à condition que les dépendances aient été vérifiées au préalable et que des fenêtres de maintenance aient été prévues.

Le choix doit également être adapté à l'organisation des tests. Comme pour les autres panneaux d'hébergement, ce n'est pas un numéro de version en particulier qui est déterminant, mais l'interaction entre le panneau, les extensions, le système d'exploitation et la pile client. L'article Planifier de manière contrôlée les mises à jour de Plesk pour les fournisseurs d'hébergement illustre ce principe général pour une autre plateforme. Selon la documentation relative aux mises à jour, un délai de plusieurs jours ouvrés ne concerne que les mises à niveau automatiques vers la version majeure suivante dans le niveau RELEASE, et uniquement dans les conditions qui y sont mentionnées ; les niveaux EDGE, CURRENT, STABLE et LTS en sont exclus.

Découvrir les nouvelles fonctionnalités de la version 138

La version 138 apporte Méridien en tant qu'interface client. Pour les administrateurs WHM, ce n'est pas seulement la nouvelle mise en page qui importe : le choix du thème, l'attribution des packs, les listes de fonctionnalités, les supports de formation et les procédures d'assistance doivent être cohérents. Le niveau de version (Release Tier) détermine si la version requise du produit et de la build est disponible sur le serveur ; en revanche, les sections visibles par un compte donné dépendent principalement du thème, du pack, des listes de fonctionnalités et de la configuration du fournisseur.

Avec Meridian, une migration à grande échelle sans stratégie bien définie comporte des risques. Les comptes créés avec Meridian et n’ayant jamais utilisé Jupiter ne peuvent pas revenir d’eux-mêmes à Jupiter. Les administrateurs peuvent toutefois définir le thème via WHM, un pack ou l'API. C'est pourquoi les modèles de packs et la communication destinée à un petit groupe pilote doivent être coordonnés de manière contraignante avant le déploiement à grande échelle.

La fonction WHM-API-1 set_primary_domain_docroot permet de modifier le répertoire racine d'un domaine principal et a été rétroporté vers les versions 134 et 136. Cela facilite le provisionnement ou la migration, mais ne remplace pas une vérification de l'application. Un CMS, une redirection, des droits d’accès aux fichiers ou un script de déploiement peuvent toujours nécessiter l’ancien chemin d’accès ; une exécution réussie de l’outil de mise à jour ne détecte pas automatiquement cette hypothèse technique.

À partir de la version 138.0.10, les fonctions API permettant de récupérer des certificats SSL et des clés nécessitent la fonctionnalité sslinstall ou sslmanager. Les listes de fonctionnalités restreintes et les intégrations de facturation externes doivent donc faire l'objet d'une vérification ciblée. De plus, cPanel a supprimé les fichiers auxiliaires obsolètes de Cpanel/Accounting; les intégrations directes dans des solutions de facturation individuelles nécessitent une adaptation et ne constituent pas un cas de compatibilité résolu automatiquement.

La version 138.0.13 modifie également les exigences relatives à ACL des revendeurs lors de la configuration des serveurs de noms. Les revendeurs qui gèrent le clustering DNS peuvent avoir besoin du droit all, afin de modifier les paramètres des serveurs de noms du serveur. Avant la mise à jour, vérifie donc les modèles d'exploitation délégués, les rôles des revendeurs impliqués et les processus automatisés du cluster DNS. Ce privilège élargit considérablement les droits d'accès et ne doit pas être attribué de manière générale, mais uniquement après une vérification des rôles et de la sécurité.

Préparer les mises à jour avec inventaire et phase pilote

Avant la mise à jour, on commence par recenser l'état actuel : version installée, niveau de version, système d'exploitation, plugins tiers, appels à l'API propre à l'entreprise, paramétrages du pare-feu ainsi que les procédures de sauvegarde et de restauration. La version peut être déterminée dans le terminal sans modification du système. Cet inventaire relie les composants techniques à leurs responsables et évite que des dépendances floues n'apparaissent qu'après la mise à jour.

/usr/local/cpanel/cpanel -V

Pour une mise à niveau, cPanel nécessite au moins 5 Go d'espace libre dans le répertoire /usr/local/cpanel. Les verrous actifs du gestionnaire de paquets peuvent bloquer le processus ; le chemin d'accès au système d'exploitation peut également imposer des limites selon la version. Ces points doivent être traités avant la fenêtre de maintenance, tout comme une restauration dont le déroulement et les droits d'accès ont été clarifiés au préalable.

Vient ensuite Staging sur un système de test distinct et comparable. Les paquets, thèmes, plugins et intégrations API concernés y sont testés à l'aide de comptes de test simulés. Testez les processus types tels que la connexion, l'automatisation des certificats, le provisionnement et l'exploitation des applications. La documentation du fabricant recommande expressément de tester la mise à niveau sur un système de test avant de mettre à jour le système de production.

Une phase pilote de production doit être traitée séparément. Les comptes clients réels ne sont intégrés qu’après autorisation expresse, dans une mesure limitée, sous surveillance et avec un canal d’assistance clairement défini. Déterminez au préalable quels tests fonctionnels seront effectués, qui prendra les décisions en cas de panne et quelles mesures de reprise sont possibles pour le compte ou le serveur concerné. Un test sur des comptes simulés ne remplace pas cette autorisation d’exploitation ; inversement, un test client ne constitue pas une mise en scène sans risque.

Dans WHM, l’option „ Upgrade to Latest Version “ effectue la mise à jour vers la dernière version disponible du niveau de publication sélectionné. Cette fonction ne garantit donc pas le passage à la version majeure la plus récente en général. De plus, un délai automatique peut s’appliquer pour les versions RELEASE ; une mise à jour forcée permet de contourner ce délai. Les mesures opérationnelles liées à la sécurité concernant les accès, les sauvegardes et le pare-feu doivent être mises à jour parallèlement au processus de mise à jour ; les principes pratiques sont expliqués dans l'article Sécurité du panneau de contrôle d'hébergement dans WHM et cPanel.

Exploiter Meridian et CSF de manière contrôlée

Dans cPanel & WHM 138, Meridian est bien plus qu'une simple nouvelle vue client. Ce thème regroupe des tâches dans des domaines tels que les sites web, la messagerie électronique, les fichiers, les bases de données, la sécurité et les performances. Pour son utilisation, ce n’est donc pas seulement l’aspect visuel de l’interface qui compte, mais aussi la capacité des clients à continuer de trouver et d’exécuter sans ambiguïté les tâches prévues avec les fonctionnalités auxquelles ils ont souscrit.

Avant la validation, l'administrateur doit définir une Politique relative aux thèmes Définir : quels comptes reçoivent Meridian, quels modèles de pack attribuent ce thème, et quelles listes de fonctionnalités limitent certaines fonctions ? Ces paramètres vont de pair. Un pack peut certes spécifier un thème, mais une fonctionnalité absente de la liste des fonctionnalités restera néanmoins indisponible pour le compte correspondant.

D'un point de vue pratique, il est recommandé de constituer un groupe pilote restreint avec des forfaits représentatifs, par exemple un simple compte d'hébergement web, un compte avec plusieurs domaines et un scénario de revendeur. Vérifiez à cette occasion les processus d'assistance courants, tels que la gestion des boîtes mail, l'accès aux bases de données et la recherche de fonctionnalités de sécurité. La communication avec les clients doit préciser la date, les changements visibles et un canal d'assistance accessible, plutôt que d'annoncer le changement comme une simple modification cosmétique.

Le retour à Jupiter doit faire partie de cette planification. Les comptes créés avec Meridian et n'ayant jamais utilisé Jupiter ne peuvent pas revenir d'eux-mêmes à Jupiter. Les administrateurs peuvent toujours modifier le thème dans WHM, via un paquet ou par API. Il en résulte que l'attribution du thème et le processus correspondant doivent être définis avant que de nouveaux comptes ne soient créés par défaut avec Meridian.

CSF doit être considéré indépendamment de la version principale de cPanel & WHM. WebPros propose ce fork sous forme de paquet à version distincte pour les versions prises en charge de cPanel & WHM. cpanel-csf Prêt ; l'installation et la mise à jour s'effectuent via le gestionnaire de paquets de cPanel. La migration, annoncée précédemment, des installations CSF non prises en charge ou obsolètes vers la branche prise en charge a été rétroportée sur toutes les versions prises en charge de cPanel et WHM. Par conséquent, il n'est pas possible de déterminer de manière fiable la version de CSF à partir de la seule version de cPanel installée.

Pour effectuer ce test, tu dois disposer du logiciel installé Version du pack cPanel-CSF, le journal des modifications CSF séparé, l'état de la gestion des paquets et la configuration locale. Sauvegardez et comparez vos propres règles, listes d'autorisation et de refus, hooks, notifications, ainsi que les plugins ou scripts de déploiement. Vérifiez également si des outils externes nécessitent des fichiers ou des commandes provenant d’une installation antérieure de CSF. La version cPanel reste pertinente dans le contexte général de la mise à jour, mais ne remplace ni cette vérification des paquets ni l’évaluation de la configuration locale du pare-feu.

Identifier systématiquement les erreurs après la mise à jour

Si certaines fonctionnalités cessent de fonctionner après une mise à jour, l'analyse commence par le niveau de version (Release Tier) sélectionné et la version (build) effectivement installée. La version majeure la plus récente n'est pas automatiquement celle d'un serveur ; ce qui importe, c'est la version (build) fournie dans le niveau de version configuré. Notez également la date et l'heure, les comptes concernés et la fonctionnalité précise avant d'effectuer des modifications visant à corriger le problème présumé.

Ensuite, tu analyses les journaux de mise à jour et les éventuels Bloqueur de mise à jour . En cas de sauts de version importants, le programme de mise à jour passe par des versions intermédiaires et effectue des contrôles de compatibilité ; des blocages actifs du gestionnaire de paquets ou des chemins d'accès au système d'exploitation incorrects peuvent influencer le déroulement du processus. Une mise à niveau interrompue ou partiellement réussie ne justifie pas une répétition aveugle avec des options forcées, mais nécessite d’abord de clarifier la cause consignée dans le journal.

Vous testez ensuite les dépendances dans un ordre bien défini : d'abord vos propres appels à l'API WHM ou cPanel, puis les listes de fonctionnalités et les attributions de thèmes, suivies des plugins et des règles de pare-feu. De cette manière, le dépannage permet de distinguer une modification centrale des autorisations d’un compte client individuel ou d’une extension. Les modifications doivent être documentées de manière traçable et, dans la mesure du possible, testées dans un premier temps sur un environnement de staging ou un compte isolé.

Un cas concret de dysfonctionnement concerne les automatisations SSL : à partir de la version 138.0.10, les fonctions API permettant de récupérer des certificats SSL et des clés nécessitent la fonctionnalité sslinstall ou sslmanager. Si, après la mise à jour, un script ne fournit plus de données de certificat, vérifie donc d'abord la liste des fonctionnalités attribuées au compte et les autorisations de l'accès utilisé, et pas seulement le réseau ou le stock de certificats.

Même en cas de modification des répertoires racines des documents, un appel d'API réussi ne garantit pas pour autant le bon fonctionnement du site web. La fonction set_primary_domain_docroot Il est possible de définir le chemin d'accès du domaine principal, tandis que les configurations du CMS, les redirections, les droits d'accès aux fichiers, les paramètres des serveurs virtuels ou les scripts de déploiement continuent de pointer vers l'ancien chemin. Testez donc séparément la mise en ligne, l'espace d'administration et les opérations d'écriture de l'application.

Les intégrations comptables personnalisées peuvent également être concernées, car des fichiers d'aide PHP obsolètes provenant de Cpanel/Accounting ont été supprimés. Si un processus de facturation est essentiel à l'activité et qu'aucune adaptation compatible n'est disponible, il est plus judicieux de suspendre la maintenance ou de procéder à une restauration à partir d'une sauvegarde vérifiée plutôt que d'effectuer une nouvelle mise à jour forcée. La documentation du fabricant et les journaux constituent alors la base d'un plan d'adaptation solide.

Définir de manière contraignante la stratégie de mise à jour appropriée

Une stratégie de mise à jour viable commence par l'objectif opérationnel, et non par le numéro de version le plus élevé. Les facteurs décisifs sont la durée du support, les besoins en nouvelles fonctionnalités, l'impact attendu sur les clients, la capacité de test disponible, les dépendances vis-à-vis de tiers et les opérations de sécurité. Ces critères doivent être évalués pour chaque groupe de serveurs : un cluster d’hébergement mutualisé, une nouvelle plateforme gérée et un système de test interne présentent des risques et des rythmes de changement différents.

La version LTS est indiquée lorsqu'une stabilité prévisible à long terme prime sur l'ajout continu de nouvelles fonctionnalités. Pendant sa durée de vie, cette branche reçoit principalement des mises à jour de sécurité, des correctifs critiques et des mises à jour de compatibilité. La version LTS n'implique donc ni la suspension des mises à jour, ni ne remplace les tests de sauvegarde, de restauration et de dépendances. Pour les offres d’hébergement mutualisé bien établies, cette limitation des changements de fonctionnalités peut rendre l’assistance plus prévisible.

La version STABLE est publiée moins fréquemment que la version RELEASE et a fait l'objet de tests publics plus approfondis. RELEASE offre toutes les fonctionnalités et constitue la version standard pour les nouvelles installations. Ces deux options sont pertinentes lorsque de nouvelles fonctionnalités sont nécessaires, mais que des tests doivent être effectués avant un déploiement à grande échelle. Le choix entre ces deux niveaux dépend donc de ce qui est prioritaire pour la plateforme concernée : une disponibilité plus rapide ou une période de test supplémentaire.

CURRENT est mis à jour plus fréquemment et peut contenir des fonctionnalités encore en cours de développement. EDGE ne fait l'objet que de tests de base et est exclusivement destiné à des environnements de test contrôlés. Les numéros de version majeurs impairs correspondent à des versions de développement de la branche EDGE ; ils ne garantissent pas qu'une fonctionnalité soit suffisamment stable pour être déployée en production. Pour les serveurs de production des clients, EDGE ne constitue donc pas un raccourci vers des fonctionnalités antérieures.

Place la Politique de publication consignées par écrit : nombre d'animaux autorisés par classe de serveur, responsables des validations, étendue minimale du test de préproduction, fenêtres de maintenance et critères d'interruption. Un délai de plusieurs jours ouvrables s'applique exclusivement aux mises à niveau automatiques vers la version majeure suivante dans le niveau RELEASE, à condition que la mise à niveau ne soit pas lancée manuellement ou forcée et qu'elle ne saute qu'une seule version majeure. Les niveaux EDGE, CURRENT, STABLE, LTS et les versions fixes ne bénéficient pas de ce délai.

Parmi les erreurs typiques, on peut citer l'utilisation d'EDGE en production et la définition fixe de certains numéros de build dans /etc/cpupdate.conf, l'absence de phase de test et l'idée selon laquelle les versions LTS ne nécessiteraient pas de mises à jour de sécurité. Il est tout aussi problématique d'assimiler une exécution réussie du programme de mise à jour à une validation technique. Ce n’est qu’une fois que les fonctionnalités client, les automatisations, les plugins et les mécanismes de protection ont été testés dans toute l’étendue prévue qu’une mise à jour technique devient un changement opérationnel maîtrisé.