Come installare Virtualmin su Ubuntu 20.04

Virtualmin su Ubuntu 20.04: cosa stai installando davvero

Virtualmin non è solo un pannello di controllo: è un livello di gestione sopra Webmin che ti porta dentro provisioning di virtual host, DNS, mail, database, FTP, SSL e permessi, con una struttura pensata per amministrare più siti in modo coerente. Su Ubuntu 20.04 funziona bene, ma il punto non è “lanciare uno script e sperare”: devi arrivare all’installazione con una macchina pulita, un hostname corretto e le porte esposte nel modo giusto, altrimenti poi ti ritrovi a inseguire problemi di posta, certificati o login al pannello.

Se l’obiettivo è gestire hosting multi-dominio, Virtualmin ha senso quando vuoi centralizzare configurazione e cicli operativi senza costruire tutto a mano con Nginx, Postfix, Dovecot, MariaDB e tool separati. Se invece ti serve solo un singolo sito statico, stai introducendo complessità inutile. Qui assumo un caso reale da server Linux: una VM o un server dedicato con Ubuntu 20.04, IP pubblico, accesso root o sudo e disponibilità a modificare la configurazione di base del nodo.

Prerequisiti che vanno sistemati prima dello script

La parte che viene saltata più spesso è quella che poi fa perdere tempo. Virtualmin si appoggia a un hostname FQDN valido, a DNS coerente e a servizi di base che devono poter essere installati senza conflitti. Prima di iniziare, verifica questi punti:

• Ubuntu 20.04 aggiornato, con accesso amministrativo.
• Hostname completo tipo server.example.com, non solo server.
• Record DNS A/AAAA coerenti con l’IP pubblico del server.
• Porte 22, 80, 443, 10000 aperte almeno tra client e server.
• Nessun altro stack già pesantemente configurato su Apache/Nginx/Postfix/Dovecot, a meno che tu sappia esattamente come integrarlo.

Controlla subito hostname e risoluzione, perché Virtualmin usa questi dati in più punti: certificati, URL del pannello, identità del server e servizi mail. I comandi sotto ti danno una fotografia rapida.

hostnamectl
hostname -f
getent hosts $(hostname -f)

Il risultato atteso è un FQDN risolvibile e coerente con l’IP del server. Se hostname -f restituisce errore o un nome corto, fermati lì: prima sistemi DNS e /etc/hostname, poi prosegui. Questo evita una catena di problemi che altrimenti emergono solo dopo il setup.

Installazione pulita: il percorso più lineare

Il metodo più affidabile su Ubuntu 20.04 è usare lo script ufficiale di installazione di Virtualmin. Non è una magia: prepara repository, dipendenze e stack necessari. La regola pratica è semplice: fai prima un aggiornamento del sistema, poi lanci l’installer da root o con sudo, e osservi bene cosa installa e cosa decide di configurare.

sudo apt update
sudo apt -y upgrade
sudo reboot

Dopo il riavvio, se il server è stabile e l’uptime è tornato pulito, scarica lo script e verifica che il file sia quello atteso. Non saltare la parte di controllo del contenuto se il tuo ambiente è sensibile: è una best practice basilare su macchine esposte.

wget https://software.virtualmin.com/gpl/scripts/install.sh
sudo sh install.sh

Lo script propone una serie di scelte: tipicamente puoi accettare la configurazione standard se parti da una macchina pulita. In un contesto di produzione conviene leggere l’elenco dei pacchetti che verranno installati e capire se il pannello intende usare Apache o Nginx, se verrà predisposto Postfix, Dovecot, BIND o altri componenti. La scelta del web server dipende dal tuo scenario, ma per una prima installazione “classica” Apache resta il percorso più semplice e documentabile.

Se vuoi automatizzare o fare audit, salva l’output dell’installer in un log. È utile quando devi ricostruire cosa è stato configurato e in quale ordine.

sudo sh install.sh 2>&1 | tee /root/virtualmin-install.log

Al termine, il pannello sarà normalmente raggiungibile su https://IP_DEL_SERVER:10000 oppure su https://hostname:10000 se DNS e rete sono già corretti. La prima login va fatta con l’utente root o con un account sudo autorizzato, in base alla configurazione applicata dallo script.

Accesso iniziale al pannello e controlli di base

La prima verifica non è estetica, ma funzionale: il pannello risponde, il certificato non è palesemente sbagliato e i servizi base sono attivi. Apri il browser su https://server.example.com:10000 e controlla che il login sia possibile. Se il certificato è self-signed nella fase iniziale, è normale; quello che non è normale è non riuscire a raggiungere la porta 10000.

Dal server puoi verificare subito la porta e lo stato dei servizi con systemd. È un controllo rapido che ti dice se il problema è di rete o di servizio locale.

sudo ss -ltnp | grep 10000
sudo systemctl status webmin

Se webmin risulta attivo ma la porta non ascolta, il problema è più profondo e va letto nei log. Se la porta ascolta ma il browser non arriva, il collo di bottiglia è quasi sempre firewall, security group o routing. In un hosting pubblico non dare mai per scontato che “aperto sul server” significhi “raggiungibile da fuori”.

I log più utili, in questa fase, sono quelli di Webmin e del kernel/network stack. Il path esatto può variare, ma i riferimenti tipici sono questi:

sudo journalctl -u webmin -n 100 --no-pager
sudo tail -n 100 /var/webmin/miniserv.error
sudo tail -n 100 /var/log/syslog

Se trovi errori di bind, certificato, permessi o porta già occupata, lì hai già la direzione. Non fare tuning a caso prima di aver letto almeno gli ultimi eventi.

Configurazione iniziale: hostname, DNS, mail e web server

Una volta entrato nel pannello, il primo lavoro serio è allineare identità del server e servizi. Virtualmin tende a fare bene il suo mestiere quando il nome host è corretto, il DNS risponde e i servizi mail/web non hanno conflitti con installazioni precedenti. Se il server ospiterà siti separati, conviene impostare da subito una struttura pulita per utenti, virtual host e database.

Nel pannello, la strada tipica è verificare la sezione di configurazione del sistema e dei moduli di Virtualmin. Cerca l’area dedicata a System Settings e a Virtualmin Configuration, poi controlla che il nome del server sia quello atteso. Se il pannello suggerisce un hostname diverso da quello che hai nel DNS, non ignorarlo: correggere adesso è semplice, farlo dopo aver creato domini e certificati è molto meno pulito.

Per la posta, la scelta operativa dipende dal tuo uso. Se il server deve gestire email, verifica che Postfix e Dovecot siano attivi e che le porte 25, 465, 587, 143, 993 siano coerenti con la policy del tuo provider. Se non vuoi esporre mail sul nodo, disabilita o limita i componenti che non ti servono. Virtualmin è versatile, ma non è obbligatorio usare tutto.

Per il web server, Apache resta la soluzione più lineare nella prima installazione. Se hai già una piattaforma Nginx davanti o un reverse proxy esterno, valuta bene l’architettura prima di lasciare che Virtualmin configuri tutto da solo. Mischiare logiche di proxy, SSL e rewrite senza un disegno chiaro porta quasi sempre a debug inutili.

Creazione del primo virtual server

Il test vero non è il pannello in sé: è la creazione di un virtual server. Da qui capisci se DNS, web server, permessi, database e SSL stanno lavorando insieme. Crea un dominio di prova, meglio se non quello di produzione, e usa un nome realistico. In Virtualmin il virtual server rappresenta il contenitore operativo del sito: utente, gruppo, document root, virtual host e, se vuoi, database e mailbox.

Durante la creazione, controlla con attenzione le opzioni che attivano servizi aggiuntivi. Se non ti serve la posta per quel dominio, non abilitarla per inerzia. Se non ti serve FTP, disattivalo. Meno superficie esposta hai, meno manutenzione ti porti dietro. Questo non è solo ordine amministrativo: è riduzione reale del rischio.

Dopo la creazione, verifica che la document root esista e che il contenuto di test risponda correttamente. Un controllo classico è questo:

curl -I http://example.com
curl -Ik https://example.com

Il risultato atteso è un 200 o un 301/302 coerente con il redirect impostato. Se vedi 404, il virtual host non punta dove pensi. Se vedi 500, il problema è lato applicazione o PHP. Se non risponde proprio, il problema è a monte: DNS, routing, firewall o servizio web down.

SSL: quando farlo subito e quando aspettare

Su un pannello come Virtualmin, il certificato TLS non è un dettaglio accessorio. Serve per il pannello stesso e per i virtual host ospitati. Se il dominio è già pubblico e risolvibile, la strada più pulita è ottenere un certificato Let’s Encrypt appena il sito è creato e il DNS è allineato. Se il DNS non è ancora propagato o il server è dietro un proxy non trasparente, rimanda la richiesta finché non hai una validazione affidabile.

Il punto di attenzione è la validazione HTTP-01: il server deve essere raggiungibile dall’esterno sulla porta 80 per completare il challenge. Se hai un WAF, un CDN o un firewall stretto, verifica prima il percorso end-to-end. In molti casi il problema non è il certificato, ma il fatto che la challenge non arriva mai al server giusto.

Se usi Let’s Encrypt da Virtualmin, tieni sotto controllo i log relativi all’emissione e al rinnovo. Un rinnovo fallito spesso si scopre troppo tardi, quando il certificato è già scaduto. La manutenzione corretta è controllare periodicamente la scadenza e testare il rinnovo automatico in anticipo.

sudo certbot certificates
sudo systemctl list-timers | grep certbot

Se il tuo stack non usa Certbot direttamente ma un’integrazione di Virtualmin, il principio non cambia: devi sapere dove guardare la scadenza, dove sta il log e quale processo gestisce il rinnovo. L’assenza di visibilità qui si traduce in incidenti evitabili.

Hardening minimo che conviene fare subito

Subito dopo l’installazione, prima di caricare siti veri, conviene fare un hardening essenziale. Non serve irrigidire tutto in modo cieco, ma ridurre esposizione e rischio sì. La superficie minima da controllare è questa: accesso al pannello, policy SSH, firewall, aggiornamenti, account amministrativi e servizi non usati.

• Limita l’accesso a :10000 con firewall o allowlist IP se possibile.
• Verifica che SSH non sia esposto oltre il necessario.
• Applica aggiornamenti di sicurezza con cadenza regolare.
• Disabilita servizi che non usi davvero, soprattutto mail e FTP se il caso non li richiede.
• Controlla i permessi dei virtual server e degli utenti creati.

Su Ubuntu 20.04, se UFW è in uso, puoi partire da una policy semplice e leggibile. Attenzione però: applica solo ciò che sai di dover tenere aperto, altrimenti ti blocchi fuori dal server o spezzi il pannello. Prima di toccare il firewall, assicurati di avere accesso console o out-of-band.

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/tcp

Se il server è già dietro un security group cloud o firewall perimetrale, allinea anche lì le regole. Il controllo va fatto su entrambi i livelli: host e rete. Molti problemi di “porta aperta ma non raggiungibile” nascono proprio da questa doppia configurazione dimenticata.

Problemi tipici dopo l’installazione e come leggerli senza perdere tempo

Il primo errore classico è il mismatch di hostname. Sintomo: il pannello funziona, ma certificati, mail o virtual host mostrano nomi sbagliati. La verifica è semplice: confronta hostname -f, il record DNS pubblico e i valori mostrati nel pannello. Se non coincidono, correggi la sorgente del nome, non il sintomo.

Il secondo errore è il conflitto con servizi già presenti. Sintomo: Apache o Postfix non partono, oppure Virtualmin segnala componenti mancanti o già occupati. Qui i comandi utili sono sempre gli stessi: stato del servizio, log recenti, porte in ascolto. Il pattern è questo:

sudo systemctl status apache2
sudo systemctl status postfix
sudo ss -ltnp
sudo journalctl -xe --no-pager

Il terzo errore è il DNS incompleto. Sintomo: il sito funziona in locale ma non da fuori, oppure Let’s Encrypt fallisce. In questo caso non serve “rifare Virtualmin”: devi verificare i record A/AAAA, la propagazione e l’eventuale CDN davanti. Un test rapido da un host esterno ti chiarisce subito se il nome punta dove deve.

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

Se i risultati non tornano, la correzione è nel DNS o nel routing, non nel pannello. Virtualmin può gestire record DNS se usi il suo modulo, ma resta fondamentale che il modello mentale sia quello giusto: il pannello orchestra, non sostituisce la coerenza dell’infrastruttura.

Backup, aggiornamenti e manutenzione ordinaria

Una volta installato, il valore di Virtualmin si vede nella gestione ordinaria. Devi sapere dove finiscono i backup dei virtual server, con quale frequenza li produci e come ne verifichi il ripristino. Il backup senza restore testato è solo un file occupato su disco. Per un ambiente serio, serve almeno una prova di ripristino su una macchina di test o su un dominio non critico.

La manutenzione minima include aggiornamenti di sistema, verifica dello stato dei servizi e controllo dello spazio disco. Il disco pieno è uno dei motivi più banali e più fastidiosi di disservizio, soprattutto su nodi che gestiscono log, mail e database insieme.

df -h
sudo apt update
sudo apt list --upgradable
sudo systemctl --failed

Se il server ospita siti con traffico reale, aggiungi metriche di base: tempi di risposta, error rate, carico CPU, uso RAM, I/O disco e code mail. Non serve una piattaforma enorme per iniziare: basta sapere se il nodo sta degradando prima che lo faccia vedere l’utente finale.

Quando Virtualmin è una scelta sensata e quando no

Virtualmin ha senso quando vuoi un pannello che ti dia controllo amministrativo serio, ma senza scrivere a mano ogni volta la stessa combinazione di virtual host, account, database e certificati. È adatto a chi gestisce hosting, ambienti multi-dominio, piccoli datacenter, VPS per clienti e server interni con più servizi web. Funziona bene anche come piattaforma di apprendimento, perché mostra in modo abbastanza trasparente cosa c’è sotto il cofano.

Non è invece la scelta ideale se il tuo stack è già fortemente standardizzato su automazione IaC, container orchestration o reverse proxy custom con pipeline dedicate. In quel caso il pannello può diventare un livello in più da mantenere, non un vantaggio. La domanda corretta non è “è potente?”, ma “mi riduce davvero il lavoro operativo senza introdurre ambiguità?”.

Su Ubuntu 20.04, la combinazione Virtualmin + installazione pulita + DNS coerente + hardening minimo è una base solida. Il resto lo fa la disciplina operativa: log letti davvero, backup verificati, aggiornamenti regolari e modifiche documentate. È questa la differenza tra un pannello che aiuta e un pannello che ti costringe a fare debug ogni settimana.