I have a mongodb replica-set of 3 members (version 2.4) in which the administrator user for the 'admin' db does not have the 'userAdminAnyDatabase' role.
This role is required for managing the users on all databases.
The roles I currently have are: [ "readWriteAnyDatabase", "dbAdminAnyDatabase", "clusterAdmin" ]
I tried updating roles for myself or creating a new user, however I have no permission to access db.system.users in the admin db.
I tried setting noauth=true but that did not help. When removing the keyFile as well, the db was not able to sync with the other members (obviously) and got stuck in RECOVERY state.
I found a similar question that refers to a stand alone db (no replica set) so it doesn't really help in this case.
What would be the best way to add this role while having minimal system downtime?
I would use mongodump and mongorestore to backup the data then rebuild node with right permissions and restore the data.
However this approach should work:
If you have locked yourself out then you need to do the following:
Stop your MongoDB instance
Remove the --auth and/or --keyfile options from your MongoDB config
to disable authentication
Start the instance without authentication
Edit the users as needed
Restart the instance with authentication enabled
As you are using mongo 2.4, that means you have MMAP as a storage engine.
my proposal will be:
create similar replica set on each host but different port, and set database directory on same media as current one.
configure all auth stuff same as running ones
stop old replica set members
MOVE database files to new directory excluding local
change port on new replica set
start it
As moving files to other directory is just a pointer change this will take some seconds.
Please test before implementation.
Any comments welcome!
Related
Below I list the directions I followed from the docs
Problem
After following the docs listed below I am unable to access my database. I most definitely did not forget my password as I actually saved the query that I ran to create the user I will list the query I ran below.
I get the following error when I try to connect my local host instance in MongoDB compass
connect ECONNREFUSED 127.0.0.1:27017
I think the issue might lie in the fact that I was running these command in the mongodb compass mongosh terminal and not the mongod
use admin
db.createUser(
{
user: "max",
pwd: "max",
roles: [
{ role: "userAdminAnyDatabase", db: "admin" },
{ role: "readWriteAnyDatabase", db: "admin" }
]
}
)
What I need Help with:
I need help accessing my local database and if possible setting up authentication on the schema
Below this line is the docs I followed
Start MongoDB without access control
Start a standalone
mongod
instance without access control.
Open a terminal and run the following command as the mongod user:
mongod --port 27017 --dbpath /var/lib/mongodb
The
mongod instance in this tutorial uses
port 27017
and the /var/lib/mongodb data directory.
The tutorial assumes that the /var/lib/mongodb directory exists and is the default
dbPath
. You may specify a different data directory or port as needed.
TIP
When
mongod
starts, it creates some system files in the /var/lib/mongodb directory. To ensure the system files have the correct ownership, follow this tutorial as the mongod user. If you start
mongod
as the root user you will have to update file ownership later.
Connect to the instance
Open a new terminal and connect to the database deployment with
mongosh
mongosh --port 27017
If you are connecting to a different deployment, specify additional command line options, such as
--host
, as needed to connect.
Create the user administrator
IMPORTANT
Localhost Exception
You can create the user administrator either before or after enabling access control. If you enable access control before creating any user, MongoDB provides a localhost exception which allows you to create a user administrator in the admin database. Once created, you must authenticate as the user administrator to create additional users.
I made sure that I made a user
Using
mongosh switch to the admin database add the myUserAdmin user with the userAdminAnyDatabase
and
readWriteAnyDatabase
roles":
use admin
db.createUser(
{
user: "myUserAdmin",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "userAdminAnyDatabase", db: "admin" },
{ role: "readWriteAnyDatabase", db: "admin" }
]
}
)
With respect to the technical issue, the error message that was provided (connect ECONNREFUSED 127.0.0.1:27017) suggests that the server is actively refusing the connection. Searching with this specific text surfaces lots of results that can probably help you solve the problem. This one, for example, suggests that one common reason for this error message is that the mongod process (the database itself) is not running. This is easy to test and reproduce, such as by trying to connect to a host and port where there is no mongod process running and listening. So I'd recommend taking a look at that question, or similar ones, to help troubleshoot and resolve your issue.
Also from the technical perspective, it is really important that we understand the different between the different processes associated with using MongoDB. As was noted in the comments:
The mongod process itself is the actual executable that needs to be up and running for the database to be accessible. Apart from starting this process with the appropriate parameters you don't do anything else with this. Typically this process needs to be --forked so that it does not stop when the command line is closed (which is what #Wernfried Domscheit was getting at in the comments). More information about this process is here in the documentation.
The shell(s) that are used to connect to and interact with the running database. The legacy one was mongo and the newer one (which is in Compass) is mongosh. This is an interface for connecting to and performing various tasks against the running database. This can include things like creating users or querying data.
This then bridges nicely toward the general advice part of this answer. It is important to keep in mind that, as of the time of writing, this question has been viewed more than 100 times. That represents a significant number of people who are volunteering their time in an attempt to help you without expecting anything in return. Said another way, we are trying to help you.
But in order to do so, we need to have an appropriate level of detail and context. It is great that you attempted to provide that information in the question itself, but ultimately it is not really enough for us to assist you effectively. Moreover, it is important to keep in mind that it is not a goal of this site (as far as I understand) to provide full tutorials or completely walkthrough configuring a new environment. Such guides can be found elsewhere, including in the documentation from the vendor that you linked. Having basic knowledge of the technology that you are working with is the foundation that allows for a "good" question. Such questions are those that allow us to help you in a focused and otherwise reasonable manner.
For MongoDB specifically, if you wanted to try to get additional support then you may try posting to the developer forums here.
The final point to make here is that it is worth considering what your ultimate goal here is. Operationally managing a database is often a task (or full job) that requires a lot of specific knowledge to perform correctly. This includes things like configuring the system properly to provide the high availability, data security, and other requirements needed by your application. Taking the time to learn these things yourself is certainly something that can be done, but the actual place that you should learn about them should probably be done primarily in a different place than this site. If you don't want to spend your time doing this, which is perfectly fine, then I would suggest looking into a hosted solution. Places like DigitalOcean and MongoDB itself offer such 'fully managed' solutions. Usually such solutions help extract away most of these underlying configuration/management details to help get you up and running faster with little upfront knowledge about operating databases being required. It may be something that is worth looking into, especially if you are just starting out on your MongoDB journey and have other tasks that you want to be focusing your time on.
I just uninstalled and reinstalled both MongoDB and MongoDB compass
I have a mongodb sharded cluster, with mongos machines, mongo nodes in replicate sets and config servers. MongoDB version is 3.02
The guy that set this up left the company a while ago and now I cant do simple things like show dbs or show collections
I have OS root in all these Debian machines, so I want to know how to reset mongo's root password so I can admin the database.
The apps that access this db seem to be working fine, using a user that has low privileges. I know the password for this particular user.
This is a production setup, so I can't afford to keep it down for more than a few seconds, tops minutes.
It depends on the types of users. For example, if you are using SCRAM, the basic steps to reset password would be:
Stop the mongod nodes
Disable authorization in mongod.conf
Restart the Replica set nodes
Connect to the replica set primary node using the mongo shell
Reset the your password by db.changePassword
I think this may work:
Stop your MongoDB instance
Remove the --auth and/or --keyfile options from your MongoDB config to disable authentication
Start the instance without authentication
Edit the users as needed
Restart the instance with authentication enabled
https://dba.stackexchange.com/questions/62976/how-can-i-enter-mongo-as-a-superuser-or-reset-users
This may not be the perfect answer, because I cannot test it. The base problem is of course that, that you cannot put your system into maintenance mode, where you can change admin password... But there is config file parameter security.transitionToAuth what you can add with rolling matter to your config file(s).
A mongod or mongos running with security.transitionToAuth does not enforce user access controls. Users may connect to your deployment without any access control checks and perform read, write, and administrative operations.
There are two options here
If you plan to upgrade to 3.4 this can be done without downtime:
MongoDB 3.4 allows Enforce Keyfile Access Control in a Replica Set without Downtime
You need to start all your members with --transitionToAuth(This will allow both authenticated and non-authenticated traffic for some duration)
Login to mongo shell on primary and create a userAdmin
Logout and login again using userAdmin
Create rootAdmin
Store the password in password manager
Disable transitionToAuth (Allow only authenticated traffic to replica set)
If you need to do this with existing MongoDB without upgrade:
Stop a secondaries in the replica set in a rolling manner. Disable authentication using keyFile options
Stepdown a primary and update its configuration to disable authentication.
Update you're the application to remove username and password from application config
Restart application
Create useradmin and rootAdmin in admin DB
Save passwords in the password manager
Enable authentication in the replica set
Start your application with the old config that includes username and password
Steps
Connect to the machine hosting your MongoDB instance
Open the MongoDB configuration file found in /etc/ folder using: sudo nano mongod.conf
Comment out the following code like so:
# security:
# authorization: enabled
Stop the MongoDB service: sudo service mongod stop
Start the MongoDB service: sudo service mongod start
Connect to the database using Robo3T or equivalent. With a connection to the admin collection, create a new admin superuser:
db.createUser({ user:"admin", pwd:"password", roles:[{role:"root", db:"admin"}] });
Go back and uncomment the lines from step 3. Then repeat steps 4 and 5.
You should now be able to authenticate with the new user you created in step 6 and have full access to the database.
Troubleshooting
If for whatever reason, after trying to restart your mongo service, you cannot connect to it, you can make sure the service properly started with: systemctl --type=service --state=active. If it has started, it will be in the list as mongod.service.
Mongo logs can also be found at /var/log/mongodb/mongodb.log but this is less likely to be helpful in this situation.
Is there any ways or methods to start mongodb replication directly when mongod service start? I don't want to enter to shell and ON the replication?
Thanks!
You can create a mongod service which starts automatically when server starts.
First you need to create a configuration file(mongodb.conf) which will include configuration settings such as replicaSet name etc. Then create a service and install it using following command
mongod -f c:\mongod.conf --install
Then start the service using
net start mongodb
Read about configuration file here and
How to install mongo as service here
When you create a valid replica set in mongodb, your data will be asynchronously from the primary member to the secondary members in replica set
Having said that, you're not required to do extra efforts manually to get data replication done
When you do rs.slaveOk() on secondary, that allows you to query data from secondary members in the replica set.
It's a provision. It allows you to read from secondary provided that you're can tolerate the possible eventual consistent data. The replication does not happen when you do rs.slaveOk() on secondary
I'm not sure to understand. Your question was about service start. On my part, I install mongo on ubuntu and the service is not started with replicatet mode.
Finally, I disabled the first one and I created another service with the option --replSet myReplicat .
When you have only 2 servers, there is a problem with majority votes. On my part, I had 2 secondary after I stopped the primary and it was difficult to comeback with 1 primary and 1 secondary.
Effectively, the replication is always active. By default, all connections should go to the Primary. If you want to readonly from a secondary, you first enter the commande rs.slaveOk(). This command is active at session level. If you reconnect, you have to pass it again. It is not possible to put it at server side.
I was using MongoDB version 2.6.6 on Google Compute Engine and used the click to deploy method.
rs0:SECONDARY> db.createUser({user:"admin", pwd:"secret_password", roles:[{role:"root", db:"admin"}]})
2015-07-13T15:02:28.434+0000 Error: couldn't add user: not master at src/mongo/shell/db.js:1004
rs0:SECONDARY> use admin
switched to db admin
rs0:SECONDARY> db.createUser({user:"admin", pwd:"secret_password", roles:["root"]})
2015-07-13T15:13:28.591+0000 Error: couldn't add user: not master at src/mongo/shell/db.js:1004
I had a similar problem with mongo 3.2:
Error: couldn't add user: not master :
When trying to create a new user, with root role.
I was using only a local copy of mongo.
In my mongod.conf file I had the following uncommented:
replication:
replSetName: <node name>
Commenting that out and restarting fixed the problem. I guess mongo thought it was part of a replication set, and was confused as to who the Master was.
Edit:
I've also found that if you ARE trying to setup a replication set, and you get the above error, then run:
rs.initiate()
This will start a replication set, and set the current node as PRIMARY.
Exit, and then log back in and you should see:
PRIMARY>
Now create users as needed.
I ran into this error when scripting replica set creation.
The solution was to add a delay between rs.initiate() and db.createUser().
Replica set creation is seemingly done in background and it takes time for the primary node to actually become primary. In interactive use this doesn't cause a problem because there is a delay while typing the next command, but when scripting the interactions the delay may need to be forced.
MongoDB will be deployed in a cluster of Compute Engine instances (also known as a MongoDB replica set). Each instance will use a boot disk and separate disk for database files.
Primary and master nodes are the nodes that can accept writes. MongoDB’s replication is “single-master:” only one node can accept write operations at a time.
Secondary and slave nodes are read-only nodes that replicate from the primary.
Your error message looks like you are trying to add the user on the secondary. Try adding the user in the primary.
I ran into this issue when I thought I was running mongo 3.4 but it was mongo 3.6. Uninstalling 3.6 and installing 3.4 fixed my issue.
We have 9 mongo nodes in our environment with:
1 mongos
3 config servers (mongod --configSvr)
9 mongod servers (shards or members of sharded replica-sets)
and we are trying to implement authentication on them.
I have done this in the past with a single server and it was really easy:
just add the admin user to the admin database
add a user on each database
I had to restart mongod with --auth option, but here it doesn't seem to work.
I've added the admin account to our mongos and for our sharded databases; I tried to authenticate as the user I had just created, but it didn't work.
I've tried creating an admin user on each database, and the other user accounts that we need, but it still didn't work.
I also tried making sure all of our mongo servers were running with the --keyFile option specified either on the command-line or in their /etc/mongodb.conf files, but that didn't seem to help.
When I try to authenticate as a given user, like so:
db.auth("user","passwd")
it fails and returns 0, as in false; not non-zero.
I seriously need all the help I can get, so please at least leave some suggestions on things I could try--I can't overstress this, any help is more than welcome since I don't seem to be getting anywhere just from following the official docs on managing/administrating mongo sharded clusters.
In a sharded cluster you should use --keyFile to allow all the members of the cluster to authenticate to each other. When you use this option, --auth is "assumed". Since there've been several version changes since you asked this question, the roles assigned to users are more granular now - you would need to have a 'clusterAdmin', 'userAdmin', 'dbAdmin', etc.
This page has more details about how to configure security in MongoDB for a sharded cluster.