Installare cPanel/WHM su AlmaLinux 9 passo dopo passo

Prerequisiti reali prima di partire

cPanel/WHM su AlmaLinux 9 non è un’installazione “click-next” da fare su una macchina qualsiasi. Il punto critico è partire da un sistema pulito, con hostname corretto, DNS coerente e niente stack web o mail già attivi che si pestino i piedi con i servizi di cPanel.

Il caso tipico che crea problemi è il server appena provisionato con pacchetti extra, repository terzi, firewall già molto personalizzato o una configurazione di rete improvvisata. Se vuoi evitare metà dei ticket post-installazione, tratta l’installazione come un change controllato: prima osservi, poi modifichi, poi verifichi.

Serve un AlmaLinux 9 minimale, accesso root o sudo completo, un IP pubblico statico, e un hostname FQDN valido. In produzione conviene anche avere una finestra di manutenzione e un snapshot della VM o un backup del provider. Non è un dettaglio: se qualcosa va storto, il rollback più rapido è tornare all’immagine precedente.

Controlli preliminari che evitano errori banali

Prima di lanciare l’installer, verifica tre cose: nome host, risoluzione DNS e versione del sistema. Sono i punti che più spesso bloccano l’installazione o generano un WHM funzionante solo a metà.

Esegui questi controlli:

hostnamectl status
cat /etc/redhat-release
getent hosts $(hostname -f)

Il risultato atteso è un hostname completo, una release coerente con AlmaLinux 9 e una risoluzione che ritorna l’IP corretto del server. Se hostname -f non restituisce un FQDN valido, correggi prima quello: cPanel usa l’hostname come base per certificati, servizi e notifiche.

Controlla anche che non ci siano servizi web o mail preinstallati. Su sistemi “sporchi” trovi spesso Apache, Nginx, MariaDB, Dovecot o Postfix già configurati in modo non compatibile con il layout che cPanel si aspetta. Non sempre è un blocco immediato, ma quasi sempre è una fonte di ambiguità.

Architettura minima: cosa fa cPanel e cosa non deve trovare

WHM è il pannello amministrativo, cPanel è il pannello utente. Sul server, l’installer porta dentro un insieme di componenti: web server, mail stack, DNS, FTP, database, servizi di monitoraggio e gli strumenti di gestione. Il punto non è “installare un pannello”, ma accettare che il pannello diventi il gestore principale di quei servizi.

Per questo motivo è sconsigliato installarlo sopra un host già usato per altro, a meno di sapere esattamente quali servizi vuoi sacrificare o migrare. Se il nodo ospita già applicazioni custom con configurazioni manuali, il rischio non è il crash immediato: è la deriva lenta, con file sovrascritti, service unit modificate e troubleshooting inutile dopo qualche settimana.

In pratica: cPanel vuole essere il centro di gravità del server. Se il server è già “di tutti”, prima si ripulisce, poi si installa.

Step 1: aggiorna il sistema e riduci il rumore

Parti da un aggiornamento completo. Non perché “sia buona norma” in astratto, ma perché riduce la distanza tra kernel, librerie e dipendenze che l’installer dovrà sistemare.

dnf -y update
reboot

Dopo il reboot, conferma che il sistema sia tornato pulito e che non ci siano errori evidenti all’avvio:

systemctl --failed
journalctl -p err -b --no-pager | tail -n 50

Se trovi unità fallite, non ignorarle. Un server con problemi di base prima dell’installazione di cPanel tende a trasformare piccoli warning in problemi operativi più difficili da leggere dopo.

Step 2: imposta hostname, FQDN e risoluzione corretta

L’hostname deve essere un FQDN stabile, del tipo server1.example.com. Evita nomi generici come localhost, alias ambigui o hostnames che puntano a record DNS non ancora pubblicati.

hostnamectl set-hostname server1.example.com
hostname -f

Controlla poi /etc/hosts. In molti ambienti l’installer funziona meglio se il FQDN risolve localmente verso l’IP del server, senza dipendere solo dal DNS esterno.

cat /etc/hosts

Un esempio coerente è questo:

203.0.113.10 server1.example.com server1

Se il server è dietro NAT o in un cloud con IP privato e pubblico separati, definisci bene quale IP deve comparire nell’hostname e quale nei record DNS. Qui non si improvvisa: WHM e i servizi di mail soffrono molto più di altri stack quando l’identità di rete è incoerente.

Step 3: prepara il sistema senza installazioni inutili

La regola pratica è semplice: meno roba c’è prima dell’installazione, meno conflitti avrai dopo. Se il sistema è stato creato con un template generico, verifica e rimuovi i servizi che non servono.

dnf list installed | egrep 'httpd|nginx|mariadb|mysql|postfix|dovecot|bind|named|vsftpd'

Se trovi componenti già presenti e non necessari, la scelta corretta è decidere prima se vuoi davvero migrare su cPanel oppure rifare il nodo. Disinstallare alla cieca su un host in uso è un’operazione a rischio, soprattutto se ci sono dati o configurazioni da preservare.

Per un’installazione pulita, il controllo più utile è anche quello delle porte in ascolto:

ss -tulpn

Se vedi servizi inattesi su 80, 443, 25, 53 o 3306, fermati e chiarisci la baseline. È molto più semplice correggere prima che cPanel inizi a installare i propri demoni.

Step 4: scarica e lancia l’installer ufficiale

Il metodo standard resta l’installer ufficiale. Va eseguito come root e richiede connettività verso i repository e i mirror di cPanel.

cd /home
curl -o latest -L https://securedownloads.cpanel.net/latest
sh latest

Durante l’installazione possono comparire lunghi periodi senza output apparente: non è necessariamente un blocco. Il processo scarica pacchetti, prepara dipendenze e costruisce la configurazione iniziale. Se vuoi osservare il progresso, tieni aperto un secondo terminale e monitora i log dell’installer.

tail -f /var/log/cpanel-install.log

In caso di errore, il log è la prima fonte da leggere, non il browser. È lì che trovi il pacchetto fallito, la dipendenza mancante o il problema di rete. Se il download si interrompe, verifica anche DNS e reachability verso l’esterno:

curl -I https://securedownloads.cpanel.net/
ping -c 3 1.1.1.1
getent hosts securedownloads.cpanel.net

Step 5: primo accesso a WHM e verifica delle porte

A installazione completata, l’accesso avviene su WHM via HTTPS, tipicamente sulla porta 2087. Il primo login richiede credenziali di root o un utente amministrativo autorizzato.

Verifica che il servizio stia ascoltando:

ss -tulpn | egrep ':2087|:2083|:2096|:53|:25'

Le porte utili da controllare subito sono quelle di WHM/cPanel, DNS e mail. Se una di queste manca, non dare per scontato che il problema sia nel browser: spesso è il firewall o un servizio non partito correttamente.

Apri quindi l’interfaccia amministrativa e verifica tre elementi: stato generale del server, notifica di eventuali problemi di licenza e presenza dei servizi principali. Se la GUI non si apre ma il processo risulta in ascolto, il sospetto va al firewall locale, al security group del provider o a una policy di rete intermedia.

Firewall, SELinux e rete: il minimo indispensabile da non sbagliare

Su AlmaLinux 9 è normale avere firewalld attivo. Il punto non è disattivarlo per comodità, ma aprire solo ciò che serve. Se il server è esposto a Internet, lasciare tutto aperto è una cattiva abitudine che prima o poi presenta il conto.

Le porte da considerare dipendono dal ruolo del nodo, ma per l’accesso amministrativo e i servizi base conviene almeno verificare queste:

firewall-cmd --list-ports
firewall-cmd --list-services

Se devi aprire una porta, fallo in modo esplicito e documentato. Ad esempio, per WHM:

firewall-cmd --permanent --add-port=2087/tcp
firewall-cmd --reload

Con SELinux, la strategia migliore è non spegnerlo per abitudine. Se qualcosa non funziona, prima osserva gli AVC:

getenforce
ausearch -m AVC -ts recent

Se il problema è reale e non un falso positivo, correggi il contesto o la policy. Disabilitare SELinux di default su un server esposto non è una soluzione tecnica, è solo un modo per spostare il rischio più avanti.

Primo hardening operativo dopo l’installazione

Finita l’installazione, il lavoro non è concluso. Il primo hardening utile è pratico: accesso amministrativo protetto, password robuste o meglio ancora autenticazione a più fattori dove disponibile, e limitazione delle superfici che non ti servono.

Se il server non deve ospitare DNS autoritativo, mail o FTP, valuta di non attivarli o di ridurne l’esposizione. Molti ambienti cPanel nascono con tutto abilitato e poi si scopre che l’80% delle funzioni non serve davvero. Meno servizi significa meno patch, meno log, meno punti di guasto.

Controlla anche gli aggiornamenti automatici e la finestra di manutenzione. cPanel è un ecosistema che si aggiorna spesso: lasciare il server fermo per mesi senza monitoraggio è il modo più rapido per accumulare drift tra versione, plugin e configurazioni locali.

Verifiche post-installazione che vale la pena fare subito

Le verifiche immediate non devono essere teoriche. Devi guardare servizi, log e reachability reale.

1. Apri WHM su https://IP:2087 e verifica che il login funzioni senza errori di certificato o redirect anomali.
2. Controlla lo stato dei servizi principali con /scripts/restartsrv_all solo se necessario, oppure usa il pannello “Service Status” per vedere cosa è up/down.
3. Verifica la presenza dei log di installazione e di sistema, in particolare /var/log/cpanel-install.log e /usr/local/cpanel/logs/.
4. Controlla che il server risolva il proprio hostname in modo corretto con hostname -f e getent hosts $(hostname -f).
5. Conferma che le porte amministrative e di servizio siano raggiungibili dal tuo IP di gestione.

Se una di queste verifiche fallisce, non saltare subito alla reinstallazione. Di solito il problema è più piccolo: firewall, DNS, hostname o un servizio non partito.

Errori tipici e come leggerli senza perdere tempo

Il primo errore comune è l’installazione su sistema non pulito. Sintomo: conflitti di pacchetti, servizi duplicati, configurazioni sovrascritte. La correzione è decidere se bonificare davvero il nodo o rifare la VM da zero.

Il secondo errore è l’hostname sbagliato. Sintomo: WHM raggiungibile ma certificato incoerente, mail con identità non corretta, warning ripetuti in pannello. La correzione è sistemare hostname e DNS prima di tutto il resto.

Il terzo errore è la rete filtrata male. Sintomo: installazione completata ma accesso a WHM o ai servizi bloccato dall’esterno. La correzione è verificare security group del provider, firewall locale e eventuali ACL intermedie.

Rollback sensato se qualcosa va storto

Se sei in un ambiente virtualizzato o cloud, il rollback più pulito è il ripristino dello snapshot pre-installazione. È la scelta migliore quando l’installazione ha modificato troppi componenti o quando il nodo era già usato per altro.

Se non hai snapshot, la via meno rischiosa è fermarti prima di toccare dati applicativi e ripristinare la configurazione di rete e i pacchetti al minimo indispensabile. In pratica, non trasformare un problema di provisioning in una migrazione manuale improvvisata.

Per ambienti di test, conserva sempre una nota con: versione AlmaLinux, data installazione, IP, hostname, repository usati e qualsiasi modifica al firewall. Quando devi fare troubleshooting dopo giorni, questi dettagli valgono più di dieci screenshot.

Decisione pratica: quando ha senso usare cPanel su AlmaLinux 9

Ha senso se vuoi un server orientato a hosting classico, con gestione centralizzata di domini, account, mail e DNS, e se il team preferisce lavorare da pannello con una struttura abbastanza standardizzata. Ha meno senso se il nodo deve ospitare stack applicativi molto personalizzati o se vuoi il massimo controllo manuale su ogni singolo servizio.

Il criterio utile non è “cPanel sì o no” in astratto, ma quanto il tuo caso reale tollera un layer di astrazione che gestisce per te gran parte del sistema. Se accetti quel modello, AlmaLinux 9 è una base solida. Se non lo accetti, meglio fermarsi prima e scegliere un’architettura diversa.