Come installare MongoDB 6.0 su Ubuntu 22.04

Su Ubuntu 22.04 la strada giusta per MongoDB 6.0 è il repository ufficiale di MongoDB, non il pacchetto del repository standard di Ubuntu. La differenza non è cosmetica: con il repo ufficiale controlli versione, aggiornamenti e compatibilità in modo prevedibile, evitando di ritrovarti con una release diversa da quella che pensavi di aver installato.

Qui sotto trovi una procedura pulita per installare MongoDB 6.0, verificarne lo stato, fare un controllo minimo di sicurezza e lasciare una base sensata per l’uso in produzione o in laboratorio.

Prerequisiti e scelta del repository

Ubuntu 22.04 usa di default librerie e toolchain che sono compatibili con MongoDB 6.0, ma il punto critico è il repository APT. MongoDB pubblica i propri pacchetti per architetture e release specifiche: su 22.04 devi usare il ramo jammy. Se punti al ramo sbagliato, il problema non è solo l’errore di installazione: rischi dipendenze incoerenti o aggiornamenti che non arrivano come previsto.

Prima di toccare il sistema, verifica due cose: versione del sistema operativo e architettura. In genere basta questo:

lsb_release -a
uname -m

Atteso: Ubuntu 22.04.x e architettura x86_64 o aarch64 supportata dai pacchetti MongoDB. Se sei su un ambiente non standard o containerizzato, chiudi il gap controllando la compatibilità sul nodo reale e non nel solo layer container.

Aggiunta della chiave e del repository APT

MongoDB distribuisce il proprio repository firmato. Oggi il modo corretto è usare un keyring dedicato in /usr/share/keyrings/, non importare chiavi nel vecchio keyring globale APT. Questo riduce confusione e ti lascia un tracciato pulito di cosa firma cosa.

Procedura consigliata:

1. Installa i pacchetti utili per scaricare e verificare la chiave.
2. Scarica la chiave pubblica ufficiale di MongoDB.
3. Salvala come keyring dedicato.
4. Aggiungi il repository per mongodb-org 6.0 su jammy.

sudo apt update
sudo apt install -y gnupg curl

curl -fsSL https://pgp.mongodb.com/server-6.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-6.0.gpg

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list

Se l’architettura è diversa da amd64 o arm64, fermati e verifica il supporto reale del pacchetto prima di andare oltre. Non forzare installazioni “a colpi di dpkg”: è il modo più rapido per ritrovarti con un sistema in stato ambiguo.

A questo punto aggiorna l’indice pacchetti e controlla che il repository sia visibile:

sudo apt update
apt-cache policy mongodb-org

Atteso: tra le versioni candidate compare 6.0.x dal repository MongoDB. Se vedi errore di firma, quasi sempre il problema è la chiave scaricata male, una rete con proxy che altera il download, oppure un file .list scritto in modo errato.

Installazione di MongoDB 6.0

Il pacchetto da installare è mongodb-org, che porta con sé server, shell e strumenti di base. Non serve inventare combinazioni strane di pacchetti singoli se il tuo obiettivo è una installazione standard e mantenibile.

sudo apt install -y mongodb-org

Il pacchetto installa tipicamente questi componenti: mongod come demone, mongosh come shell, e utility come backup tool e strumenti client. Se l’installazione fallisce per dipendenze bloccate, il comando utile è leggere l’errore completo di APT invece di riprovare a vuoto: spesso indica il pacchetto mancante o un conflitto con installazioni precedenti.

Se hai già una vecchia installazione di MongoDB da repository esterni o pacchetti manuali, la verifica preliminare è obbligatoria. Controlla cosa è presente prima di sovrascrivere:

dpkg -l | grep -E '^ii\s+(mongodb|mongo)'
apt-cache policy mongodb-org

Se emergono pacchetti legacy, valuta la migrazione con cautela. Non mescolare repository diversi per la stessa major release: aumenta il rischio di conflitti sulle dipendenze e rende più difficile il rollback.

Avvio del servizio e verifica operativa

Su Ubuntu 22.04 il servizio viene gestito da systemd. Dopo l’installazione, MongoDB potrebbe essere già abilitato e avviato; in ogni caso conviene esplicitarlo e verificare lo stato subito.

sudo systemctl enable --now mongod
sudo systemctl status mongod --no-pager

Condizione OK: il servizio risulta active (running). Se lo stato è failed, guarda i log prima di cambiare configurazione:

journalctl -u mongod -n 100 --no-pager

Una causa comune in installazioni non pulite è il permesso errato sulla directory dati o sulla directory log. Le posizioni standard sono /var/lib/mongodb per i dati e /var/log/mongodb per i log. Se sono state modificate, il file di configurazione da controllare è /etc/mongod.conf.

Verifica anche che il processo stia ascoltando sulla porta prevista:

ss -lntp | grep 27017

Atteso: un listener su 127.0.0.1:27017 o sull’indirizzo configurato. Se la porta non è in ascolto ma il servizio è attivo, il problema è quasi sempre nella configurazione di bind o in un errore all’avvio che non hai ancora letto nel journal.

Connessione locale con mongosh

La verifica più semplice è una connessione locale con mongosh. Non serve autenticazione se non hai ancora abilitato utenti e ruoli.

mongosh --eval 'db.runCommand({ ping: 1 })'

Atteso: risposta con { ok: 1 }. Se il ping fallisce, distingui subito tra problema di socket, problema di avvio del demone e problema di autenticazione. In questa fase, se l’installazione è appena stata fatta, autenticazione e TLS di norma non sono ancora il collo di bottiglia.

Per una verifica più completa, apri la shell e controlla lo stato del server:

mongosh
> db.serverStatus().version
> db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

La versione deve essere 6.0.x. Se la shell si apre ma le query amministrative danno errore, controlla di essere sul server giusto e non su un’istanza remota raggiunta per errore tramite DNS o alias.

Configurazione minima sensata di mongod.conf

La configurazione di default va bene per un test locale, ma appena esci dal laboratorio conviene impostare almeno rete, log e storage in modo esplicito. Il file principale è /etc/mongod.conf.

Un assetto minimo può essere questo:

storage:
  dbPath: /var/lib/mongodb
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
net:
  port: 27017
  bindIp: 127.0.0.1

Con bindIp: 127.0.0.1 esponi il servizio solo in locale. È la scelta giusta se MongoDB è dietro un’applicazione sulla stessa macchina. Se devi esporlo in rete, non limitarti a cambiare il bind: devi progettare anche firewall, autenticazione, TLS e restrizioni lato applicazione.

Dopo ogni modifica al file, controlla la sintassi del servizio riavviando in modo controllato:

sudo systemctl restart mongod
sudo systemctl status mongod --no-pager
sudo tail -n 50 /var/log/mongodb/mongod.log

Se il servizio non riparte, il log applicativo è il primo posto da leggere. In pratica: prima osservi, poi tocchi. È una regola che evita di trasformare un errore banale in un downtime più lungo del necessario.

Abilitare l’accesso remoto in modo prudente

Molti installano MongoDB e poi lo espongono sulla rete cambiando solo il bind. È una cattiva abitudine. Se il database deve essere raggiungibile da altre macchine, devi trattarlo come un servizio sensibile: apri solo l’indirizzo necessario, usa firewall restrittivo e abilita l’autenticazione prima di metterlo in produzione.

Per esempio, se vuoi ascoltare su un IP specifico della LAN, modifica /etc/mongod.conf così:

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.1.10

Prima di riavviare, verifica che quell’IP esista davvero sulla macchina:

ip addr show

Se il bind è sbagliato, MongoDB può non avviarsi o può avviarsi ma non essere raggiungibile come ti aspetti. Dopo il riavvio, controlla il listener e testa da un client autorizzato:

ss -lntp | grep 27017
mongosh --host 192.168.1.10 --eval 'db.runCommand({ ping: 1 })'

Se il ping funziona solo in locale e fallisce da remoto, il problema di solito è nel firewall host o in un filtro di rete a monte, non in MongoDB. In quel caso chiudi il gap con una verifica di rete minimale: porta aperta, routing corretto, ACL coerenti.

Hardening minimo: utenti, autenticazione e firewall

Una installazione senza autenticazione è accettabile solo per un test temporaneo isolato. Appena il servizio esce dal singolo host, crea un amministratore e abilita il controllo accessi. L’ordine conta: prima crei l’utente, poi attivi l’autenticazione, altrimenti rischi di bloccarti fuori.

1. Accedi localmente alla shell.
2. Crea un utente amministrativo.
3. Abilita l’autenticazione in mongod.conf.
4. Riavvia il servizio e verifica il login.

mongosh

use admin
 db.createUser({
   user: "admin",
   pwd: passwordPrompt(),
   roles: [ { role: "root", db: "admin" } ]
 })

Il prompt della password evita di lasciare segreti in chiaro nella history della shell. Dopo aver creato l’utente, abilita la sezione di sicurezza nel file di configurazione:

security:
  authorization: enabled

Riavvia e testa con credenziali esplicite:

mongosh -u admin -p --authenticationDatabase admin --eval 'db.runCommand({ ping: 1 })'

Atteso: { ok: 1 }. Se fallisce, il rischio più probabile è aver creato l’utente nel database sbagliato o aver scritto male il blocco security nel file YAML.

Per il firewall, su Ubuntu puoi usare UFW se è già parte della tua baseline. L’obiettivo non è “aprire la porta”, ma aprirla solo ai client autorizzati:

sudo ufw allow from 192.168.1.0/24 to any port 27017 proto tcp
sudo ufw status verbose

Se MongoDB è esposto a Internet senza un controllo serio, il problema non è l’installazione ma la postura di sicurezza. In quel caso il fix corretto non è allargare il firewall: è restringere l’esposizione e mettere il servizio dietro un canale autenticato e cifrato.

Verifiche post-installazione che evitano sorprese

Una installazione riuscita non è solo un demone in esecuzione. Devi verificare che il pacchetto sia quello atteso, che il servizio parta al boot e che il database scriva davvero sul filesystem giusto.

dpkg -l | grep mongodb-org
systemctl is-enabled mongod
systemctl is-active mongod
df -h /var/lib/mongodb

Controlla anche i log di avvio per eventuali warning persistenti. Alcuni warning non bloccano l’operatività immediata, ma diventano problemi quando aumentano carico o volume dati.

journalctl -u mongod --since "10 min ago" --no-pager

Se il nodo è destinato a carichi reali, monitora almeno queste metriche: uso CPU, RAM, spazio disco, latenza di I/O e numero di connessioni. MongoDB soffre rapidamente su storage lento o quasi pieno, quindi lo spazio libero non è un dettaglio amministrativo ma una variabile di stabilità.

Un controllo pratico che vale più di molte supposizioni è la scrittura di prova e la lettura immediata:

mongosh --eval 'db.testcol.insertOne({ts: new Date(), ok: true}); db.testcol.find().sort({ts:-1}).limit(1)'

Se la scrittura fallisce, il problema non è “MongoDB non parte”, ma un sottoinsieme più specifico: permessi, filesystem, autenticazione o spazio esaurito.

Errore tipici e lettura rapida dei segnali

In pratica, i guasti più comuni durante o subito dopo l’installazione sono pochi e riconoscibili. Se il servizio non parte, il journal ti dice quasi sempre se sei davanti a un problema di configurazione YAML, di permessi o di porta occupata. Se la shell non si connette, il punto di partenza è la reachability locale, non il database remoto.

• Repository errato: apt update fallisce o non propone mongodb-org 6.0.
• Servizio failed: controlla journalctl -u mongod e il log in /var/log/mongodb/mongod.log.
• Connessione negata: verifica bindIp, firewall e listener con ss -lntp.
• Login fallito: controlla database dell’utente e parametro --authenticationDatabase.
• Spazio finito: controlla df -h e il path reale di dbPath.

Questa lettura rapida evita il classico errore di inseguire il sintomo sbagliato. Un database che rifiuta connessioni non è necessariamente “rotto”: può essere semplicemente chiuso al bind corretto o bloccato dal firewall. Un servizio che si ferma all’avvio non va “riinstallato” a prescindere: va letto il motivo del fallimento.

Disinstallazione pulita e rollback

Se devi tornare indietro, fallo in modo controllato. Prima ferma il servizio, poi rimuovi i pacchetti. Se hai dati da conservare, backup della directory dati prima di toccare nulla.

Rollback minimo:

sudo systemctl stop mongod
sudo apt remove -y mongodb-org
sudo rm -f /etc/apt/sources.list.d/mongodb-org-6.0.list
sudo rm -f /usr/share/keyrings/mongodb-server-6.0.gpg
sudo apt update

Se vuoi conservare i dati, non cancellare /var/lib/mongodb finché non hai deciso esplicitamente cosa fare del contenuto. Quella directory contiene il database, non un cache temporaneo.

Assunzione finale: i comandi sono eseguiti su Ubuntu 22.04 LTS aggiornato, con repository ufficiale MongoDB raggiungibile e con privilegi sudo disponibili.