1 30/10/2026 9 min

Repository ufficiale MongoDB su Debian 12

Su Debian 12 conviene partire dal repository ufficiale di MongoDB, non dai pacchetti del repository base di Debian. Il motivo è semplice: i rilasci di MongoDB seguono un ciclo diverso da quello della distribuzione e, se vuoi una versione supportata e aggiornata, il canale ufficiale è la strada più lineare.

Prima di toccare il sistema, chiarisco l’obiettivo operativo: installare MongoDB Server, avviarlo come servizio systemd, verificarne lo stato e lasciare una base minima di sicurezza. Non faccio assunzioni strane sullo stack: Debian 12, sistema recente, accesso root o sudo, rete in uscita verso i mirror ufficiali.

Se il server è in produzione, considera l’impatto come reale fino a prova contraria: ogni modifica a repository, pacchetti e configurazione può cambiare il comportamento del servizio. Tieni sempre un punto di rollback, anche solo un backup dei file che tocchi.

Preparazione del sistema

Parti aggiornando l’indice pacchetti e installando i prerequisiti per la gestione delle chiavi del repository. Su Debian 12 è preferibile usare il formato moderno delle keyring, evitando approcci vecchi e più fragili.

sudo apt update
sudo apt install -y ca-certificates curl gnupg

Il risultato atteso è che i pacchetti vengano installati senza errori e che il sistema disponga di curl e gpg per importare la chiave del repository. Se uno di questi pacchetti manca, fermati lì: prima correggi la connettività o l’indice APT, poi prosegui.

Aggiunta della chiave e del repository MongoDB

Per Debian 12, MongoDB pubblica repository dedicati alla versione del prodotto. La procedura tipica consiste nel salvare la chiave in una keyring locale e nel dichiarare la sorgente APT con signed-by, così la fiducia resta limitata a quel repository specifico.

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

Il file di repository può essere creato in /etc/apt/sources.list.d/mongodb-org-7.0.list. Se usi una versione diversa, sostituisci il numero di release in modo coerente con il pacchetto che intendi installare.

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

Dopo aver aggiunto il repository, aggiorna l’indice pacchetti e verifica che APT lo veda correttamente.

sudo apt update

Se apt update segnala errori di firma o di connessione, non forzare l’installazione: controlla prima la keyring in /usr/share/keyrings/mongodb-server-7.0.gpg, l’URL del repository e l’orologio di sistema, perché una data errata può far fallire la validazione delle firme.

Installazione del pacchetto MongoDB Server

A questo punto puoi installare il metapacchetto ufficiale. La scelta più comune è mongodb-org, che porta con sé server, shell e componenti essenziali del pacchetto distribuito da MongoDB.

sudo apt install -y mongodb-org

Il risultato atteso è la presenza dei binari e dell’unità systemd. Se l’installazione fallisce per conflitti con pacchetti già presenti, verifica se sul server sono installate versioni vecchie provenienti da repository Debian o da installazioni manuali. In quel caso il problema non è MongoDB in sé, ma la sovrapposizione di sorgenti software diverse.

Per controllare cosa è stato installato, puoi usare:

dpkg -l | grep -E '^ii\s+mongodb|^ii\s+mongosh'

Se vuoi sapere quali file appartengono al pacchetto, il controllo utile è questo:

dpkg -L mongodb-org | head

Avvio del servizio e abilitazione all’avvio automatico

Su Debian 12 MongoDB si gestisce comodamente con systemd. Dopo l’installazione, avvia il servizio e abilitalo all’avvio automatico solo quando sei sicuro che la configurazione sia coerente con il contesto del server.

sudo systemctl start mongod
sudo systemctl enable mongod

La verifica minima è il controllo dello stato del servizio.

systemctl status mongod --no-pager

Ti aspetti uno stato active (running). Se vedi failed, la prima fonte da consultare è il journal del servizio:

journalctl -u mongod -b --no-pager

Qui di solito emergono subito i casi più frequenti: permessi errati sulla directory dati, porta già occupata, problemi di filesystem, configurazione YAML non valida o mancata inizializzazione della directory di storage.

Verifica locale con la shell MongoDB

Una volta che il demone è in esecuzione, conviene fare una prova locale. Su installazioni recenti la shell è mongosh, che ti permette di testare autenticazione, ping e stato di base del server.

mongosh

Dentro la shell, un controllo semplice e utile è:

db.runCommand({ ping: 1 })

L’output atteso è un documento con ok: 1. Se il ping fallisce ma il servizio risulta avviato, il problema può essere nella porta di ascolto, nella configurazione di bind o in un errore di rete locale se stai testando da un host remoto.

Configurazione essenziale di mongod.conf

Il file principale è /etc/mongod.conf. Prima di modificarlo, fai una copia del file originale così puoi tornare indietro senza incertezze.

sudo cp /etc/mongod.conf /etc/mongod.conf.bak

Le impostazioni più importanti in una installazione base sono il bind address, il percorso dati e la destinazione dei log. In un server esposto solo localmente, puoi lasciare il bind su localhost; se invece deve ascoltare su rete, devi essere più prudente e limitare l’esposizione con firewall e autenticazione.

net: port: 27017 bindIp: 127.0.0.1

Se modifichi bindIp per accettare connessioni da altre macchine, il blast radius cresce subito: il servizio diventa raggiungibile in rete e, senza autenticazione e firewall, allarghi la superficie d’attacco. Il rollback è semplice: ripristina il file da /etc/mongod.conf.bak e riavvia il servizio.

Dopo ogni modifica, controlla la sintassi indirettamente con un riavvio controllato e con i log. MongoDB non ha un “test config” universale come altri servizi; la verifica pratica è il comportamento del demone dopo il restart.

sudo systemctl restart mongod
sudo systemctl status mongod --no-pager

Abilitare l’autenticazione prima di esporre il servizio

Se il database non deve restare confinato a localhost, l’autenticazione non è un optional. La sequenza corretta è: prima crei l’utente amministrativo, poi abiliti l’autenticazione, non il contrario. Invertire l’ordine può lasciarti temporaneamente fuori dal server o, peggio, esporre il database senza protezione.

Una volta entrato con mongosh, puoi creare un utente amministratore nel database admin. Adatta nome utente e ruoli al tuo caso reale; evita di usare account generici e soprattutto evita password riutilizzate.

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

Dopo aver creato l’utente, abilita l’autenticazione nel file /etc/mongod.conf:

security: authorization: enabled

Riavvia il servizio e verifica che l’accesso anonimo non funzioni più. Il test corretto è provare una connessione senza credenziali e attendersi un errore di autorizzazione. Poi prova con l’utente creato e conferma che il login riesca.

mongosh -u admin -p --authenticationDatabase admin

Il rollback, se qualcosa va storto, è il ripristino del file di configurazione precedente e il riavvio del servizio. Tieni presente che togliere l’autenticazione per “farlo ripartire” è un’azione ad alto rischio se il server è raggiungibile da altre reti.

Firewall e esposizione in rete

MongoDB ascolta di default sulla porta 27017. Se il server deve essere raggiungibile da altri host, la regola non è “aprire la porta e basta”, ma limitare l’accesso alle sole sorgenti necessarie. Su Debian 12 il firewall può essere gestito con nftables o con un frontend come ufw, a seconda degli standard del server.

Se usi ufw, una regola prudente è consentire solo da una subnet specifica:

sudo ufw allow from 192.0.2.0/24 to any port 27017 proto tcp

Il controllo finale è verificare che la porta sia esposta solo dove ti aspetti. Dal server puoi usare ss per vedere il listener:

ss -lntp | grep 27017

Se il listener è su 127.0.0.1:27017, MongoDB accetta solo connessioni locali. Se invece compare un indirizzo pubblico o 0.0.0.0, il servizio è esposto su tutte le interfacce e va protetto con firewall e autenticazione senza ritardi.

Log, directory dati e problemi tipici all’avvio

Quando MongoDB non parte, i casi ricorrenti sono abbastanza stabili nel tempo. Il primo è il permesso sbagliato sulla directory dati, spesso /var/lib/mongodb. Il secondo è un errore di configurazione nel file YAML. Il terzo è il disco pieno o quasi pieno, che impedisce la creazione o la scrittura dei file di storage.

Per controllare rapidamente la capacità del filesystem:

df -h

Per verificare i permessi della directory dati:

ls -ld /var/lib/mongodb /var/log/mongodb

Il proprietario atteso, nella configurazione standard, è l’utente del servizio MongoDB. Se i permessi sono stati alterati manualmente, il demone può partire in modo intermittente o fallire subito. In questi casi il fix minimo è ripristinare ownership e permessi coerenti con i valori del pacchetto, senza introdurre correzioni creative che complicano il rollback.

Avvio automatico, aggiornamenti e manutenzione minima

Dopo l’installazione, vale la pena controllare che il servizio sia abilitato all’avvio e che gli aggiornamenti futuri non rompano la configurazione. Il punto non è automatizzare a occhi chiusi, ma sapere esattamente cosa cambia quando aggiorni il pacchetto.

systemctl is-enabled mongod
apt-cache policy mongodb-org

Il primo comando ti dice se il servizio parte al boot; il secondo mostra la versione candidata e le sorgenti pacchetto. Se vuoi pianificare manutenzione o upgrade, annota la versione installata e conserva il file di configurazione in un sistema di versioning o almeno con una copia datata.

Per un cambio controllato, la sequenza prudente è sempre la stessa: backup del file di configurazione, verifica dello stato attuale, modifica minima, riavvio controllato, controllo dei log, test applicativo. Se qualcosa non torna, torni indietro al file precedente e riavvii. Il rollback non deve essere un’idea astratta, ma un’azione che puoi eseguire in pochi secondi.

Verifica finale dell’installazione

Una installazione fatta bene non si giudica solo dal fatto che il pacchetto sia presente. La verifica finale deve confermare tre cose: il servizio è attivo, la shell si connette, la porta risponde solo dove previsto. Se una di queste tre manca, l’installazione è incompleta dal punto di vista operativo.

systemctl status mongod --no-pager
mongosh --eval 'db.runCommand({ ping: 1 })'
ss -lntp | grep 27017

Se tutti e tre i controlli sono coerenti, puoi considerare il server pronto per l’uso base. Da qui in poi le scelte importanti diventano architetturali: replica set, backup, autenticazione avanzata, tuning del filesystem, policy di retention e monitoraggio. Ma quello è un passaggio successivo, non parte dell’installazione minima.

Assunzione operativa: Debian 12, repository ufficiale MongoDB 7.0, installazione su host Linux recente con accesso sudo e servizio gestito da systemd.