Rilascio di cPanel & WHM: nuove funzionalità e strategie di aggiornamento sicure

Distinguere chiaramente cPanel da WHM

Sebbene cPanel e WHM facciano parte dello stesso prodotto, gestiscono livelli diversi di un server di hosting. cPanel È l'interfaccia relativa a un singolo account di hosting: i clienti possono gestirvi, ad esempio, domini, caselle di posta elettronica, file, database e le funzioni di sicurezza abilitate per il proprio account. Quali aree sono visibili e utilizzabili dipendono principalmente dagli elenchi delle funzionalità, dai pacchetti, dal tema, dai diritti dell’account e dalla configurazione del provider di hosting.

WHM, invece, rappresenta il livello amministrativo del pannello di hosting. Gli amministratori di server vi configurano account, pacchetti, elenchi di funzionalità e servizi a livello di server, mentre i fornitori di hosting gestito definiscono inoltre gli standard relativi al provisioning, agli aggiornamenti e all’assistenza. I rivenditori operano, a seconda dei diritti delegati, con un’area WHM limitata; ciò non comporta automaticamente l’accesso al sistema operativo, ai servizi globali o a tutte le politiche del server.

A Aggiornamento di cPanel Non riguarda quindi solo una nuova schermata nell’account cliente. Le modifiche possono influire sull’assegnazione dei temi, sulle funzionalità disponibili nei modelli di pacchetto e sui flussi di lavoro automatizzati. A livello di sistema si aggiungono le interfacce, i controlli dei diritti, le estensioni installate e l’interazione con il sistema operativo. Il livello di rilascio (Release Tier) determina quale versione del prodotto e quale build saranno disponibili per il server, non direttamente la visibilità delle singole funzioni in un determinato account cliente.

Un esempio pratico è l’introduzione di Meridian: se il tema viene predefinito tramite un pacchetto WHM, questa scelta influisce sull’interfaccia degli account nuovi o assegnati. Se gli script di provisioning utilizzano contemporaneamente le API o se le guide di assistenza presuppongono determinati percorsi di menu, è necessario verificare congiuntamente la politica relativa ai temi, il modello di pacchetto e l’automazione. In caso contrario, una modifica isolata del tema potrebbe avere conseguenze funzionalmente corrette, ma inaspettate per i clienti e il supporto tecnico.

Distinguere tra versioni, build e livelli di rilascio

Per una pianificazione degli aggiornamenti affidabile è necessario che Versione principale, i livelli di build e release vanno considerati separatamente. Allo stato attuale, cPanel & WHM 138 è l’ultima versione principale di produzione rilasciata. La versione 134 è l’attuale ramo LTS con un periodo di supporto più lungo e pianificabile. Sebbene la versione 136 spieghi l’origine delle singole modifiche, il termine regolare del suo supporto era già previsto per agosto 2026; non rappresenta quindi una valida nuova destinazione di aggiornamento.

Una versione principale indica un ramo di rilascio, ad esempio 138. Il numero di build specifica una versione concreta all’interno di quel ramo; nel changelog sono documentate le modifiche apportate alla versione 138 fino alla build 138.0.13. Ciò non significa che ogni server riceva questa build o venga aggiornato alla versione 138. È determinante anche il canale di distribuzione pubblico utilizzato dal server.

Il sito Livello di rilascio determina il livello di collaudo e la frequenza con cui vengono distribuiti gli aggiornamenti. LTS, STABLE, RELEASE, CURRENT ed EDGE non sono quindi semplici etichette che indicano la stessa versione del software. Un server nel livello LTS può trovarsi intenzionalmente su un ramo di versione principale diverso rispetto a un sistema nel livello RELEASE, sebbene 138 sia generalmente l’ultima versione principale di produzione.

È necessario prestare particolare attenzione ai numeri di versione con numero principale dispari. Questi appartengono alla release di sviluppo del ramo EDGE e non sono da equiparare a una versione di produzione pubblicata. La loro esistenza non attesta né il completamento dello sviluppo né l’idoneità per i server dei clienti. Ai fini della gestione delle modifiche e della comunicazione con l’assistenza tecnica, gli amministratori dovrebbero quindi documentare sempre la versione installata, la build specifica e il livello (tier) selezionato.

Perché è necessario pianificare un aggiornamento di cPanel

A Cambio di versione In cPanel & WHM, l'operazione non può essere annullata senza conseguenze: il downgrade a una versione principale precedente o a un livello di rilascio precedente non è supportato. In caso di salti significativi, il programma di aggiornamento passa attraverso le versioni intermedie necessarie e verifica la compatibilità prima di ogni singolo passaggio. Ciò riduce i tentativi di aggiornamento non idonei, ma non sostituisce una verifica preliminare da parte di un tecnico del proprio ambiente.

Alcuni requisiti tecnici possono impedire l'esecuzione di un aggiornamento o determinarne il percorso. Tra questi figurano il sistema operativo in uso e una quantità sufficiente di spazio libero su /usr/local/cpanel e blocchi attivi da parte del gestore dei pacchetti. Un esempio documentato è il fatto che Ubuntu 22 non può essere aggiornato a cPanel & WHM 136. Tali indicazioni non costituiscono un invito a ricorrere a un ramo precedente, ma un motivo per chiarire in anticipo lo stato del sistema operativo e il percorso di migrazione previsto.

Oltre al sistema di base, l’aggiornamento include una lista di controllo operativa. Le modifiche documentate alle autorizzazioni dell’API SSL e alla rimozione degli strumenti di contabilità indicano che potrebbero essere interessate le automazioni o le integrazioni di fatturazione personalizzate. Le modifiche a Meridian e CSF rendono inoltre le assegnazioni dei temi, gli elenchi delle funzionalità, le personalizzazioni del firewall locale e le relative estensioni dei punti di controllo significativi. Non si tratta di verifiche garantite dal programma di aggiornamento, bensì di dipendenze che devi valutare in modo mirato nel tuo ambiente.

Come misura precauzionale aziendale, l’aggiornamento dovrebbe essere avviato solo se si dispone di un piano di ripristino adeguato al proprio ambiente, di un backup precedentemente verificato e di responsabilità chiaramente definite. La documentazione del produttore raccomanda di testare inizialmente una nuova versione principale su un sistema di prova compatibile; solo dopo aver effettuato i propri test funzionali si dovrebbe procedere in modo controllato all’implementazione in produzione. Poiché non è previsto un downgrade, un eventuale ripristino dai backup non deve essere confuso con il ripristino del livello di release precedente.

Selezionare i livelli di rilascio in base all'obiettivo operativo

Il livello di rilascio determina quale versione di sviluppo e di test viene installata su un server; si tratta quindi di una decisione operativa e non di una semplice impostazione per gli aggiornamenti automatici. Durante il suo ciclo di vita, LTS si concentra sugli aggiornamenti di sicurezza, critici e di compatibilità. STABLE viene rilasciata meno frequentemente rispetto a RELEASE, mentre RELEASE è lo standard documentato per le nuove installazioni.

CURRENT viene aggiornato più frequentemente e può contenere funzionalità ancora in fase di sviluppo. EDGE viene sottoposto solo a test di base e, pertanto, deve essere utilizzato esclusivamente in ambienti di test controllati. I numeri di versione principali dispari indicano le versioni di sviluppo nel ramo EDGE; non garantiscono né la maturità per la produzione né la disponibilità sicura di una singola funzionalità.

Per un hosting condiviso pianificabile è LTS È opportuno ricorrere a questa soluzione quando è più importante garantire un livello di funzionalità prevedibile a lungo termine piuttosto che disporre di una nuova interfaccia o di funzioni di automazione avanzate. Ciò non significa sospendere gli aggiornamenti: le correzioni di sicurezza e quelle critiche continuano a far parte delle operazioni di sistema. RELEASE è la scelta giusta per i nuovi server, a condizione che le dipendenze siano state verificate in anticipo e che siano state pianificate le finestre di manutenzione.

La scelta dovrebbe inoltre essere in linea con l’organizzazione dei test. Come per altri pannelli di hosting, non è determinante un singolo numero di versione, bensì l’interazione tra pannello, estensioni, sistema operativo e stack del cliente. L’articolo Pianificare in modo controllato gli aggiornamenti di Plesk per i provider di hosting illustra questo principio generale per un'altra piattaforma. Secondo la documentazione relativa agli aggiornamenti, un ritardo di diversi giorni lavorativi riguarda solo gli aggiornamenti automatici alla versione principale successiva nel livello RELEASE e solo alle condizioni ivi specificate; i livelli EDGE, CURRENT, STABLE e LTS ne sono esclusi.

Verifica le nuove funzionalità della versione 138

La versione 138 introduce Meridiano come interfaccia utente. Per gli amministratori WHM non è rilevante solo il layout modificato: la scelta del tema, l’assegnazione dei pacchetti, gli elenchi delle funzionalità, il materiale formativo e le procedure di assistenza devono essere coerenti tra loro. Il livello di rilascio (Release Tier) determina se la versione del prodotto e del build richiesta è disponibile sul server; quali aree sono visibili a un singolo account dipendono invece principalmente dal tema, dal pacchetto, dagli elenchi delle funzionalità e dalla configurazione del provider.

Con Meridian, una migrazione su larga scala senza una politica definita è rischiosa. Gli account creati con Meridian che non hanno mai utilizzato Jupiter non possono tornare autonomamente a Jupiter. Gli amministratori possono tuttavia impostare il tema tramite WHM, un pacchetto o l’API. Pertanto, i modelli dei pacchetti e la comunicazione con un piccolo gruppo pilota dovrebbero essere concordati in modo vincolante prima dell’introduzione su larga scala.

La funzione WHM-API-1 set_primary_domain_docroot È possibile modificare la radice dei documenti di un dominio primario; questa funzionalità è stata reintrodotta nelle versioni 134 e 136. Ciò semplifica il provisioning o la migrazione, ma non sostituisce la verifica dell’applicazione. Un CMS, un reindirizzamento, i permessi dei file o uno script di distribuzione potrebbero continuare a presupporre il percorso precedente; un'esecuzione riuscita dell'Updater non riconosce automaticamente questa ipotesi tecnica.

A partire dalla build 138.0.10, le funzioni API per il recupero dei certificati SSL e delle chiavi richiedono la funzionalità sslinstall oppure sslmanager. È quindi necessario verificare con attenzione gli elenchi di funzionalità limitate e le integrazioni di fatturazione esterne. Inoltre, cPanel ha rimosso i file di supporto obsoleti da Cpanel/Accounting; le integrazioni dirette con soluzioni di fatturazione personalizzate richiedono un adattamento specifico e non costituiscono un caso di compatibilità risolto automaticamente.

La build 138.0.13 modifica inoltre i requisiti relativi a ACL dei rivenditori nella configurazione dei server dei nomi. I rivenditori che gestiscono il clustering DNS potrebbero aver bisogno del privilegio all, per modificare le impostazioni dei server dei nomi del server. Prima dell'aggiornamento, verifica quindi i modelli operativi delegati, i ruoli dei rivenditori coinvolti e i processi automatizzati dei cluster DNS. Questo privilegio amplia notevolmente l'accesso e non dovrebbe essere assegnato in modo indiscriminato, ma solo dopo una verifica dei ruoli e della sicurezza.

Preparare gli aggiornamenti con l'inventario e la fase pilota

Prima dell’aggiornamento viene innanzitutto rilevato lo stato attuale: versione installata, livello di rilascio, sistema operativo, plugin di terze parti, chiamate alle API interne, configurazioni del firewall e procedure di backup e ripristino. La versione può essere verificata nel terminale senza apportare modifiche al sistema. Questo inventario mette in relazione i componenti tecnici con i rispettivi responsabili ed evita che dipendenze poco chiare emergano solo dopo l’aggiornamento.

/usr/local/cpanel/cpanel -V

Per eseguire un aggiornamento, cPanel richiede almeno 5 GB di spazio libero in /usr/local/cpanel. Eventuali blocchi attivi da parte dei gestori di pacchetti possono ostacolare il processo; anche il percorso del sistema operativo può imporre dei limiti a seconda della versione. Questi aspetti devono essere affrontati prima della finestra di manutenzione, così come un ripristino le cui procedure e i cui diritti di accesso siano stati chiariti in anticipo.

Segue poi Messa in scena su un sistema di test separato e comparabile. Qui vengono verificati i pacchetti, i temi, i plugin e le integrazioni API rilevanti utilizzando account di test simulati. Verifica i flussi di lavoro tipici quali l'accesso, l'automazione dei certificati, il provisioning e il funzionamento delle applicazioni. La documentazione del produttore raccomanda espressamente di eseguire l’aggiornamento in ambiente di test prima di aggiornare il sistema di produzione.

La fase pilota di produzione deve essere trattata separatamente. Gli account dei clienti reali vengono coinvolti solo previa espressa autorizzazione, con portata limitata, monitoraggio e un canale di assistenza ben definito. Definisci in anticipo quali test funzionali verranno effettuati, chi prenderà le decisioni in caso di guasto e quali misure di ripristino sono possibili per il rispettivo account o server. Un test su account simulati non sostituisce questa autorizzazione operativa; viceversa, un test sul cliente non costituisce uno staging privo di rischi.

In WHM, l’opzione „Upgrade to Latest Version“ esegue l’aggiornamento all’ultima build del livello di rilascio selezionato. La funzione non garantisce quindi il passaggio alla versione principale più recente in assoluto. Inoltre, per RELEASE può essere applicato un ritardo automatico; un aggiornamento forzato lo aggira. Le misure operative relative alla sicurezza riguardanti accessi, backup e firewall dovrebbero essere gestite parallelamente al processo di aggiornamento; le nozioni pratiche di base sono illustrate nell’articolo Sicurezza del pannello di controllo dell'hosting in WHM e cPanel.

Gestire Meridian e CSF in modo controllato

In cPanel & WHM 138, Meridian è molto più di una semplice nuova interfaccia per i clienti. Il tema raggruppa le attività in aree quali siti web, e-mail, file, database, sicurezza e prestazioni. Per il funzionamento, quindi, non conta solo che l’interfaccia sia esteticamente gradevole, ma anche che i clienti possano continuare a individuare e eseguire chiaramente le attività previste con le funzioni da loro sottoscritte.

Prima dell'approvazione, l'amministratore dovrebbe redigere un documento vincolante Politica sui temi Definire: quali account ricevono Meridian, a quali modelli di pacchetto viene assegnato il tema e quali elenchi di funzionalità limitano le singole funzioni? Queste impostazioni sono correlate. Un pacchetto può sì specificare un tema, ma una funzione mancante nell’elenco delle funzionalità rimane comunque non disponibile per l’account corrispondente.

In pratica, è consigliabile un gruppo pilota limitato con tariffe rappresentative, ad esempio un semplice account di web hosting, un account con più domini e uno scenario di rivendita. Verifica i canali di assistenza tipici, come la gestione delle caselle di posta, l’accesso al database e la ricerca delle funzionalità di sicurezza. La comunicazione ai clienti dovrebbe specificare la tempistica, le modifiche visibili e un canale di assistenza accessibile, anziché annunciare il cambiamento come se fosse puramente estetico.

Il ritorno a Jupiter deve far parte di questa pianificazione. Gli account creati con Meridian che non hanno mai utilizzato Jupiter non possono tornare a Jupiter autonomamente. Gli amministratori possono comunque modificare il tema in WHM, tramite un pacchetto o tramite API. Ne consegue che l’assegnazione del tema e il processo responsabile devono essere definiti prima che i nuovi account vengano creati di default con Meridian.

CSF va considerato separatamente dalla versione principale di cPanel e WHM. WebPros mette a disposizione il fork sulle versioni supportate di cPanel e WHM come pacchetto con versioning separato. cpanel-csf Pronto; l'installazione e l'aggiornamento avvengono tramite il gestore dei pacchetti di cPanel. La migrazione, annunciata in precedenza, delle installazioni CSF non supportate o obsolete verso il fork supportato è stata retroportata su tutte le versioni supportate di cPanel e WHM. Pertanto, non è possibile determinare in modo affidabile lo stato di CSF basandosi esclusivamente sulla build di cPanel installata.

Come base di prova ti serve il programma installato Stato del pacchetto cPanel-CSF, il changelog separato di CSF, lo stato della gestione dei pacchetti e la configurazione locale. Esegui il backup e confronta le regole personalizzate, gli elenchi di autorizzazioni e di blocchi, gli hook, le notifiche, nonché i plugin o gli script di distribuzione. Verifica inoltre se strumenti esterni richiedono file o comandi di una precedente installazione di CSF. La build di cPanel rimane rilevante nel contesto generale dell’aggiornamento, ma non sostituisce né questa verifica dei pacchetti né la valutazione della configurazione locale del firewall.

Individuare sistematicamente gli errori dopo l'aggiornamento

Se, a seguito di un aggiornamento, alcune funzioni smettono di funzionare, l’analisi inizia dal livello di release selezionato e dalla build effettivamente installata. La versione principale più recente in generale non corrisponde automaticamente allo stato di un server; ciò che conta è quale build sia stata fornita nel livello configurato. Prendi inoltre nota della data, degli account interessati e della funzione specifica prima di apportare modifiche volte alla presunta risoluzione del problema.

Successivamente, analizzerai i registri degli aggiornamenti e le possibili Blocco aggiornamenti . In caso di salti di versione significativi, il programma di aggiornamento passa attraverso le versioni intermedie ed esegue controlli di compatibilità; eventuali blocchi attivi da parte del gestore di pacchetti o percorsi del sistema operativo non corretti possono influenzare il processo. Un aggiornamento interrotto o completato solo parzialmente non giustifica una ripetizione cieca con opzioni forzate, ma richiede innanzitutto il chiarimento della causa registrata nel log.

Successivamente, verifica le dipendenze seguendo un ordine prestabilito: prima le chiamate alle API WHM o cPanel, poi gli elenchi delle funzionalità e le assegnazioni dei temi, quindi i plugin e le regole del firewall. In questo modo, la ricerca degli errori consente di distinguere una modifica centrale delle autorizzazioni da un singolo account cliente o da un’estensione. Le modifiche dovrebbero essere documentate in modo tracciabile e, se possibile, testate inizialmente su un ambiente di staging o su un account isolato.

Un caso specifico di errore riguarda le automazioni SSL: a partire dalla build 138.0.10, le funzioni API per il recupero dei certificati SSL e delle chiavi richiedono la funzionalità sslinstall oppure sslmanager. Se, dopo l'aggiornamento, uno script non fornisce più i dati relativi ai certificati, verifica innanzitutto l'elenco delle funzionalità assegnate all'account e le autorizzazioni dell'accesso utilizzato, non solo la rete o l'inventario dei certificati.

Anche in caso di modifiche alle radici dei documenti, una chiamata API riuscita non garantisce di per sé il corretto funzionamento del sito web. La funzione set_primary_domain_docroot È possibile impostare il percorso del dominio principale, mentre le configurazioni del CMS, i reindirizzamenti, i permessi sui file, le impostazioni dei virtual host o gli script di distribuzione continuano a puntare al vecchio percorso. Si consiglia quindi di testare separatamente la visualizzazione, l'area di amministrazione e le operazioni di scrittura dell'applicazione.

Anche le integrazioni contabili configurate individualmente potrebbero essere interessate dal problema, poiché i file di supporto PHP obsoleti presenti in Cpanel/Accounting sono stati rimossi. Se un processo di fatturazione è fondamentale per l’attività e non è disponibile alcuna modifica compatibile, è più opportuno sospendere la manutenzione o eseguire un ripristino da un backup verificato piuttosto che procedere con un ulteriore aggiornamento forzato. La documentazione del produttore e i log costituiscono quindi la base per un piano di adeguamento solido.

Definire in modo vincolante la strategia di aggiornamento adeguata

Una strategia di aggiornamento sostenibile parte dall’obiettivo operativo, non dal numero di versione più alto visibile. Sono determinanti il periodo di supporto, la necessità di nuove funzionalità, l’impatto previsto sui clienti, la capacità di test disponibile, le dipendenze da fornitori terzi e le operazioni di sicurezza. Questi criteri devono essere valutati per ciascun gruppo di server: un cluster di hosting condiviso, una nuova piattaforma gestita e un sistema di test interno presentano rischi e ritmi di aggiornamento diversi.

LTS è indicato quando è più importante poter pianificare a lungo termine rispetto all’introduzione continua di nuove funzionalità. Durante il suo ciclo di vita, questo ramo riceve principalmente aggiornamenti di sicurezza, correzioni critiche e aggiornamenti di compatibilità. LTS non implica quindi né la sospensione degli aggiornamenti, né sostituisce i test di backup, ripristino e dipendenza. Per le offerte di hosting condiviso consolidate, questa limitazione delle modifiche funzionali può rendere il supporto più prevedibile.

La versione STABLE viene rilasciata meno frequentemente rispetto alla RELEASE ed è stata sottoposta a un numero maggiore di test pubblici. RELEASE è completa dal punto di vista funzionale e rappresenta lo standard per le nuove installazioni. Entrambe sono opzioni valide quando sono necessarie nuove funzionalità, ma prima dell’introduzione su larga scala vengono effettuati dei test. La scelta tra i due livelli dipende quindi dal fatto che per la piattaforma in questione sia più importante una disponibilità anticipata o un periodo di test aggiuntivo.

CURRENT viene aggiornato più frequentemente e può contenere funzionalità ancora in fase di sviluppo. EDGE viene sottoposto solo a test di base ed è destinato esclusivamente ad ambienti di test controllati. I numeri di versione principali dispari corrispondono a release di sviluppo nel ramo EDGE; non indicano che una funzionalità sia disponibile in modo stabile per la produzione. Per i server di produzione dei clienti, EDGE non rappresenta quindi una scorciatoia per accedere a funzionalità precedenti.

Metti il Politica di rilascio definito per iscritto: numero consentito di istanze per classe di server, responsabili delle autorizzazioni, portata minima del test di staging, finestre di manutenzione e criteri per l’interruzione. Un ritardo di diversi giorni lavorativi si applica esclusivamente agli aggiornamenti automatici alla versione principale successiva nel livello RELEASE, a condizione che l’aggiornamento non venga avviato manualmente o forzato e che salti solo una versione principale. EDGE, CURRENT, STABLE, LTS e le versioni fissate in modo definitivo non sono soggette a tale ritardo.

Esempi tipici di decisioni errate sono l’uso di EDGE in produzione e la definizione fissa di singoli numeri di build in /etc/cpupdate.conf, la mancanza di una fase di staging e il presupposto che le versioni LTS non richiedano aggiornamenti di sicurezza. Altrettanto problematico è equiparare il corretto completamento di un’operazione di aggiornamento all’approvazione tecnica. Solo quando le funzionalità per i clienti, le automazioni, i plugin e i meccanismi di protezione sono stati verificati nella misura prevista, un aggiornamento tecnico si trasforma in un cambio operativo controllato.