Mongodb – what is correct way of adding a user in admin with role userAdminAnyDatabase doing upgrade to 2.6

mongodb

I am running a mongodb 2.4 with auth enabled and want to upgrade to 2.6

Instructions in upgrade 2.6 says:

Before beginning the upgrade process for a deployment that uses authentication and authorization:

Ensure that at least one user exists in the admin database with the role userAdminAnyDatabase.

then upgrade binaries

then run athorization schema format if needed

So I have to add user with the role userAdminAnyDatabase in 2.4 before copies binaries of 2.6 ?

in current 2.4 shell added user with role userAdminAnyDatabase and then schema upgrade with userAdminAnyDatabase role after coping binaries of 2.6

db.addUser( { user: "a", pwd: "pass", roles: [ "userAdminAnyDatabase" ] } )

Is this the right way? Do i need to add read write access as well?

I think i might not get the error below if I go into admin database with role userAdminAnyDatabase

> show collections
2016-02-22T18:51:10.765-0500 error: {
  "$err" : "not authorized for query on oasis.system.namespaces",
  "code" : 13
} at src/mongo/shell/query.js:131

Best Answer

IMPORTANT The userAdminAnyDatabase user can grant itself and any other user full access to the entire MongoDB instance. The credentials to log in as this user should be carefully controlled.

Users with the userAdmin and userAdminAnyDatabase privileges are not the same as the UNIX root superuser in that this role confers no additional access beyond user administration. These users cannot perform administrative operations or read or write data without first conferring themselves with additional permissions.

4 Steps for upgrading MongoDB v2.4 to v2.6

Ensure that at least one user exists in the admin database with the role userAdminAnyDatabase.
Upgrade client libraries,compatible with v2.6
Upgrade all MongoDB process to 2.6
Connect and authenticate to the mongod instance for a single deployment or a mongos for a sharded cluster as an admin database user with the role userAdminAnyDatabase.Use the authSchemaUpgrade command in the admin database to update the user data using the mongo shell.

Create a User Administrator https://docs.mongodb.org/v2.4/tutorial/add-user-administrator/

Related Solutions

MongoDB instance for production

First Question: In order for this communication to be secure, would it be a better idea to use HTTPS port 443 instead of that basic TCP port 27077 , then disable the HTTP interface in the mongo.conf file? Is that enough to make the communication secured?

--yes enough.As port and ip security is there apart from that you can use iptables for more security. As currently you are just preventing mongo attack only.

What would be the best way to always make sure the mongo server is always responsive or running? (for example if the server was rebooted, I need to make sure that the mongo is still running) or (to avoid mongodb.lock file) because I had that issue before.

-- if you are running it as service then lock file issue will not be there.in case you are using directly from bin then put it in rc.d simple. advised you to create a script to check your server status and configure alerts accordingly.

BACKUP: As you are not using replica then simply mongodump will be advisable but you can also start your single machine as replica means without any secondary you will have oplog for incremental backup. You can start instance with replset option or change in config file. then below command.

>rs.initiate()

it will give you something like :

{
    "info2" : "no configuration specified. Using a default configuration for the set",
    "me" : "machine:27017",
    "ok" : 1
}

check one oplog.rs will be there in local database.

MongoDB Sharded Cluster Upgrade from 2.4 to 3.2 version

Yes. Period. No "Ok, but..."
You should make a backup. Start now, continue reading later. It is presumably going to take a while.
Config servers in 2.4, 2.6 and 3.0 do *not* form a replica set. Those were basically 3 standalone instances.
Read and understand the migration guide to 2.6 for sharded clusters. Rinse, repeat.
Read and understand the migration guide to 3.0 for sharded clusters. Rinse, repeat.
Read and understand the migration guide to 3.2 for sharded clusters Rinse, repeat.
Read the guide Upgrade Config Servers to Replica Set. Rinse, repeat.
Wait until your backup is done.
Upgrade to 2.6 according to guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
Upgrade to 3.0 according to the guide mentioned above. Migrate to WiredTiger in the process, unless you have very strange requirements. That is: shutdown data secondary data bearing node, delete its datadir, adjust config to utilize WT, resync, proceed. Have primary step down Before shut down. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
Upgrade to 3.2 according to the guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
Convert your config servers to a replica set according to the guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
Take a few notes: "Good resolution 1: read release notes and docs of my chosen persistence technology. Good resolution 2: I will only ask questions to my peers after thoroughly researching the topic myself."

Best Answer

Related Solutions

MongoDB instance for production

MongoDB Sharded Cluster Upgrade from 2.4 to 3.2 version

Related Question