Come installare CyberPanel su Ubuntu 22.04

CyberPanel su Ubuntu 22.04 funziona bene quando il sistema è pulito, il server ha risorse sufficienti e non ci sono già servizi in ascolto sulle porte che il pannello vuole usare. Il punto non è “far partire l’installer”, ma evitare conflitti con web server, database e mail già presenti, perché la reinstallazione dopo un mezzo disastro costa sempre più tempo della preparazione fatta bene.

Se l’obiettivo è ottenere un pannello per gestire siti, virtual host, SSL e account senza passare ogni volta dal terminale, CyberPanel è una scelta pratica. Su Ubuntu 22.04 conviene però partire con un’installazione minimale, aggiornare il sistema, verificare porte e spazio disco, e solo dopo lanciare lo script ufficiale. Questa sequenza riduce i problemi più comuni: conflitti su Apache/Nginx, database già attivo, hostname non corretto, DNS non allineato e installazione interrotta per mancanza di RAM o swap.

Prima di installare: controlli che evitano metà dei ticket

La prima verifica è banale ma decisiva: il server deve avere un hostname valido e risolvibile. CyberPanel lavora meglio se il nome host è un FQDN, ad esempio panel.example.com, e non un nome corto generico. Se il record DNS non esiste ancora, si può comunque installare, ma alcuni servizi e certificati richiederanno correzioni successive.

Controlla anche che il sistema sia aggiornato e che ci sia spazio libero sufficiente. Un’installazione pulita di CyberPanel con OpenLiteSpeed, database e servizi correlati può occupare parecchio, soprattutto se il server ospiterà più siti. In pratica, sotto i 10 GB liberi stai già giocando male; meglio stare più larghi.

Esegui questi controlli preliminari:

hostnamectl
lsb_release -a
free -h
df -h /
ss -lntp | egrep ':(80|443|7080|8090|3306|25|587|465)\b' || true

La condizione ideale è questa: Ubuntu 22.04 LTS, memoria sufficiente per l’installer, disco con margine reale e nessun web stack già in ascolto su 80 e 443. Se trovi Apache o Nginx già installati e configurati, devi decidere se migrare o rimuovere prima di procedere. Lasciarli lì “tanto non danno fastidio” è il modo più rapido per avere porte occupate e diagnostica confusa.

Se il server è in produzione o contiene dati importanti, fai almeno uno snapshot del VPS o un backup completo prima di toccare il sistema. L’installer può installare pacchetti, modificare configurazioni e riavviare servizi. Non è il caso di improvvisare.

Architettura minima: cosa installa CyberPanel e cosa aspettarsi

CyberPanel non è solo un’interfaccia. Di norma porta con sé OpenLiteSpeed come web server, PHP con gestione dei profili, database MySQL/MariaDB a seconda della configurazione, strumenti per SSL, gestione utenti e funzioni di base per mail e DNS, se abilitate. Questo significa che l’installazione va pensata come un cambio di stack, non come una semplice aggiunta di pannello.

Il vantaggio è evidente: il pannello semplifica provisioning, virtual host, firewall di base e creazione di certificati. Il rovescio della medaglia è che se hai già una tua architettura ben costruita con Nginx, PHP-FPM custom, reverse proxy e database separato, CyberPanel può sovrapporsi in modo scomodo. In quel caso va valutato come change controllato, non come installazione “al volo”.

Installazione su Ubuntu 22.04: sequenza operativa pulita

La strada più lineare è usare lo script ufficiale. Prima però aggiorna il sistema e rimuovi eventuali conflitti evidenti. Se hai già Apache o Nginx e vuoi un’installazione standard, fermali e disinstallali solo se sai che non servono più. Se invece stai lavorando su un server nuovo, è ancora meglio: meno variabili, meno sorprese.

sudo apt update
sudo apt -y upgrade
sudo reboot

Dopo il riavvio, rientra via SSH e lancia l’installer ufficiale. CyberPanel fornisce uno script che guida l’installazione interattiva. La sintassi può cambiare nel tempo, quindi conviene usare il comando indicato nella documentazione ufficiale al momento dell’installazione. La logica, però, resta la stessa: scarichi lo script, lo esegui e rispondi alle opzioni richieste.

sudo su -
curl -sS https://cyberpanel.net/install.sh | bash

Durante il setup ti verranno chieste alcune scelte importanti: versione di OpenLiteSpeed, eventuali componenti extra, password amministrativa, installazione di servizi aggiuntivi e, in alcuni casi, opzioni per mail e DNS. La regola pratica è semplice: se non hai un’esigenza precisa, resta sulle opzioni standard e non attivare moduli che non userai subito. Ogni servizio in più è un servizio da aggiornare, monitorare e mettere in sicurezza.

Se l’installer chiede una password per l’account admin, non riutilizzare credenziali già presenti altrove. Usa una password nuova e con sufficiente entropia. Meglio ancora, appena finita l’installazione, sostituiscila con un segreto custodito in un password manager o in una vault interna. Non salvarla in chiaro nei ticket, nei documenti condivisi o nei prompt della shell.

Se l’installer fallisce, il primo posto da guardare è il log del processo e lo stato dei servizi creati. In molti casi il problema non è CyberPanel in sé, ma una dipendenza mancante, una porta occupata o un repository esterno non raggiungibile. I comandi utili sono questi:

systemctl status lscpd --no-pager
journalctl -u lscpd -n 100 --no-pager
journalctl -xe --no-pager

Se il servizio principale non parte, verifica prima il motivo tecnico più semplice: porta occupata, permessi su file di configurazione, database non inizializzato o memoria insufficiente. L’errore “generic failure” non aiuta; il log sì.

Accesso iniziale al pannello e primo hardening

Una volta completata l’installazione, il pannello è tipicamente raggiungibile sulla porta amministrativa indicata dallo script. In genere si accede via browser con l’IP del server o con il nome host, usando l’URL e la porta configurati in fase di setup. Se il firewall blocca l’accesso, devi aprire solo ciò che serve davvero: amministrazione, HTTP e HTTPS, più eventuali porte mail se il server ospita anche quello.

Il primo login non è il momento per creare siti a caso. Prima controlla la sicurezza di base: cambia password admin se non l’hai già fatto, verifica l’hostname, limita l’accesso al pannello se possibile e conferma che il certificato TLS sia valido. Se usi un IP pubblico diretto, il certificato iniziale potrebbe non essere perfetto; appena hai un DNS corretto, genera un certificato Let’s Encrypt per il pannello.

Un controllo minimo del firewall su Ubuntu 22.04 con UFW può essere questo:

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# apri la porta del pannello solo se necessaria e solo verso IP fidati
# sudo ufw allow from X.X.X.X to any port 8090 proto tcp

La scelta migliore, quando possibile, è non esporre il pannello a tutto Internet. Se devi amministrarlo da remoto, restringi l’accesso per IP, VPN o jump host. È una misura semplice che elimina una fetta di tentativi automatici e riduce la superficie d’attacco. Per un pannello web amministrativo, è una misura di buon senso, non un optional.

Verifica del web server e del PHP dopo l’installazione

Dopo il login, il test reale è la pubblicazione di un sito di prova. Non basta vedere il pannello online: serve verificare che il web server risponda, che PHP venga eseguito e che i virtual host siano creati correttamente. Una pagina statica e una pagina PHP di test ti dicono subito se il layer applicativo è vivo.

Per un test rapido, crea un file semplice nella document root del sito di test, ad esempio:

<?php
phpinfo();

Se questo file restituisce un errore 403, 404 o viene scaricato invece di essere eseguito, il problema è quasi sempre nel mapping del virtual host, nella gestione PHP o nei permessi della directory. In quel caso controlla la configurazione del sito dal pannello e, se necessario, il profilo PHP assegnato. La correzione va fatta sul punto giusto, non con tentativi casuali sul filesystem.

Per la parte di servizio, questi comandi sono i più utili:

systemctl status lsws --no-pager
systemctl status lscpd --no-pager
ss -lntp | egrep ':(80|443|8090)\b'

Se OpenLiteSpeed non ascolta su 80 e 443, non ha senso andare a caccia di bug applicativi. Prima fai tornare su il servizio, poi testi il sito. La sequenza corretta è sempre layer-by-layer: servizio, porta, virtual host, PHP, contenuto.

DNS, certificati e nome host: dove si rompe spesso in silenzio

Molti installano il pannello e poi si fermano lì, ma il lavoro vero inizia quando colleghi dominio, DNS e certificati. Se il record A o AAAA non punta al server giusto, il pannello sarà raggiungibile solo via IP oppure non lo sarà affatto. Prima di attivare SSL, verifica la propagazione e la coerenza tra hostname e IP pubblico.

Il controllo minimo è questo:

dig +short panel.example.com A
dig +short panel.example.com AAAA
curl -I https://panel.example.com

Se il certificato non si genera, spesso il motivo è banale: il dominio non risolve ancora verso il server, la porta 80 è chiusa, oppure c’è un proxy/CDN che intercetta la richiesta. In questi casi non serve reinstallare nulla. Va sistemata la catena DNS → edge → origin. Solo quando la richiesta arriva davvero all’istanza giusta ha senso rifare la richiesta del certificato.

Se usi Cloudflare o un altro CDN, fai attenzione alla modalità proxy durante l’emissione del certificato. In alcuni scenari conviene temporaneamente impostare il record su DNS only per il tempo necessario a validare la challenge. Poi puoi riattivare il proxy. È un dettaglio operativo che evita ore perse dietro a un ACME che non può completare la verifica.

Backup, aggiornamenti e manutenzione: la parte noiosa che salva il server

Installare CyberPanel è la parte facile. La parte seria è mantenerlo. Appena il pannello è in produzione, definisci un backup esterno: non sullo stesso disco, non nella stessa VM, non nello stesso storage che ospita i siti. Se il server si ferma per un problema hardware o per un errore umano, il backup locale vale poco o niente.

Almeno per la prima fase, verifica che i backup includano configurazioni, virtual host, database e file web. Non dare per scontato che tutto sia coperto allo stesso modo. Un backup “completo” che lascia fuori i database è un falso amico. Fai un test di restore su una macchina di prova o in una directory separata, perché un backup non testato è solo un file che speri di poter usare un giorno.

Per gli aggiornamenti, non correre. Prima osserva changelog e impatto sui servizi. Un update del pannello o di OpenLiteSpeed può richiedere riavvii o modificare il comportamento di PHP. La procedura prudente è: snapshot, finestra di manutenzione, update, verifica, rollback se qualcosa si rompe. Su server con traffico reale, questa disciplina evita incidenti stupidi e facilmente prevenibili.

Problemi tipici subito dopo l’installazione

Il primo problema classico è la porta del pannello non raggiungibile. In quel caso controlla firewall, security group del provider, binding del servizio e eventuali regole di rete esterne. Il secondo è il sito che risponde ma PHP non esegue: qui il colpevole di solito è il profilo PHP o la configurazione del virtual host. Il terzo è il certificato TLS non valido, quasi sempre per DNS non allineato o challenge ACME bloccata.

Un altro caso frequente è il server che sembra installato ma lavora male sotto carico. Qui la causa non è il pannello in sé, ma risorse sottodimensionate. Se la macchina è piccola, con poca RAM e senza swap, basta poco per andare in OOM o rallentare in modo visibile. Il controllo da fare è semplice:

free -h
swapon --show
journalctl -k -n 100 --no-pager | egrep -i 'oom|killed process|out of memory'

Se emergono kill del kernel o swap assente su una VPS piccola, la soluzione è aumentare RAM o aggiungere swap, poi ritarare i limiti applicativi. Non è elegante, ma è molto più utile che inseguire ottimizzazioni premature.

Quando ha senso usare CyberPanel e quando no

CyberPanel ha senso quando vuoi un pannello unico per più siti, gestione semplice di SSL e virtual host, e un setup ragionevolmente standard su Ubuntu 22.04. È utile anche per chi deve consegnare ambienti in tempi rapidi e non vuole ricostruire tutto a mano ogni volta. In pratica, funziona bene dove conta la velocità operativa e la standardizzazione.

Ha meno senso se hai già una piattaforma molto personalizzata, con reverse proxy, tuning fine, deployment automatizzati e policy di sicurezza interne rigide. In quel caso il pannello può diventare un ulteriore livello da governare, non una semplificazione. La domanda giusta non è “si installa?”, ma “mi riduce davvero il costo operativo nel mio scenario?”.

Su Ubuntu 22.04, la risposta pratica è questa: installalo su server nuovi, dedicati o quasi dedicati, con configurazione pulita e obiettivo chiaro. Se devi integrare un ambiente già complesso, fermati prima e valuta il blast radius. Cambiare stack senza piano di rollback è il modo più veloce per trasformare un pannello comodo in una notte lunga.

Checklist finale per un’installazione fatta bene

Prima di considerare chiusa l’installazione, verifica questi punti in ordine:

1. Il sistema è Ubuntu 22.04 aggiornato e con spazio disco sufficiente.
2. L’hostname è corretto e risolve verso l’IP giusto.
3. Non ci sono conflitti evidenti su 80, 443 e sulla porta di amministrazione.
4. Il pannello risponde e l’accesso admin funziona con credenziali nuove.
5. Un sito di test risponde in HTTP e PHP viene eseguito correttamente.
6. Il certificato TLS è valido o il motivo del fallimento è stato identificato.
7. Firewall, backup e policy di accesso sono stati impostati prima della messa in produzione.

Se tutti i controlli passano, hai un’installazione utilizzabile e non solo un pannello acceso. Il valore vero sta lì: non nell’aver lanciato uno script, ma nell’aver portato il server in uno stato prevedibile, amministrabile e recuperabile.

Per un ambiente nuovo, la procedura consigliata resta sempre la stessa: preparazione, installazione, verifica, hardening minimo, backup e solo dopo pubblicazione dei siti. È una sequenza semplice, ma è quella che evita quasi tutti gli errori che vedo ripetersi sui server gestiti di fretta.