Timeline for MongoDB - Adding a new server to an existing replica set with auth enabled
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2014 at 9:08 | history | edited | Adam C | CC BY-SA 3.0 |
added 779 characters in body
|
| May 23, 2014 at 9:45 | vote | accept | mclayton | ||
| May 23, 2014 at 9:44 | comment | added | mclayton | Interesting. I don't think I've got anything unusual in my environment, but maybe there's something hiding somewhere. I've managed to get the new servers into the replica set now anyway, so I'll leave them alone now and step away slowly :-). Thanks for your help. | |
| May 22, 2014 at 18:26 | comment | added | Adam C | I just tested this (as part of recording an online training course) and the otherDBRoles was not needed for me to be able to add nodes to a set with authentication enabled, only clusterAdmin, so I am not sure what is different on your set or your procedure. From scratch, and in general, that is not a requirement. | |
| May 22, 2014 at 14:03 | comment | added | mclayton | My "mongo-cluster-admin" account now looks like this: { "_id" : ObjectId("XXXXXXXX"), "pwd" : "XXXXXXXX", "user" : "mongo-cluster-admin", "roles" : [ "clusterAdmin" ], "otherDBRoles" : { "local" : [ "read" ] } }. Note the "otherDBRoles" part - that's the critical part that was missing originally. | |
| May 22, 2014 at 13:59 | comment | added | mclayton | There's a little bit more to it than that... The massive gotcha is that you need the "read" role in the "local" database as well as the "clusterAdmin" role in the "admin" database. The "Combined Access" section of my previous link gives a tiny fragment of a clue about this where it says that "rs.conf()" requires read access on the local database. It doesn't say, but "rs.initiate()", "rs.add()" and "rs.addArb()" also need that role otherwise you hit the "unauthorized" error when auth is enabled. (For completeness, this is all on version 2.4.9. Things may be different for newer versions). | |
| May 21, 2014 at 9:26 | comment | added | Adam C | Ah, I see, you needed to have the permissions from the built-in role clusterManager to make the changes, and turning off auth as you described would remove the problem by allowing you to make any changes you require (no role restriction in place, because no roles). I added the clusterManager note to the answer to prevent confusion for others (that don't get this far in the comments). | |
| May 21, 2014 at 9:24 | history | edited | Adam C | CC BY-SA 3.0 |
added 351 characters in body
|
| May 20, 2014 at 17:22 | comment | added | mclayton | I think the problem was that the "mongo-cluster-admin" account I'd created didn't have the required permissions to make changes to the replica set config, as opposed to it being a problem with the replication mechanism itself. After I gave it "local: read" privilege, the account was able to modify the replica set config and it all worked perfectly. | |
| May 20, 2014 at 13:58 | comment | added | Adam C | The set members do not use that account to replicate though, so I don't see why that would make a difference (they use the internal __system user/role). The procedure I described is one I have used successfully several times, and the usual reason for an unauthorized failure is that the keyfiles are not in fact identical across the set (hence the inter-set auth fails). | |
| May 20, 2014 at 13:34 | comment | added | mclayton | Hi Adam. I tried that initially, but I got the same "unauthorized" problem. I've just had a breakthrough though by giving my "mongo-cluster-admin" account "read" access to the "local" database as per docs.mongodb.org/v2.4/reference/user-privileges/…. (That might be specific to the version I'm using - i.e. 2.4.9). I'll add an answer with details once I've finished testing it. | |
| May 19, 2014 at 21:01 | history | answered | Adam C | CC BY-SA 3.0 |