Exécution de MongoDB avec l'authentification

Question

Je suis en train de comprendre MongoDB afin d'évaluer si elle est une route que je voudrais prendre pour des applications futures ou non. Afin de déployer judicieusement sur mon serveur, je dois l'exécuter avec l'authentification activée (avec l'argument --auth ou auth = true dans le fichier de configuration).

L'installation semble relativement straightfoward et j'ai procédé avec une aide de la documentation si nécessaire. En particulier, les sur la sécurité fait un très bon travail d'expliquer le processus d'exécution avec auth activé et insérer votre premier utilisateur admin. Cependant, les choses ne sont pas procédé selon le plan.

Running sans auth donne le résultat que l'on pourrait espérer - il fonctionne, avec la sortie suivante:

Thu Dec 10 21:14:24 Mongo DB : starting : pid = 9350 port = 27017 dbpath = /var/mongodb_data master = 0 slave = 0  64-bit 
Thu Dec 10 21:14:24 db version v1.3.0-, pdfile version 4.5
Thu Dec 10 21:14:24 git version: 32d56f6d81a98b569103149c9ffea9f25a1ece81
Thu Dec 10 21:14:24 sys info: Darwin erh2.10gen.cc 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 BOOST_LIB_VERSION=1_37
Thu Dec 10 21:14:24 waiting for connections on port 27017

Cependant, en cours d'exécution avec l'authentification (en utilisant des méthodes, arg ou directive de configuration) donne la sortie suivante et le processus se termine immédiatement:

Thu Dec 10 21:15:37 Mongo DB : starting : pid = 9361 port = 27017 dbpath = /var/mongodb_data master = 0 slave = 0  64-bit 
Thu Dec 10 21:15:37 User Exception unauthorized
Thu Dec 10 21:15:37  local.system.namespaces  Caught Assertion in runQuery ns:local.system.namespaces userassert:unauthorized
Thu Dec 10 21:15:37   ntoskip:0 ntoreturn:0
Thu Dec 10 21:15:37   query:{ name: /^local.temp./ }
Thu Dec 10 21:15:37 query local.system.namespaces ntoreturn:0 exception  0ms
Thu Dec 10 21:15:37 Dropping old temporary collection: 
Thu Dec 10 21:15:37 User Exception no collection name
Thu Dec 10 21:15:37   exception in initAndListen std::exception: no collection name, terminating
Thu Dec 10 21:15:37  dbexit: 
Thu Dec 10 21:15:37   shutdown: going to flush oplog...
Thu Dec 10 21:15:37   shutdown: going to close sockets...
Thu Dec 10 21:15:37   shutdown: waiting for fs...
Thu Dec 10 21:15:37   shutdown: closing all files...
Thu Dec 10 21:15:37      closeAllFiles() finished
Thu Dec 10 21:15:37   shutdown: removing fs lock...
Thu Dec 10 21:15:37  dbexit: really exiting now
ERROR: Client::shutdown not called!

Comme il est indiqué dans les balises, cela est en cours d'exécution sur OS X Snow Leopard et il utilise le dernier système d'exploitation nocturne 1.3.x X 64bit téléchargement binaire (dois-je revenir à 1.2 stable peut-être?)

Toute idée de ce qui cause cela et ce que je peux faire pour le résoudre? Il est pas si important sur ma machine locale mais je besoin de travailler en mode sécurisé pour le rendre pratique pour toute utilisation de la production du tout.

---

PS: si cela devrait être sur ServerFault plutôt que SO, ne hésitez pas à avoir déplacé là. Je ne savais pas quel environnement le mieux adapté.

---

Mise à jour:

Je l'ai essayé de courir sans auth, l'ajout d'un utilisateur et réexécution avec auth comme recommandé par mdirolf et Mathias. Cependant, le jetant toujours la même erreur. L'utilisateur a été ajouté de la manière suivante:

Mark@Destiny mongodb$ sudo bin/mongo
MongoDB shell version: 1.3.0-
url: test
connecting to: test
type "help" for help
> use admin
switched to db admin
> db.addUser("Mark", "my-password-went-here")   
{ "user" : "Mark", "pwd" : "9934...be15da0" }
> db.system.users.find()
{ "_id" : ObjectId("4b216ed0be8a0b185767654e"), "user" : "Mark", "pwd" : "9934a190b...babe15da0" }
> exit
bye

Après la course sans auth et en entrant le shell mongo prouver que l'utilisateur est en fait encore. Est-ce que je fais quelque chose de stupide?

Answer 1

Ahh, ressemble vous avez trouvé un bug dans le maître. J'ai créé un cas pour elle: http://jira.mongodb.org/browse/SERVER -474 .

S'il vous plaît essayer la mongodb a récemment publié 1.2.0. maître Git (branche 1.3.x) est pas prêt à l'emploi encore.

Answer 2

Vous devez avoir déjà un utilisateur dans l'admin DB avant de démarrer le serveur avec --auth. Je viens d'ajouter une note à la documentation de mentionner si personne d'autre est surpris.

Par ailleurs, la plupart (sinon tous) les déploiements de MongoDB de production fonctionnent sans auth. Nous recommandons de manipuler l'authentification dans votre application et la configuration du pare-feu sur votre serveur de base de données pour autoriser uniquement les connexions de vos serveurs Web / app.

Answer 3

Vous devez ajouter un utilisateur avant de commencer --auth. Commencez sans --auth et ajouter un utilisateur, puis redémarrez avec --auth.

La section de sécurité a été mis à jour pour décrire cela.