1 21/10/2026 10 min

Tomcat 10 su Ubuntu 20.04: prima il Java giusto, poi il servizio

Su Ubuntu 20.04 il punto non è solo “installare Tomcat”, ma farlo partire con una base pulita: Java compatibile, utente non privilegiato, directory ordinate e un servizio systemd che si comporti bene al riavvio. Tomcat 10 è la linea che segue Jakarta EE 9, quindi non è un semplice drop-in rispetto a Tomcat 9 per applicazioni legacy. Se l’obiettivo è un server applicativo stabile, conviene impostarlo subito in modo ripetibile, invece di improvvisare con un tarball scompattato alla mano e permessi messi a caso.

La procedura qui sotto usa l’archivio ufficiale Apache, perché è la via più lineare quando vuoi controllare versione, path e configurazione. Su Ubuntu 20.04 puoi anche trovare pacchetti, ma spesso sono vecchi o meno allineati alla release che vuoi davvero usare. La regola pratica è semplice: prima verifichi Java, poi scarichi Tomcat, poi lo colleghi a systemd, infine apri la porta solo se serve davvero esporlo direttamente.

Verifica del prerequisito: Java compatibile

Tomcat 10 richiede una JVM moderna. Su Ubuntu 20.04 la scelta più lineare è OpenJDK 11 o superiore. Se installi Tomcat e poi scopri che il servizio fallisce con errori sulla versione Java, hai già perso tempo e hai un servizio che non parte. Quindi questo controllo va fatto subito.

Esegui:

java -version

Il risultato deve mostrare una versione supportata, per esempio OpenJDK 11. Se il comando non esiste o restituisce una versione troppo vecchia, installa il runtime:

sudo apt update
sudo apt install -y openjdk-11-jdk

Controlla di nuovo:

java -version
readlink -f /usr/bin/java

Se in ambiente server vuoi tenere separato il JDK dal resto del sistema, annota il path reale del binario: servirà per il file di servizio o per il file di ambiente di Tomcat.

Utente dedicato e directory di lavoro

Tomcat non va eseguito come root. Crea un account di servizio senza shell interattiva e prepara una struttura coerente sotto /opt. È una scelta banale ma evita metà dei problemi classici: permessi sbagliati, file temporanei scritti dal proprietario errato, log non leggibili e aggiornamenti fatti “a mano” in una directory casuale.

Crea utente e gruppo:

sudo useradd -r -m -U -d /opt/tomcat -s /usr/sbin/nologin tomcat

Se la directory esiste già perché hai provato installazioni precedenti, verifica prima di sovrascrivere. In caso di ambiente già sporco, meglio ripulire con criterio piuttosto che sovrapporre file di release diverse.

Installa gli strumenti utili per il download e l’estrazione:

sudo apt install -y curl tar

Scarica Tomcat 10 dal sito Apache. Sostituisci la versione con quella che vuoi adottare; qui uso un esempio realistico. Se vuoi validare l’integrità, prendi anche checksum e firma dalla pagina ufficiale della release.

cd /tmp
curl -O https://downloads.apache.org/tomcat/tomcat-10/v10.1.24/bin/apache-tomcat-10.1.24.tar.gz

Estrai e sposta i file nella directory finale:

sudo tar xzf apache-tomcat-10.1.24.tar.gz -C /opt/tomcat --strip-components=1
sudo chown -R tomcat:tomcat /opt/tomcat

Verifica che la struttura sia coerente:

ls -l /opt/tomcat
ls -l /opt/tomcat/bin /opt/tomcat/conf

In questa fase devi vedere directory come bin, conf, lib, webapps, logs, temp e work.

Avvio manuale per capire subito se la base regge

Prima di scrivere il servizio systemd, fai un avvio manuale sotto l’utente dedicato. Se Tomcat non parte così, il problema è nella base: Java, permessi o configurazione. Se parte, hai una linea di partenza pulita per il servizio permanente.

Usa il classico script di startup:

sudo -u tomcat /opt/tomcat/bin/startup.sh

Controlla il log principale:

tail -n 50 /opt/tomcat/logs/catalina.out

Se il processo si blocca, gli errori tipici sono immediati: Java non trovato, porta occupata, permessi insufficienti sul filesystem, oppure configurazione XML non valida. Anche il controllo delle porte è utile:

ss -ltnp | grep 8080

Se la porta 8080 è già occupata, devi scegliere: cambiare porta di Tomcat o liberare il servizio che la usa. Non forzare il riuso senza capire chi sta ascoltando. Su un server con più stack applicativi la collisione sulla porta è una delle cause più banali e più frequenti.

Configurazione minima utile: utenti, porte e memoria

Il file da toccare con più attenzione è /opt/tomcat/conf/server.xml. Non serve riscriverlo da zero. Conviene modificare solo ciò che ti serve davvero: porta HTTP, eventuale connettore AJP se lo usi davvero, e impostazioni coerenti con il reverse proxy.

Per un’installazione base puoi lasciare la porta 8080. Se invece Tomcat deve stare dietro Apache o Nginx, spesso è meglio mantenerlo su localhost e pubblicarlo solo tramite proxy. In quel caso il connettore HTTP può rimanere in ascolto su 127.0.0.1 oppure puoi gestire l’esposizione a livello di firewall. La scelta dipende dal disegno della rete, non da una preferenza estetica.

Per impostare la memoria JVM in modo esplicito, crea un file di ambiente dedicato. È più pulito che infilare parametri sparsi in script di startup. Ad esempio:

sudo nano /opt/tomcat/bin/setenv.sh

Contenuto minimo:

export CATALINA_OPTS="-Xms512m -Xmx1024m -Djava.awt.headless=true"
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

Rendi eseguibile lo script:

sudo chmod +x /opt/tomcat/bin/setenv.sh

Qui il punto non è “mettere tanta memoria”, ma dare al garbage collector un margine coerente con il carico reale. Se il server è piccolo, 1 GB per Tomcat potrebbe essere già troppo. Se ospita applicazioni pesanti, va dimensionato in base a heap, permgen/metaspace e pressione del sistema nel complesso.

Servizio systemd: avvio automatico e gestione pulita

Per un server serio, Tomcat deve essere gestito da systemd. Così ottieni restart automatico, logging coerente e un lifecycle chiaro. Il file di unità può stare in /etc/systemd/system/tomcat.service.

Crealo con questo contenuto di base:

[Unit]
Description=Apache Tomcat 10
After=network.target [Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/opt/tomcat"
Environment="CATALINA_OPTS=-Xms512m -Xmx1024m -Djava.awt.headless=true"
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh
Restart=on-failure
RestartSec=10 [Install]
WantedBy=multi-user.target

Dopo aver salvato il file, ricarica systemd e avvia il servizio:

sudo systemctl daemon-reload
sudo systemctl enable --now tomcat

Controlla lo stato:

systemctl status tomcat --no-pager
journalctl -u tomcat -n 50 --no-pager

Se il servizio fallisce subito, guarda prima il journal. Spesso il problema è banale: variabile JAVA_HOME errata, permessi sul file tomcat.pid, oppure un path non coerente con l’installazione effettiva di Java. Non correggere alla cieca: verifica il path reale con readlink -f e confrontalo con la configurazione.

Accesso all’interfaccia manager e sicurezza minima

Tomcat include applicazioni di amministrazione, ma non vanno lasciate aperte senza criterio. Se abiliti manager e host-manager, limita l’accesso e definisci credenziali forti. Su un host esposto, lasciare queste interfacce pubbliche è una pessima idea. La superficie d’attacco aumenta senza alcun vantaggio operativo reale.

Modifica il file /opt/tomcat/webapps/manager/META-INF/context.xml o le regole di accesso previste dalla tua distribuzione Tomcat, poi regola gli utenti in /opt/tomcat/conf/tomcat-users.xml. Un esempio minimo può essere questo:

<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<user username="tomcatadmin" password="PASSWORD_FORTE" roles="manager-gui,admin-gui"/>

Non usare password deboli e non lasciare segreti in chiaro in repository, ticket o script condivisi. Se devi automatizzare, sposta le credenziali in un secret manager o in un file con permessi stretti e gestione controllata. Se hai già esposto una password in ambienti non fidati, trattala come compromessa e ruotala.

Firewall e pubblicazione del servizio

Se Tomcat deve essere raggiungibile direttamente sulla porta 8080, verifica che il firewall lo consenta solo dal perimetro previsto. Su Ubuntu con UFW puoi aprire la porta in modo esplicito, ma solo se hai davvero bisogno di esporla.

sudo ufw allow 8080/tcp
sudo ufw status verbose

In molti casi però è meglio non pubblicare 8080 verso internet e mettere davanti un reverse proxy come Apache o Nginx su 80/443. Così centralizzi TLS, header, compressione e regole di accesso. Tomcat resta un backend applicativo, non un front-end esposto inutilmente.

Se usi un proxy, controlla che il forwarding sia corretto e che l’applicazione riceva lo schema giusto. In particolare alcune app dipendono da header come X-Forwarded-Proto o da un connettore configurato per riconoscere il proxy. Se non li imposti bene, puoi ritrovarti redirect sbagliati, cookie non marcati correttamente o URL assoluti incoerenti.

Verifica funzionale: risposta HTTP e pagina di default

A questo punto Tomcat dovrebbe rispondere. Dal server stesso o da un host autorizzato, prova una richiesta HTTP semplice:

curl -I http://127.0.0.1:8080

Il ritorno atteso è un codice 200 o comunque una risposta coerente con la pagina iniziale. Se vedi timeout, connection refused o 5xx, torna ai log. Se invece il browser mostra la pagina di benvenuto di Tomcat, l’installazione di base è andata a buon fine.

Per una verifica più concreta, controlla che il processo sia in esecuzione e che il PID file esista:

ps -ef | grep tomcat | grep -v grep
cat /opt/tomcat/temp/tomcat.pid

Se il PID non coincide con il processo reale o il file non viene creato, il servizio non sta gestendo correttamente il lifecycle. In quel caso il problema è quasi sempre nel file systemd o nei permessi della directory temp.

Aggiornamento corretto: sostituire la release senza rompere tutto

Tomcat non si aggiorna “sopra” in modo cieco. La strada meno rischiosa è fermare il servizio, conservare config e applicazioni, sostituire i binari della release e riavviare. Se hai customizzazioni in conf o webapp proprie, trattale come materiale da versionare. È qui che molti ambienti si rompono: si aggiorna il pacchetto ma si perdono file modificati a mano.

Prima di cambiare versione, fai un backup minimo di configurazione e applicazioni installate:

sudo tar czf /root/tomcat-conf-backup-$(date +%F).tar.gz -C /opt/tomcat conf webapps

Poi sostituisci i file della nuova release nella stessa directory o in una nuova base, a seconda della tua strategia operativa. Se preferisci un rollout più ordinato, puoi tenere installazioni versionate in /opt/tomcat-10.1.x e cambiare un symlink. È più pulito per rollback rapidi, soprattutto quando hai finestre di manutenzione strette.

Problemi tipici e lettura rapida dei log

Se Tomcat non parte, la sequenza di controllo non cambia: log, porte, Java, permessi. In pratica, i casi più frequenti sono questi:

  • Java non installato o JAVA_HOME errato.
  • Porta 8080 già occupata da un altro servizio.
  • Permessi errati su /opt/tomcat o sulle directory temporanee.
  • Configurazione XML rotta in server.xml o tomcat-users.xml.
  • Heap troppo basso o troppo alto rispetto alla RAM disponibile.

Per leggere i log in modo utile, non limitarti al file più recente. Usa sia il journal di systemd sia il log applicativo di Tomcat. Il primo ti dice se il servizio è partito e con quale exit code; il secondo ti mostra i dettagli del bootstrap e degli errori Java. La combinazione dei due di solito basta per chiudere il cerchio senza tentativi a caso.

Comandi utili:

journalctl -u tomcat -b --no-pager
tail -n 100 /opt/tomcat/logs/catalina.out

Se il messaggio parla di Address already in use, il problema è quasi certamente una collisione di porta. Se parla di Permission denied, è un problema di ownership o di policy SELinux/AppArmor se presente. Se il log si ferma senza stacktrace chiaro, spesso c’è un errore di configurazione molto iniziale che richiede di leggere le righe precedenti, non solo l’ultima.

Conclusione operativa: installazione pronta, ma mantenuta con disciplina

Installare Apache Tomcat 10 su Ubuntu 20.04 è semplice solo quando la sequenza è ordinata: Java verificato, utente dedicato, file estratti in /opt, avvio controllato, servizio systemd, e sicurezza minima sulle interfacce amministrative. La parte davvero importante non è il primo avvio, ma la capacità di ripetere la procedura senza dubbi e senza introdurre regressioni.

Se poi devi metterlo in produzione, fai un passo in più: reverse proxy davanti, TLS terminato correttamente, log ruotati, backup della configurazione e un canale di rollback già deciso prima del cambio. Tomcat funziona bene quando viene trattato come componente di piattaforma, non come eccezione artigianale lasciata a sé stessa.