Come installare VestaCP su CentOS 7 passo dopo passo

CentOS 7 e VestaCP: scelta da fare con i piedi per terra

CentOS 7 è fuori dal ciclo standard di vita da tempo, quindi installare VestaCP su questa base ha senso solo se devi gestire un server già esistente, un ambiente legacy o un laboratorio che non puoi migrare subito. La procedura funziona, ma il punto vero non è far partire il pannello: è sapere che stai montando un controllo remoto completo su una piattaforma che va tenuta stretta, aggiornata e isolata il più possibile.

VestaCP resta un pannello semplice da usare per hosting classico: web server, DNS, mail, database, utenti e backup. Non è il sistema più moderno del settore, però su macchine piccole o in contesti con operatività ridotta continua a essere pratico. Qui conviene installarlo in modo pulito, con i controlli minimi prima di aprire porte e pubblicare servizi.

Prerequisiti reali prima di lanciare l’installer

Prima di installare, verifica che la macchina abbia un hostname FQDN corretto, una rete stabile e una configurazione di base coerente. VestaCP usa il nome host in diversi punti: certificati, mail, DNS e interfaccia. Se lasci un hostname generico, poi ti ritrovi problemi che sembrano del pannello ma sono solo errori di identità del server.

Serve anche una installazione minimale di CentOS 7, senza stack web già presenti. Se Apache, Nginx, MariaDB o vecchi servizi di mail sono già stati configurati, l’installer può sovrapporsi o fallire. In pratica: meno roba c’è, meglio è.

Controlli iniziali consigliati

Fai questi controlli prima di tutto:

1. Hostname completo e risolvibile:

   hostnamectl
   hostname -f

2. Versione del sistema:

   cat /etc/centos-release

3. Spazio disponibile su root e /tmp:

   df -h

4. Connettività verso repository e DNS funzionante:

   curl -I https://vestacp.com
   nslookup google.com

Se uno di questi punti fallisce, fermati prima di installare. Il costo di un rollback dopo è più alto del costo di correggere adesso il prerequisito. Se il server è in produzione, fai anche uno snapshot o un backup completo della macchina prima di toccare il sistema.

Impostare hostname e aggiornare il sistema

Su CentOS 7, il nome host deve essere impostato in modo permanente. Un esempio corretto è qualcosa come server1.example.com. Evita nomi brevi o temporanei, perché il pannello li riusa in più componenti.

Se devi correggerlo, imposta il nome e verifica subito la risoluzione locale:

hostnamectl set-hostname server1.example.com
echo "127.0.0.1 server1.example.com server1 localhost localhost.localdomain" >> /etc/hosts
hostname -f

Il punto delicato è /etc/hosts: deve contenere il mapping giusto per il FQDN, altrimenti alcuni script di installazione o servizi del pannello possono interpretare male l’identità del server. Non usare lo stesso nome su più host.

Poi aggiorna il sistema prima dell’installazione. Su una macchina vecchia questo passaggio riduce il rischio di dipendenze rotte o librerie incompatibili.

yum clean all
yum -y update
reboot

Dopo il riavvio, controlla che il kernel e i servizi di base siano tornati su senza errori:

uptime
systemctl --failed

Scaricare e avviare l’installer di VestaCP

La procedura classica passa da uno script di installazione. È semplice, ma proprio per questo va trattata con attenzione: uno script remoto eseguito come root va verificato almeno nel minimo indispensabile, e va lanciato solo su sistemi puliti.

La sequenza tipica è questa:

curl -O https://vestacp.com/pub/vst-install.sh
bash vst-install.sh

Se preferisci un controllo in più, scarica prima il file e ispezionalo. Anche una lettura rapida delle prime righe e delle chiamate a pacchetti o repository ti dice subito se lo script sta facendo cose inattese.

Durante l’installazione ti vengono richiesti alcuni dati operativi: email amministrativa, hostname, componenti da installare e password iniziale. Qui l’errore più comune è correre e accettare tutto senza leggere. Se il server deve fare solo hosting web, non è detto che ti servano anche mail e DNS sullo stesso nodo.

Scelta dei componenti

In un’installazione tipica puoi trovare moduli per web, DNS, mail, database e FTP. La scelta va fatta in base al ruolo del server, non per abitudine. Se hai già un DNS esterno o un relay mail separato, tenere quei servizi fuori dal pannello ti semplifica manutenzione e riduce superficie d’attacco.

• Web: quasi sempre necessario.

• DNS: solo se vuoi gestire autoritativo sul server.

• Mail: attivalo solo se hai davvero bisogno di ospitare caselle locali.

• Database: utile per hosting classico, ma verifica la versione installata.

• FTP: spesso evitabile se puoi lavorare con SFTP.

Se il pannello propone più web stack o varianti di database, scegli la combinazione più semplice compatibile con il tuo scenario. Ogni componente in più è una porta, un servizio e un possibile punto di manutenzione.

Verificare che il pannello sia davvero operativo

Finita l’installazione, non fermarti al messaggio di successo. Entra subito nel pannello e verifica che l’interfaccia risponda, che i servizi principali siano attivi e che le porte siano raggiungibili solo dove devono esserlo.

Un controllo minimo da shell è questo:

systemctl status vesta
ss -tulpn | egrep ':8083|:80|:443|:25|:53|:3306'

La porta di default dell’interfaccia web di VestaCP è spesso 8083. Se non risponde, il problema può stare nel servizio, nel firewall o nella configurazione di rete. Non partire subito con modifiche complesse: prima distingui se il blocco è locale o di rete.

Dal client, una prova semplice è questa:

curl -kI https://server1.example.com:8083

Con -k accetti il certificato self-signed iniziale, che in molte installazioni è normale. Se invece ottieni timeout, controlla il firewall prima di cercare colpe nell’applicazione.

Firewall, porte e riduzione della superficie esposta

Su un pannello di hosting la tentazione è aprire tutto per farlo funzionare subito. È il modo più rapido per avere un server esposto in eccesso. La regola giusta è aprire solo le porte che servono davvero al ruolo del nodo.

Le porte da considerare dipendono dai moduli installati: 80 e 443 per il web, 8083 per il pannello, 25/465/587 per mail, 53 per DNS, 3306 solo se il database deve essere raggiungibile da fuori. Se il database è locale, non esporlo.

Con firewalld, un esempio minimale per il pannello e il web è:

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=8083/tcp
firewall-cmd --reload
firewall-cmd --list-all

Se stai gestendo anche SSH da remoto, verifica che la tua policy non tagli fuori l’accesso amministrativo. Il rollback qui è banale ma fondamentale: tieni una sessione aperta e prova prima la nuova regola da un secondo terminale o da una seconda origine di rete.

Post-install: primo giro di hardening minimo

Una volta acceso il pannello, fai subito un giro di pulizia. Il primo obiettivo non è “blindare tutto”, ma togliere attrito e ridurre errori banali. Cambia le password iniziali, verifica gli utenti creati e controlla i permessi delle directory di hosting.

Se il pannello gestisce account separati per i siti, lascia ogni sito nel proprio spazio e non mischiare credenziali o file tra progetti diversi. È la differenza tra un incidente circoscritto e uno che si allarga a più virtual host.

Controlla anche i log principali. I percorsi possono variare leggermente, ma in genere conviene cercare sotto /var/log e nei log specifici del servizio web, del mail server e del pannello. Se qualcosa non parte, il log ti dice subito se il problema è certificato, porta occupata, permesso o dipendenza mancante.

Una verifica utile è cercare errori recenti subito dopo l’installazione:

journalctl -xe
find /var/log -maxdepth 2 -type f | egrep 'vesta|nginx|httpd|mysqld|mail|exim|dovecot'

Se hai attivato il mail stack, controlla anche la reputazione operativa di base: hostname corretto, record DNS coerenti, SPF e PTR allineati. Senza questi elementi, il pannello può funzionare ma la posta finisce comunque nel posto sbagliato.

DNS, mail e certificati: i tre punti che fanno perdere tempo

Su VestaCP i problemi più noiosi non sono quasi mai l’installazione in sé, ma l’integrazione dei servizi. Il DNS deve puntare al server giusto, la posta deve avere record coerenti e il certificato deve coprire il nome usato dagli utenti.

Per il DNS, verifica almeno A, MX e, se usi mail, SPF e PTR. Se il dominio risolve altrove o il reverse DNS non combacia, la posta può essere rifiutata o degradata dai provider esterni. Non è un bug del pannello: è coerenza infrastrutturale.

Per i certificati, se il pannello o i siti partono con un self-signed, pianifica subito la sostituzione con un certificato valido. Se usi Let’s Encrypt, assicurati che il nome host sia risolvibile pubblicamente e che la porta necessaria sia raggiungibile. Se una challenge fallisce, guarda prima firewall e DNS, poi il servizio ACME.

Un controllo rapido del DNS da shell:

dig +short server1.example.com A
 dig +short example.com MX
 dig +short -x 203.0.113.10

Se i risultati non sono coerenti con quello che hai configurato nel pannello, fermati e correggi la zona prima di andare avanti. Qui il problema non è il pannello, è la base su cui lo stai appoggiando.

Backup e ripristino: non rimandare al giorno dopo

Subito dopo l’installazione conviene impostare almeno una strategia di backup semplice. VestaCP include funzioni di backup, ma la regola operativa resta la stessa: un backup non vale nulla finché non hai provato un ripristino su un ambiente di test o su una macchina secondaria.

Decidi cosa salvare: configurazioni del pannello, vhost, database, home degli utenti, DNS e mail. Se il server ospita siti, il minimo è poter ricostruire web root e database. Per i dati sensibili, evita di lasciare archivi non cifrati in posizioni facilmente accessibili.

Se usi backup automatici, verifica il percorso di destinazione e lo spazio disponibile. Molti problemi emergono non al primo backup, ma quando il disco di destinazione si riempie e nessuno se ne accorge.

Quando non ha senso insistere su CentOS 7

Se stai progettando un nuovo ambiente, CentOS 7 non è la base giusta. Ha troppo debito tecnico accumulato per giustificare una nuova installazione. In quel caso ha più senso migrare verso una distribuzione supportata e scegliere un pannello o una gestione nativa compatibile con il ciclo di vita attuale.

Se invece devi mantenere un’installazione esistente, la strada migliore è documentare bene la configurazione, ridurre i servizi inutili e preparare un piano di migrazione. Installare VestaCP qui può essere una soluzione tattica, non una scelta strategica.

Checklist finale operativa

Prima di considerare il lavoro concluso, verifica questi punti:

1. Hostname FQDN corretto e risolvibile localmente.

2. Servizio Vesta attivo e pannello accessibile sulla porta prevista.

3. Firewall allineato ai soli servizi necessari.

4. DNS, mail e certificati coerenti con il dominio.

5. Backup configurato e testato almeno una volta.

Assunzione: questa procedura è pensata per un server legacy o di laboratorio; su un ambiente nuovo conviene migrare a una base supportata prima di investire tempo sul pannello.