Ubuntu Server è la versione di Ubuntu pensata per eseguire servizi e applicazioni su server fisici, macchine virtuali, VPS e infrastrutture cloud. Può ospitare un sito web, un database, un file server, container, API, applicazioni aziendali o servizi di rete, senza richiedere un ambiente desktop grafico.
La parte più semplice, nella maggior parte dei casi, è installarlo. Le decisioni che contano davvero arrivano prima e subito dopo l’installazione: scegliere una release ancora supportata, capire se ti serve realmente un’ISO, configurare correttamente rete e accesso SSH, aggiornare il sistema e non esporre servizi inutili verso Internet.
In questa guida partiamo quindi da ciò che Ubuntu Server è realmente e arriviamo a un sistema utilizzabile, aggiornato e amministrabile da remoto, distinguendo anche ciò che cambia tra server fisico, VPS, macchina virtuale e cloud.
Cos’è Ubuntu Server e a cosa serve
Ubuntu Server è una distribuzione Linux della famiglia Ubuntu progettata per fare da base a servizi server e infrastrutture. Se vuoi approfondire prima il concetto generale, nella guida dedicata spieghiamo cos’è un server e come funziona.
La distinzione è importante: Ubuntu Server non è un “programma server” come Apache, MySQL o OpenSSH. È il sistema operativo sul quale questi servizi possono essere installati ed eseguiti.
Il modello mentale corretto è quindi:
hardware o VM → Ubuntu Server → servizi/applicazioni → client
Una macchina può eseguire, per esempio, Ubuntu Server come sistema operativo, Nginx o Apache come web server, PHP come runtime applicativo e MySQL come database. Ogni componente svolge un ruolo diverso.
Canonical descrive Ubuntu Server come una base per ambienti che vanno dal semplice server alla virtualizzazione, al cloud e alle infrastrutture su larga scala.
Ubuntu Server e Ubuntu Desktop: cosa cambia davvero
Ubuntu Server e Ubuntu Desktop appartengono allo stesso ecosistema Ubuntu e accedono allo stesso archivio di pacchetti, ma partono da configurazioni e set di software differenti.
La differenza più evidente è che l’immagine Server non installa un’interfaccia grafica desktop per impostazione predefinita. Questo evita di occupare risorse per componenti che normalmente non servono su una macchina amministrata da remoto.
| Aspetto | Ubuntu Server | Ubuntu Desktop |
|---|---|---|
| Interfaccia grafica predefinita | No | Sì |
| Uso principale | Servizi, hosting, cloud, infrastrutture | Postazione personale e workstation |
| Amministrazione tipica | Terminale e SSH | GUI + terminale |
| Software iniziale | Base orientata ai servizi | Applicazioni desktop e ambiente grafico |
| Esecuzione senza monitor | Naturale | Possibile, ma non è il caso d’uso principale |
| GUI installabile successivamente | Sì | Già presente |
Non significa che Ubuntu Server “non possa avere una GUI”. Puoi installare un ambiente grafico anche dopo, ma prima conviene chiedersi se serva davvero. Su un VPS o su un server esposto in rete, quasi sempre l’amministrazione via SSH è più semplice e riduce i componenti da mantenere.
Server web, database, file server, container e altri casi d’uso
Una singola installazione può svolgere ruoli molto diversi. Puoi usarla come web server, database server, ambiente per applicazioni, nodo di virtualizzazione, server per backup e file condivisi oppure host per container.
Per un sito WordPress self-hosted su VPS, per esempio, Ubuntu può costituire la base del sistema; sopra puoi installare un web server, PHP e un database. Per un’applicazione moderna, invece, potresti eseguire Docker o altri strumenti di containerizzazione e distribuire i vari servizi separatamente.
Il punto è che Ubuntu Server non decide quale server stai costruendo. Ti fornisce l’ambiente Linux sul quale puoi costruire la configurazione appropriata.
Server fisico, VPS, macchina virtuale o cloud: dove può essere installato
Ubuntu Server può essere eseguito direttamente su hardware fisico oppure all’interno di una macchina virtuale.
Su un computer o un server fisico parti normalmente dall’ISO e dall’installer. Su un VPS o Virtual Private Server, invece, è comune che il provider abbia già preparato un’immagine Ubuntu: scegli la distribuzione nel pannello e pochi secondi dopo ricevi una VM pronta.
Nel cloud il processo è ancora più orientato all’automazione. Le immagini ufficiali Ubuntu sono disponibili per ambienti cloud e virtualizzati e possono essere inizializzate con strumenti come cloud-init.
Questa distinzione evita uno degli errori più frequenti delle vecchie guide: non tutti quelli che vogliono utilizzare Ubuntu Server devono scaricare una ISO e creare una chiavetta USB.
Quale versione di Ubuntu Server scegliere
Per un nuovo server la scelta più prudente è normalmente l’ultima versione LTS compatibile con il tuo software e con l’infrastruttura che utilizzi.
LTS significa Long Term Support. Canonical pubblica una release LTS ogni due anni e garantisce cinque anni di manutenzione di sicurezza standard. Le release intermedie hanno invece un ciclo molto più breve, pari a nove mesi.
Per un laptop destinato a test o sviluppo può avere senso inseguire più rapidamente le nuove funzionalità. Per un server di produzione, aggiornare l’intero sistema operativo ogni pochi mesi introduce invece un costo operativo che raramente porta un vantaggio proporzionato.
LTS e release intermedie: perché per un server la differenza conta
Su un server non devi valutare soltanto quali feature contiene una versione. Devi considerare per quanto tempo riceverà aggiornamenti, quanto a lungo dovrai mantenerla e quanto sarà complessa la migrazione futura.
Una LTS permette di mantenere una base stabile per anni. Questo è particolarmente utile se il sistema ospita servizi che richiedono continuità, dipendenze specifiche o procedure di aggiornamento controllate.
Le release intermedie hanno senso soprattutto per test, sviluppo, hardware molto recente o casi in cui una nuova feature sia realmente necessaria. Come default per un server di produzione, la LTS resta la scelta più semplice da gestire.
Quali versioni di Ubuntu Server sono ancora supportate
Al momento della verifica, la situazione delle principali release LTS è questa:
| Release | Stato | Manutenzione standard | Indicazione pratica |
| Ubuntu 26.04 LTS | LTS più recente | fino a maggio 2031 | Prima scelta per molti nuovi deployment |
| Ubuntu 24.04 LTS | Supportata | fino a maggio 2029 | Ottima se servono compatibilità o stack già validati |
| Ubuntu 22.04 LTS | Supportata | fino a maggio 2027 | Da mantenere dove esiste una ragione tecnica |
| Ubuntu 20.04 LTS | Fuori dalla manutenzione standard | copertura estesa tramite Ubuntu Pro | Non la sceglierei per una nuova installazione generica |
| Ubuntu 25.10 | End of Life | terminata | Da aggiornare, non da installare |
Canonical mantiene una pagina ufficiale sul ciclo di vita delle release Ubuntu che conviene controllare ogni volta che prepari un nuovo server.
Quando scegliere l’ultima LTS e quando restare su una LTS precedente
Se stai creando un nuovo server da zero e non hai vincoli particolari, partire dalla LTS più recente evita di cominciare immediatamente a consumare anni del ciclo di supporto.
Una LTS precedente resta però una scelta perfettamente razionale quando un’applicazione, un pannello di controllo, un software enterprise, un driver o una procedura interna sono certificati soltanto per quella versione.
È un punto importante: “più recente” non significa automaticamente “migliore per ogni workload”. In produzione viene prima la compatibilità del sistema nel suo insieme.
Diverso è continuare a utilizzare una versione che ha già raggiunto l’End of Life. In quel caso non stai semplicemente rinunciando a qualche nuova funzione: stai usando una release che non riceve più i normali aggiornamenti previsti dal suo ciclo di vita.
Requisiti e download di Ubuntu Server
Ubuntu Server può funzionare con risorse contenute, ma i requisiti minimi necessari per completare l’installazione non vanno confusi con le risorse adeguate a un server reale.
La documentazione corrente indica per l’installazione da ISO un minimo di 1,5 GB di RAM e 5 GB di storage. Nella reference Canonical suggerisce però almeno 3 GB di memoria e circa 25 GB di spazio quando vuoi una base più realistica per configurazioni non minimali.
Il dimensionamento vero dipenderà dal workload. Un piccolo server DNS e un database con milioni di record possono usare lo stesso sistema operativo ma avere esigenze completamente diverse.
Requisiti hardware: RAM, spazio e architettura
Ubuntu Server supporta più architetture, tra cui AMD64, ARM64, POWER, RISC-V e IBM Z, anche se la disponibilità delle immagini e i requisiti possono cambiare in base alla piattaforma.
Per un normale server x86-64, la domanda corretta non è quindi “qual è il minimo per avviare Ubuntu?”, ma “quante risorse servono al servizio che dovrò eseguire?”.
Un sistema con 2 GB di RAM può essere sufficiente per un laboratorio o per un piccolo servizio. La stessa quantità può essere totalmente inadeguata se installi database, web server, PHP, cache e più applicazioni contemporaneamente.
Anche lo storage va dimensionato considerando log, backup temporanei, database, aggiornamenti e crescita futura, non soltanto lo spazio occupato dal sistema operativo appena installato.
Dove scaricare l’ISO ufficiale di Ubuntu Server
Per una macchina fisica o una VM sulla quale vuoi effettuare personalmente l’installazione, scarica l’immagine dalla pagina ufficiale di Ubuntu Server.
La pagina identifica chiaramente la LTS corrente e mette a disposizione anche release LTS precedenti ancora supportate, download alternativi e immagini per architetture differenti.
Evita mirror casuali o siti che ridistribuiscono ISO modificate quando non hai una ragione precisa per utilizzarli. Per un sistema operativo server, sapere esattamente da dove proviene l’immagine è parte della sicurezza della macchina.
ISO, cloud image e macchina virtuale: quale immagine serve davvero
L’ISO è corretta quando devi eseguire l’installer: server fisico, VM creata manualmente con un hypervisor o laboratorio nel quale vuoi riprodurre l’intero processo.
Una cloud image è invece già predisposta per l’esecuzione in ambienti virtualizzati e cloud. In questi scenari il provisioning iniziale viene spesso effettuato tramite metadati e cloud-init anziché attraversando manualmente tutte le schermate dell’installer.
Su un VPS commerciale, infine, normalmente non devi scaricare nulla sul tuo computer. Il provider crea direttamente l’istanza dall’immagine Ubuntu selezionata.
La regola pratica è semplice: se il provider ti offre già Ubuntu nel pannello, usa l’immagine del provider salvo esigenze specifiche; se stai installando tu il sistema, usa l’ISO ufficiale o l’immagine adatta al tuo hypervisor.
Come installare Ubuntu Server passo passo
Su una macchina fisica il percorso standard consiste nello scaricare l’ISO, creare un supporto avviabile, fare il boot dall’installer e completare la configurazione del sistema.
Prima di iniziare, fai un backup di qualsiasi dato presente sul disco che andrai a utilizzare. La fase di partizionamento può cancellarne definitivamente il contenuto. Anche la documentazione ufficiale richiama esplicitamente questo rischio.
- Scarica l’ISO ufficiale. Scegli preferibilmente la LTS più recente compatibile con il tuo progetto. Se il sistema è già fornito come VPS o cloud instance, salta l’installazione manuale e passa alla configurazione post-deployment.
- Crea il supporto di installazione. Scrivi l’immagine su una chiavetta USB con uno strumento capace di creare supporti bootable. Per una VM, collega invece l’ISO al lettore virtuale dell’hypervisor.
- Avvia il sistema dall’ISO. Se la macchina non parte automaticamente dalla chiavetta, apri il boot menu o le impostazioni UEFI/BIOS e seleziona il dispositivo corretto.
- Configura lingua e tastiera. L’installer utilizza un’interfaccia testuale guidata. Non farti ingannare dall’assenza della classica GUI: puoi navigare normalmente con tastiera e menu.
- Controlla la rete. Su una rete standard l’installer prova a ottenere automaticamente una configurazione tramite DHCP. Imposta manualmente indirizzo, gateway e DNS soltanto se l’infrastruttura lo richiede.
- Verifica proxy e mirror. Se la rete non utilizza un proxy particolare, normalmente non devi impostarne uno. Lo stesso vale per un mirror personalizzato.
- Configura lo storage. Per un laboratorio o una macchina dedicata interamente a Ubuntu, l’uso dell’intero disco è il percorso più semplice. Su un sistema esistente, con RAID, LVM o layout specifici, controlla attentamente ogni partizione prima di confermare: questa è la fase in cui puoi cancellare dati.
- Crea profilo e hostname. Imposta l’utente amministrativo, una password adeguata e un hostname riconoscibile. Evita nomi generici se gestirai più macchine.
- Decidi se installare OpenSSH Server. Se la macchina verrà amministrata da remoto è normalmente utile installarlo già durante il setup. Dove previsto puoi anche importare una chiave pubblica SSH.
- Completa l’installazione e riavvia. Una volta terminata la copia dei file, rimuovi il supporto di installazione quando richiesto e avvia il sistema appena installato.
Questa sequenza segue l’attuale procedura di installazione documentata da Canonical.
A questo punto Ubuntu è installato, ma non considererei ancora il server pronto per la produzione. Prima devi verificare aggiornamenti, rete, accessi e firewall.
Cosa configurare subito dopo l’installazione
Il primo boot è il momento migliore per costruire una base pulita. L’obiettivo non è applicare una lista infinita di “hardening tricks”, ma controllare gli elementi che possono lasciarti con un sistema obsoleto, irraggiungibile o inutilmente esposto.
Aggiornare Ubuntu Server e i pacchetti installati
La prima operazione è aggiornare l’indice dei repository e installare gli aggiornamenti disponibili:
sudo apt update sudo apt upgrade
apt update non aggiorna i programmi: aggiorna l’indice locale dei pacchetti disponibili. È apt upgrade che installa le nuove versioni compatibili dei pacchetti già presenti.
Se un aggiornamento richiede il riavvio puoi verificarlo con:
test -f /run/reboot-required && echo "Riavvio richiesto"
e, quando opportuno:
sudo reboot
Ubuntu utilizza inoltre unattended-upgrades per applicare automaticamente gli aggiornamenti di sicurezza secondo la configurazione del sistema. Questo però non significa che tu possa dimenticarti della manutenzione: repository esterni, applicazioni installate manualmente, container e servizi possono seguire cicli separati.
Controllare hostname, indirizzo IP, DNS e connettività
Prima di installare servizi controlla cosa vede realmente la macchina.
Per l’hostname:
hostnamectl
Per gli indirizzi di rete:
ip -br address
Per la route predefinita:
ip route
Per la configurazione del resolver DNS:
resolvectl status
Infine verifica la raggiungibilità verso l’esterno e la risoluzione dei nomi.
Questi controlli vanno separati. Un server può avere un indirizzo IP corretto ma un gateway errato, oppure raggiungere Internet usando gli IP senza riuscire a risolvere i domini perché il DNS non funziona.
Impostare un indirizzo IP statico con Netplan quando serve
Su Ubuntu la configurazione di rete viene normalmente descritta tramite Netplan, che utilizza file YAML e genera la configurazione per il backend di rete effettivo.
Prima identifica il nome reale della tua interfaccia:
ip -br link
Potrebbe chiamarsi ens18, enp1s0, eno1 o in altro modo. Non copiare quindi alla cieca il nome presente in una guida.
Una configurazione statica semplificata può avere questa forma:
network:
version: 2
renderer: networkd
ethernets:
ens18:
dhcp4: false
addresses:
- 192.168.1.50/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
IP, prefisso, gateway, DNS e nome dell’interfaccia sono soltanto esempi e devono essere sostituiti con i valori della tua rete.
La configurazione Netplan si trova normalmente sotto /etc/netplan/. Se stai lavorando da remoto, invece di applicare immediatamente una modifica potenzialmente sbagliata è molto più prudente usare:
sudo netplan try
Il comando applica temporaneamente la nuova configurazione e può effettuare il rollback se non viene confermata. È stato previsto proprio per ridurre il rischio di perdere l’accesso remoto durante una modifica di rete.
Su VPS e cloud, però, non modificare la rete soltanto perché una guida ti dice di impostare un IP statico. L’indirizzamento può essere gestito dal provider, da cloud-init o da configurazioni specifiche della piattaforma. Prima controlla la documentazione del provider.
Configurare OpenSSH e l’autenticazione con chiavi
SSH è il principale strumento di amministrazione remota di un server Linux. Il componente server di OpenSSH è sshd, che rimane in ascolto e crea una sessione cifrata quando un client autorizzato si collega.
Se non hai installato OpenSSH durante il setup:
sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh
Controlla poi lo stato:
sudo systemctl status ssh
Da un altro computer puoi collegarti con:
ssh nomeutente@indirizzo-ip
Per un server accessibile da Internet è preferibile utilizzare l’autenticazione con chiavi. Sul client puoi generare una chiave Ed25519:
ssh-keygen -t ed25519
e copiare la chiave pubblica sul server, nei sistemi che dispongono di ssh-copy-id, con:
ssh-copy-id nomeutente@indirizzo-ip
Prima di disattivare il login tramite password, apri una seconda sessione e verifica che la chiave funzioni realmente. È un dettaglio semplice, ma evita di tagliarti fuori dalla macchina.
Se modifichi la configurazione SSH, verifica la sintassi prima di ricaricare il servizio:
sudo sshd -t
Solo se il comando non segnala errori:
sudo systemctl reload ssh
Se vuoi trasferire file utilizzando lo stesso ecosistema SSH, puoi approfondire anche la nostra guida a SFTP.
Attivare UFW senza perdere l’accesso SSH
Ubuntu utilizza UFW, Uncomplicated Firewall, come frontend semplificato per la configurazione del firewall host. La configurazione iniziale di UFW è disabilitata.
Su un server amministrato via SSH, la sequenza è fondamentale.
Prima autorizza l’accesso SSH:
sudo ufw allow OpenSSH
Poi abilita il firewall:
sudo ufw enable
Infine controlla le regole:
sudo ufw status verbose
Se hai spostato SSH su una porta personalizzata, devi aprire quella porta prima di attivare UFW.
Quando installerai un web server potrai aggiungere soltanto le porte realmente necessarie, normalmente HTTP e HTTPS se il server deve essere pubblico.
Il principio è più importante dei comandi: un firewall non deve aprire “le porte che potrebbero servire”, ma soltanto quelle associate ai servizi che vuoi rendere raggiungibili.
Aggiornamenti di sicurezza, Ubuntu Pro e Livepatch: quando servono
La manutenzione standard di una LTS copre cinque anni. Ubuntu Pro estende la copertura di sicurezza e aggiunge servizi come Expanded Security Maintenance e Kernel Livepatch; per uso personale Canonical rende disponibile Ubuntu Pro gratuitamente fino a cinque macchine.
Livepatch permette di applicare determinate correzioni al kernel senza richiedere immediatamente un riavvio. È utile soprattutto quando la continuità del servizio ha un valore operativo elevato.
Non va però interpretato come “il server non deve più essere riavviato”. Aggiornamenti diversi dalle patch live del kernel, cambi di configurazione e manutenzione applicativa possono continuare a richiedere finestre di intervento.
Per un piccolo laboratorio Ubuntu Pro è quindi opzionale. Su sistemi che devono rimanere online a lungo o su infrastrutture con requisiti di sicurezza più elevati, merita una valutazione più attenta.
Come gestire Ubuntu Server dalla riga di comando
Non serve conoscere centinaia di comandi Linux prima di utilizzare Ubuntu Server. Serve invece capire quali strumenti controllano pacchetti, servizi, log e risorse.
Una volta interiorizzati questi quattro livelli, la mancanza di una GUI smette rapidamente di essere un limite.
Installare e aggiornare software con APT
APT gestisce i pacchetti .deb provenienti dai repository configurati nel sistema.
Il ciclo di base è:
sudo apt update sudo apt install nome-pacchetto
Per rimuovere un programma:
sudo apt remove nome-pacchetto
Per aggiornare i pacchetti già presenti:
sudo apt update sudo apt upgrade
È utile anche capire da dove arrivano i pacchetti. Nelle versioni moderne di Ubuntu i repository ufficiali vengono descritti tramite file sotto /etc/apt/sources.list.d/, con ubuntu.sources come configurazione principale nelle release recenti.
Aggiungere repository esterni senza verificarne origine, manutenzione e compatibilità aumenta invece il numero di componenti che dovrai controllare durante aggiornamenti e major upgrade.
Avviare, fermare e controllare servizi con systemd
Molti software server vengono eseguiti come servizi gestiti da systemd.
Per vedere lo stato di un servizio:
sudo systemctl status ssh
Per avviarlo:
sudo systemctl start ssh
Per fermarlo:
sudo systemctl stop ssh
Per abilitarne l’avvio automatico:
sudo systemctl enable ssh
Quando un servizio non parte, non limitarti a ripetere restart. Guarda anche i log:
sudo journalctl -u ssh
Questo passaggio cambia il modo in cui affronti i problemi: invece di provare comandi casualmente, puoi cercare l’errore che ha impedito al servizio di partire.
Controllare disco, memoria, rete e processi
Pochi comandi permettono di capire rapidamente lo stato della macchina.
Spazio disco:
df -h
Memoria:
free -h
Carico e uptime:
uptime
Porte e servizi in ascolto:
sudo ss -tulpn
Indirizzi di rete:
ip -br address
Processi che utilizzano più memoria:
ps aux --sort=-%mem | head
ss -tulpn è particolarmente utile dopo aver installato un nuovo servizio: ti permette di verificare se e su quale indirizzo/porta sta realmente ascoltando prima ancora di intervenire su firewall o DNS.
Ubuntu Server ha un’interfaccia grafica?
No, Ubuntu Server non installa una GUI per impostazione predefinita. L’immagine ufficiale Server è progettata per un utilizzo che può essere interamente amministrato da console o attraverso SSH.
Questo non impedisce di installare successivamente un desktop environment. La vera domanda è se aggiungerlo migliori davvero il tuo scenario.
Perché la GUI non viene installata di default
Un ambiente desktop porta con sé display server, librerie grafiche, servizi, applicazioni e dipendenze che hanno senso su una workstation ma possono essere inutili su una macchina destinata soltanto a eseguire servizi.
Evitarli significa mantenere il sistema più essenziale. Non rende automaticamente il server “sicuro” o “veloce”, ma elimina componenti che non avrebbero una funzione concreta nel workload.
L’amministrazione remota tramite SSH ha inoltre un vantaggio pratico enorme: puoi gestire la macchina anche se si trova in un data center, su un VPS o in un’altra nazione senza trasferire un intero desktop grafico.
Quando installare un desktop environment ha senso
Una GUI può avere senso per un laboratorio, una macchina utilizzata anche localmente, software amministrativi che richiedono esplicitamente un ambiente grafico o utenti che devono interagire con applicazioni desktop sul server.
È meno convincente installarla soltanto perché il terminale sembra inizialmente più difficile.
La maggior parte delle operazioni server importanti — aggiornamenti, servizi, firewall, utenti, log, rete e automazione — rimane comunque basata sugli stessi componenti di sistema. Imparare a gestirli direttamente ti dà quindi più controllo anche se in seguito deciderai di aggiungere un’interfaccia grafica.
Quando è meglio amministrare il server via SSH
Per VPS, server cloud, web server e macchine headless sceglierei normalmente SSH.
Richiede pochissima banda, può utilizzare chiavi crittografiche, si integra con SFTP e automazione e non dipende dalla disponibilità di un ambiente desktop remoto.
Una GUI non sostituisce inoltre una corretta amministrazione: se devi capire perché Nginx non parte o quale processo sta occupando una porta, finirai comunque per consultare servizi e log.
Ubuntu Server su VPS, cloud e macchina virtuale
Il modo in cui ottieni Ubuntu cambia molto tra hardware fisico e infrastrutture virtualizzate.
Questo è uno dei punti in cui molte vecchie guide all’installazione diventano fuorvianti: descrivono correttamente l’installer da ISO, ma lasciano intendere che sia il percorso normale anche per chi ha appena acquistato un VPS.
Perché su un VPS normalmente non devi installare l’ISO manualmente
Quando acquisti un VPS, il provider dispone normalmente di immagini già pronte dei sistemi operativi supportati.
Se scegli Ubuntu, la piattaforma crea la macchina virtuale, prepara disco e rete e avvia l’immagine selezionata. A te resta soprattutto la configurazione del sistema e delle applicazioni.
Questo rende il provisioning molto più rapido, ma cambia anche le responsabilità. La configurazione iniziale della rete, dell’utente o delle chiavi SSH può essere generata automaticamente dal provider. Prima di modificare questi elementi verifica quindi come è stata costruita l’istanza.
Se stai ancora scegliendo l’infrastruttura, abbiamo approfondito anche le differenze tra cloud hosting e VPS hosting.
Provare Ubuntu Server in una VM con Multipass
Se vuoi imparare senza rischiare di rompere un server reale, una macchina virtuale locale è un ottimo laboratorio.
Canonical propone Multipass come metodo rapido per creare VM Ubuntu e lo rende disponibile su Linux, Windows e macOS.
Una volta installato Multipass puoi creare una macchina basata sulla LTS corrente con:
multipass launch lts --name ubuntu-server
Per entrare nella VM:
multipass shell ubuntu-server
Hai così a disposizione un ambiente nel quale provare APT, systemd, rete e configurazioni senza toccare il sistema host.
È uno scenario molto più utile che imparare direttamente su una macchina pubblica: puoi fare errori, eliminare l’istanza e ricominciare.
Cloud-init e provisioning automatico: cosa cambia quando gestisci più server
Installare e configurare manualmente una macchina è ragionevole. Farlo identicamente su cinquanta macchine non lo è.
Negli ambienti cloud entra quindi in gioco il provisioning automatico. Le Ubuntu Cloud Images possono utilizzare cloud-init per applicare configurazioni iniziali come utenti, chiavi SSH, hostname, pacchetti e altri parametri durante la creazione dell’istanza. La stessa pagina di download Ubuntu distingue oggi installazione manuale, VM istantanee e provisioning automatizzato come percorsi differenti.
Il vantaggio non è soltanto andare più velocemente. L’automazione permette di descrivere una configurazione e riprodurla, riducendo le differenze create da interventi manuali eseguiti in momenti diversi.
Questo diventa fondamentale quando il server smette di essere “una macchina da configurare” e diventa parte di un’infrastruttura.
Cosa installare su Ubuntu Server dopo la configurazione base
Non esiste un pacchetto standard da installare dopo Ubuntu Server. Dipende dal servizio che la macchina deve fornire.
È preferibile partire dal workload e aggiungere solo ciò che serve, anziché trasformare il sistema in una raccolta di software “che potrebbe tornare utile”.
Web server: Apache o Nginx
Se la macchina deve pubblicare siti e applicazioni web, avrai bisogno di un server HTTP oppure di un componente equivalente nello stack applicativo.
Apache rimane una delle opzioni più note e dispone di un’architettura modulare molto flessibile. Se vuoi approfondire configurazione e funzionamento puoi consultare la nostra guida su Apache HTTP Server.
Nginx è un’altra scelta molto diffusa e può essere utilizzato come server HTTP, reverse proxy e componente davanti ad applicazioni o altri web server.
Non scegliere tra i due solo in base a una classifica generica. Conta il tipo di applicazione, le configurazioni che devi supportare e l’architettura complessiva.
Database: MySQL, MariaDB o PostgreSQL
Se l’applicazione conserva dati persistenti potresti aver bisogno di un database relazionale come MySQL, MariaDB o PostgreSQL.
Per WordPress, MySQL e MariaDB sono opzioni particolarmente comuni. Nella nostra guida dedicata puoi approfondire come funziona MySQL.
Il database non deve necessariamente essere installato sulla stessa VM del web server. Per piccoli progetti è una scelta semplice; con infrastrutture più complesse può essere utile separare i ruoli oppure utilizzare un database gestito.
È un buon esempio del principio visto all’inizio: Ubuntu è il sistema operativo, mentre web server e database sono servizi indipendenti che costruisci sopra quella base.
Trasferimento file sicuro tramite SFTP
Se OpenSSH è già attivo, puoi sfruttare SFTP per il trasferimento cifrato dei file senza installare un classico server FTP separato.
Questo è utile quando devi caricare configurazioni, distribuire file o effettuare operazioni di manutenzione in modo controllato.
Non confondere SFTP con FTPS: sono tecnologie differenti. SFTP opera attraverso SSH, mentre FTPS è FTP protetto tramite TLS.
Container e servizi applicativi
Ubuntu Server è anche una base comune per l’esecuzione di container.
Docker, containerd, LXD e altri strumenti permettono di isolare applicazioni e dipendenze senza creare necessariamente una VM completa per ogni servizio.
Anche qui, però, containerizzare non elimina la gestione del server sottostante. Devi continuare a mantenere sistema operativo, storage, rete, aggiornamenti, accessi e backup, oltre alle immagini e ai workload eseguiti nei container.
Errori comuni quando configuri il tuo primo Ubuntu Server
Molti problemi dei primi server non derivano da comandi complessi. Nascono da decisioni apparentemente piccole fatte senza considerare cosa succede dopo.
Usare una release non più supportata
Installare una guida vecchia alla lettera può portarti a scegliere una release che ha già terminato il proprio ciclo di supporto.
Prima di iniziare controlla sempre lo stato della versione. Se un tutorial ti chiede di installare una release molto vecchia, chiediti se la versione sia realmente necessaria oppure se sia semplicemente l’età del tutorial a determinarla.
Per un server pubblico, partire volontariamente da una versione EOL non è una scorciatoia: significa costruire sopra fondamenta che non ricevono più la normale manutenzione prevista.
Attivare il firewall prima di consentire SSH
Se amministri la macchina da remoto, una modifica al firewall può interrompere la stessa connessione che stai utilizzando per configurarla.
Per questo il corretto ordine operativo è:
verifica SSH → consenti SSH nel firewall → abilita UFW → verifica una seconda connessione
Non chiudere la sessione attiva finché non hai confermato che una nuova sessione riesce a collegarsi.
Lo stesso principio vale per Netplan e per ogni modifica alla rete: prima devi avere una strategia di rollback.
Esporre servizi che non devono essere raggiungibili da Internet
Installare un servizio non significa che debba essere accessibile pubblicamente.
Un database usato soltanto dall’applicazione locale, per esempio, non ha normalmente bisogno di ascoltare sull’IP pubblico. Lo stesso vale per pannelli di amministrazione, sistemi di cache o strumenti interni.
Puoi verificare cosa sta ascoltando con:
sudo ss -tulpn
Controlla poi sia il binding del servizio sia il firewall. Un firewall è un livello di protezione importante, ma la configurazione dell’applicazione deve essere coerente con il ruolo reale del servizio.
Confondere IP dinamico, IP statico e IP pubblico
“IP statico” e “IP pubblico” non sono sinonimi.
Un indirizzo statico è un indirizzo che non cambia secondo la modalità di assegnazione prevista. Un indirizzo pubblico è invece instradabile su Internet. Un server può avere un IP statico privato dietro NAT oppure un IP pubblico gestito dal provider senza che tu debba configurarlo manualmente nell’interfaccia.
Prima di modificare Netplan devi quindi capire quale livello della rete stai configurando.
Su un VPS, ciò che compare nel pannello del provider e ciò che vedi dentro la macchina possono inoltre dipendere dall’architettura di rete usata dal provider.
Installare software senza aggiornare prima il sistema
Una nuova installazione può essere stata creata da un’immagine costruita giorni o settimane prima. Aggiornare l’indice APT e i pacchetti disponibili prima di costruire lo stack riduce il rischio di partire con componenti già superati.
Lo stesso vale nel tempo: mantenere Ubuntu aggiornato ma ignorare completamente WordPress, applicazioni, container, librerie installate esternamente o software del vendor significa curare soltanto uno strato della macchina.
La sicurezza del server dipende dall’intero stack, non dal solo sistema operativo.
Conclusione
Ubuntu Server è una base Linux versatile per costruire server fisici, VPS, macchine virtuali e istanze cloud. La sua installazione può essere molto semplice; ciò che distingue un ambiente di prova da un sistema realmente gestibile sono soprattutto le decisioni successive.
Per un nuovo deployment sceglierei normalmente una release LTS supportata, evitando versioni EOL e mantenendo una release precedente soltanto quando esiste un requisito concreto di compatibilità. Su hardware fisico puoi partire dall’ISO; su VPS e cloud conviene invece sfruttare le immagini e il provisioning messi a disposizione dalla piattaforma.
Dopo il primo avvio, le priorità sono altrettanto chiare: aggiornare i pacchetti, verificare rete e DNS, configurare correttamente SSH, consentire l’accesso remoto prima di attivare UFW e controllare quali servizi stanno realmente ascoltando sulla macchina.
Da lì in poi non esiste una configurazione Ubuntu Server universale. Un web server, un database, un nodo container e un file server hanno requisiti e superfici di attacco differenti. Installa quindi soltanto i componenti necessari al servizio che devi offrire e documenta ogni scelta che modifica rete, accessi e sicurezza.
È questo il passaggio che conta davvero: non avere semplicemente “Ubuntu installato”, ma costruire un server di cui sai spiegare configurazione, responsabilità e comportamento.