Dopo aver trattato i concetti base, la filosofia e un’installazione di MongoDB, vediamo nel dettaglio qualche operazione un po’ più avanzata.
Coerentemente alla propria logica di database NoSQL snello, MongoDB non prevede grandi configurazioni manuali lato server, prendendo da sé, ove possibile, le migliori decisioni. Detto ciò, amministrarlo efficacemente richiede ugualmente qualche intervento.
Il file di configurazione principale di MongoDB su RHEL e CentOS è /etc/mongodb.conf e include le direttive per il funzionamento del server. Ecco un’intestazione d’esempio, di immediata comprensione:
bind_ip = 127.0.0.1 port = 27017 fork = true # Se true inizializza come demone pidfilepath = /var/run/mongodb/mongodb.pid logpath = /var/log/mongodb/mongodb.log dbpath =/var/lib/mongodb
L’avvio e lo stop del demone dovrebbero essere eseguiti, come al solito, via /etc/init.d/mongod o, a partire da RHEL 7, con systemctl start|stop mongod. Per quanto riguarda l’amministrazione, vediamo alcune operazioni di base. Si ottengono facilmente i parametri del server running eseguendo, da dentro la shell JS, il comando serverStatus entrando in modalità command (db.runCommand):
bash-4.1# mongo
MongoDB shell version: 2.4.6
connecting to: test
> db.runCommand({"serverStatus" : 1})
{
"host" : "4036ac0285fd",
"version" : "2.4.6",
"process" : "mongod",
"pid" : 528,
"uptime" : 484,
"uptimeMillis" : NumberLong(483510),
"uptimeEstimate" : 384,
"localTime" : ISODate("2014-04-20T07:20:36.293Z"),
...
Le entry sono autoesplicative e stampate in formato JSON, complete e facili da leggere.
Passiamo ad un altro argomento, la messa in sicurezza di MongoDB. Rimangono valide le solite raccomandazioni, cioè mettere il server in binding solo per il segmento di rete da servire (con la direttiva bindip), filtrare adeguatamente con iptables il traffico verso il server (tcp/27017 è la porta di default di MongoDB), impedire l’avvio di servizi collaterali come un’interfaccia web associata (nohttpinterface = true).
Ma il primo passo per la messa in sicurezza, dopo questi tuning di sistema, è il setup delle autorizzazioni. Per prima cosa, va detto che anche con le autorizzazioni attive, MongoDB non ha capacità native di criptare il traffico da e verso se stesso: è perciò necessario, se dovesse sorgere questa necessità di sicurezza supplementare, impostare le connessioni attraverso tunnel SSH o cose del genere.
Detto ciò, le autorizzazioni si attivano (di default sono spente) con il parametro auth = true nel file di configurazione. Ma prima di attivare auth, va creato almeno un utente amministratore (il root di MongoDB). Le autorizzazioni sono gestite a livello database: un’istanza di Mongo include sempre, oltre al database di test come abbiamo visto, anche un database speciale, denominato admin. In questo database c’è la lista degli utenti autorizzati come amministratori, gli unici che hanno tutti i privilegi di lettura e scrittura sui database. Quindi entriamo in MongoDB eseguito in modalità default (admin = false), passiamo al database admin e aggiungiamo un’utente amministratore con il comando db.addUser:
bash-4.1# mongo
MongoDB shell version: 2.4.6
connecting to: test
> use admin
switched to db admin
> db.addUser("root", "extraordy");
{
"user" : "root",
"readOnly" : false,
"pwd" : "0dafd37fd3a87ab89e5ee45b2dce0205",
"_id" : ObjectId("5353794f752f8dbb91e5d953")
}
Ora decommentiamo la riga auth = true da /etc/mongodb.conf, e riavviamo il servizio. Collegandoci possiamo verificare il corretto funzionamento della autorizzazioni, tentando di eseguire un comando che richiede privilegi amministrativi (listDatabases), senza l’autenticazione e dopo aver eseguito l’autenticazione:
bash-4.1# mongo
MongoDB shell version: 2.4.6
connecting to: test
> use admin
switched to db admin
> db.runCommand({"listDatabases" : 1})
{ "ok" : 0, "errmsg" : "unauthorized" }
> db.auth("root", "extraordy")
1
> db.runCommand({"listDatabases" : 1})
{
"databases" : [
{
"name" : "local",
"sizeOnDisk" : 33554432,
"empty" : false
},
{
"name" : "admin",
"sizeOnDisk" : 67108864,
"empty" : false
},
{
"name" : "test",
"sizeOnDisk" : 1,
"empty" : true
}
],
"totalSize" : 100663296,
"ok" : 1
}
Concludiamo con un’ultima nota: la shell di Mongo ha funzionalità di history, con la possibilità di richiamare gli ultimi comandi. Per ovvie ragioni di sicurezza, i comandi di tipo db.auth non sono salvati.
Proseguiremo l’esplorazione delle caratteristiche di MongoDB con un articolo successivo sul backup e il ripristino di database corrotti. Alla prossima!
