Come installare HestiaCP su Ubuntu 20.04 LTS

Installare HestiaCP su Ubuntu 20.04 LTS ha senso quando vuoi un pannello leggero, abbastanza lineare da gestire hosting web, DNS, mail e database senza trascinarti dietro una piattaforma più pesante del necessario. La parte che fa perdere tempo, di solito, non è il lancio dello script: è arrivare alla macchina con prerequisiti puliti, hostname coerente, rete corretta e aspettative realistiche su cosa il pannello installerà davvero.

Qui l’obiettivo è fare un’installazione pulita, verificabile e reversibile. Se il server è già in produzione o contiene servizi attivi, fermati prima: HestiaCP tende a voler controllare da solo stack web, mail, DNS e firewall. Se hai già configurazioni manuali, il rischio non è teorico: possono essere sovrascritte o rese incoerenti.

Quando ha senso usare HestiaCP su Ubuntu 20.04

Ubuntu 20.04 LTS è ancora una base solida in molti ambienti, ma va trattato come sistema da tenere aggiornato con disciplina. HestiaCP è adatto se vuoi:

• gestire più siti con virtual host separati;
• avere un pannello per utenti, domini, DNS e mail;
• ridurre il tempo di provisioning rispetto alla configurazione manuale di Nginx/Apache, PHP-FPM, MariaDB e Postfix/Dovecot;
• mantenere una superficie amministrativa più semplice rispetto a suite più complesse.

Non è la scelta giusta se hai già un’architettura molto personalizzata, se usi orchestrazione esterna, o se vuoi mantenere totale controllo manuale su ogni componente. In quel caso il pannello diventa un livello di astrazione che complica più di quanto semplifichi.

Prerequisiti reali prima di lanciare l’installer

Prima di installare, verifica tre cose: hostname corretto, accesso root o sudo senza attriti, e sistema aggiornato. Il punto dell’hostname è spesso sottovalutato: un pannello di hosting si appoggia a nomi host, certificati, record DNS e configurazioni mail. Se il nome macchina è improvvisato, te lo ritrovi poi in TLS, reverse DNS e deliverability.

Controlla lo stato base del sistema con questi comandi:

hostnamectl

Atteso: hostname statico, FQDN coerente, niente nomi temporanei tipo ubuntu o server1 se il server deve esporre servizi pubblici. Se manca, correggilo prima di procedere.

Verifica anche IP e DNS:

ip a

resolvectl status

Se il server non risolve correttamente i nomi o ha un IP non allineato al DNS pubblico, HestiaCP non risolverà il problema per te: lo renderà solo più visibile.

Aggiorna il sistema prima di tutto:

sudo apt update && sudo apt -y upgrade

Se l’upgrade porta un nuovo kernel, pianifica un riavvio prima dell’installazione del pannello. Non è obbligatorio, ma evita di misurare problemi già presenti nel sistema.

Decisione architetturale: web server, mail e DNS

HestiaCP può installare e governare più componenti. La scelta pratica, prima di partire, è capire se vuoi usare il server anche per mail e DNS oppure solo per hosting web. Questa decisione influisce su porte aperte, sicurezza e manutenzione.

• Solo web hosting: meno superficie d’attacco, meno record DNS interni, meno problemi di deliverability.
• Web + DNS: utile se vuoi centralizzare la gestione dei domini, ma richiede attenzione alla ridondanza e al TTL.
• Web + mail: funziona, ma è il caso più delicato; servono SPF, DKIM, DMARC, PTR corretto e una reputazione IP decente.

Se non hai una necessità esplicita di ospitare la posta, spesso conviene lasciarla fuori o delegarla a un servizio esterno. La mail su VPS singola è una delle aree dove si perde più tempo in troubleshooting rispetto al valore ottenuto.

Installazione: percorso consigliato e comando ufficiale

Per installare HestiaCP, il metodo tipico è usare lo script ufficiale scaricato dal repository del progetto. Prima di eseguirlo, conviene leggere il contenuto o almeno verificare che provenga dalla sorgente attesa. In ambiente serio, il “curl | bash” cieco non è una buona abitudine.

Scarica lo script in una directory temporanea e controllane l’hash o il contenuto prima di avviarlo:

cd /tmp
curl -O https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
less hst-install.sh

Se vuoi essere più rigoroso, confronta la fonte con la documentazione ufficiale del progetto e verifica che il ramo sia quello previsto per la release stabile. Il dettaglio del branch può cambiare nel tempo: qui non conviene inventare il nome se non l’hai verificato sul repository corrente.

Avvio base dell’installazione:

sudo bash hst-install.sh

Durante il wizard ti verranno chiesti componenti e credenziali amministrative. Se il tuo obiettivo è un server web classico, la combinazione più comune è web server, PHP, database e pannello. Se vuoi anche mail e DNS, abilita i moduli solo se sai già come gestirli dopo il primo boot.

In molte installazioni conviene evitare di aggiungere servizi non necessari. Ogni servizio in più è una porta, una coda di update e una possibile fonte di alert. Meno roba installi all’inizio, più pulito sarà il troubleshooting.

Installazione con opzioni esplicite: cosa controllare

Lo script di HestiaCP può offrire opzioni per selezionare stack e componenti. Le opzioni esatte possono cambiare con la release, quindi il riferimento corretto è sempre l’help dello script o la documentazione aggiornata. Se vuoi evitare sorprese, fai prima un passaggio di verifica:

bash hst-install.sh --help

Da lì valuta almeno questi punti:

1. quale web server verrà installato;
2. quale versione PHP è prevista come default;
3. se il database sarà MariaDB o MySQL compatibile;
4. se il firewall del pannello interverrà sulle regole esistenti;
5. se mail e DNS saranno inclusi oppure no.

Quando il wizard propone un set di componenti, non accettarlo “perché sì”. Se hai già un reverse proxy esterno, un CDN o una piattaforma mail separata, duplicare i ruoli sul server è solo un modo elegante per creare conflitti.

Post-installazione: accesso al pannello e primo controllo

Finita l’installazione, il primo controllo non è aprire subito il browser e cliccare in giro. Prima verifica che i servizi base siano attivi e che il sistema abbia creato le unità previste. Su systemd, il controllo minimo è questo:

systemctl list-units --type=service | grep -Ei 'hestia|nginx|apache|php|mariadb|mysql|dovecot|postfix'

Atteso: i servizi selezionati risultano attivi o almeno abilitati. Se uno dei servizi chiave è in failed, il pannello può anche aprirsi, ma il comportamento dei siti sarà incoerente.

Controlla anche le porte esposte:

sudo ss -tulpn

Qui vuoi vedere solo le porte coerenti con i servizi che intendi pubblicare. Se compaiono porte inattese, fermati e identifica il processo prima di aprire il server a Internet.

Per accedere al pannello usa l’IP o l’hostname configurato, con la porta prevista dal setup. La UI può cambiare in base alla versione, quindi il dato corretto è quello mostrato dal wizard a fine installazione o nei log dell’installer. Se hai perso l’informazione, non andare a tentativi: recuperala dai log dell’installazione o dalla configurazione del servizio.

Verifiche minime su web, DNS e mail

Appena entrato nel pannello, fai una verifica per livelli. L’errore più comune è considerare tutto “ok” perché la dashboard è verde, mentre uno dei servizi secondari è già fuori asse.

1. Web: crea un dominio di test e verifica che il virtual host risponda con un curl -I dal server e da un host esterno.
2. DNS: se il pannello gestisce zone DNS, controlla che i record A/AAAA e NS siano coerenti con il provider e con l’IP pubblico.
3. Mail: se attiva, verifica che SMTP e IMAP ascoltino, che il PTR sia corretto e che SPF/DKIM/DMARC siano configurati.

Test web rapido:

curl -I http://tuodominio.tld

Atteso: risposta 200, 301 o 302 in base al redirect configurato. Se ricevi 5xx, il problema è nel backend o nella configurazione del virtual host. Se ricevi timeout, il layer da guardare prima è rete/firewall.

Hardening minimo subito dopo l’installazione

Un pannello appena installato non va lasciato nudo. Il minimo sindacale è ridurre la superficie d’attacco e mettere in ordine accessi e aggiornamenti. Non serve trasformare il server in una fortezza, ma ignorare i controlli base è un errore costoso.

• usa password amministrative lunghe e uniche;
• abilita autenticazione a due fattori se disponibile nella tua versione;
• limita l’accesso al pannello da IP fidati, se il contesto operativo lo consente;
• mantieni attivi gli update di sicurezza del sistema operativo;
• evita di esporre servizi che non usi davvero.

Per un controllo base della postura di rete puoi usare:

sudo ufw status verbose

Se il firewall è gestito dal pannello, non sovrapporre regole manuali senza sapere quale livello prevale. È un punto classico di conflitto: una regola locale, una del pannello e una del provider possono produrre un comportamento incoerente difficile da leggere.

Backup e rollback: cosa fare prima di toccare la configurazione

Prima di personalizzare HestiaCP, prepara un piano di rollback. Anche un cambio apparentemente innocuo, come il cambio del web server o la modifica di un template, può rompere più cose del previsto. Il rollback minimo deve includere un backup della configurazione e, se il server è nuovo, un’istantanea della VM o un backup del provider.

Almeno conserva i file di configurazione del pannello e dei virtual host in una copia esterna. Se non sai dove sono, individua i percorsi con la documentazione della tua installazione o con una ricerca mirata nel filesystem. Non vado a fissare qui path assoluti se non li hai già verificati nella tua build, perché cambiano in base a versione e componenti selezionati.

Se devi testare una modifica, fallo prima su un dominio di prova. La logica è semplice: cambi una sola variabile per volta, misuri l’effetto, e solo dopo applichi la stessa modifica ai domini reali.

Errori tipici che bloccano l’installazione o la prima esecuzione

Le rogne più frequenti non sono misteriose. In genere si ripetono quasi sempre negli stessi punti:

1. Hostname sbagliato: il pannello si installa ma poi TLS, mail o certificati fanno acqua. Verifica con hostnamectl e correggi prima di andare avanti.
2. Pacchetti già presenti e conflittuali: Apache, Nginx, MySQL o mail server preesistenti possono interferire. Verifica con dpkg -l o con i servizi attivi e rimuovi solo ciò che è davvero in conflitto.
3. Firewall o security group: installazione riuscita ma pannello irraggiungibile dall’esterno. Verifica con ss -tulpn e con le regole del provider.

Se il problema compare dopo l’installazione, guarda i log del pannello e del servizio che fallisce. In un ambiente Linux recente, il primo posto da controllare è quasi sempre journalctl:

journalctl -xe

Se il log è troppo verboso, filtra per servizio. Il nome esatto dipende dal componente in errore, ma il principio non cambia: prima osservi, poi tocchi la configurazione.

Una nota pratica su DNS, mail e certificati

Molti installano HestiaCP per “avere tutto in un posto”, poi scoprono che il vero costo sta nella manutenzione delle dipendenze tra DNS, mail e certificati. Un record errato o un PTR mancante può rovinare la posta in uscita; un certificato rinnovato male può fermare il pannello o il sito; un TTL troppo alto rallenta le correzioni operative.

Per questo conviene partire con una topologia semplice: un dominio principale pulito, un server con IP statico, record DNS coerenti e certificati emessi solo dopo aver validato il nome host. Se poi aggiungi mail e DNS, fallo come estensione controllata, non come effetto collaterale dell’installazione.

Sequenza operativa consigliata, in pratica

1. aggiorna Ubuntu 20.04 LTS e riavvia se necessario;
2. imposta hostname/FQDN corretti;
3. verifica rete, DNS e accesso root/sudo;
4. decidi in anticipo se installare solo web o anche mail/DNS;
5. scarica lo script ufficiale e controlla la fonte;
6. lancia l’installazione con le opzioni che ti servono davvero;
7. verifica servizi, porte e risposta HTTP;
8. applica hardening minimo e prepara backup/rollback.

Questa sequenza evita il classico errore di “installare prima, capire dopo”. Con i pannelli di hosting, capire dopo significa quasi sempre impiegare il doppio del tempo a disfare un setup non allineato al caso d’uso.

Conclusione operativa

HestiaCP su Ubuntu 20.04 LTS si installa in fretta, ma funziona bene solo se il sistema di partenza è già ordinato. Il pannello non sostituisce il controllo dell’operatore: lo rende più comodo, a patto che hostname, rete, servizi e policy siano stati pensati prima dell’installazione. Se parti con un server pulito, un perimetro chiaro e un rollback pronto, la probabilità di trasformare il setup in un problema di manutenzione cala parecchio.