We have an old MongoDb 2.2.6 deployment and lately we were requested to introduce anonymous user blocking to the Db. I followed the MongoDb tutorials and created an authentication user first and started the mongod with
--auth
parameter.
Then after login, I could not execute any db related commands except for the
use << db >>
. Everything was perfect. But then I tried issuing
use <<< some_junk_db_name >>
without authentication and then issued
db.some_collection.find()
command. Mongodb correctly raised an exception but later when I checked, that DB was there.
Is this a bug with MongoDb 2.2.6 or am I missing something here ?
This is a reported Bug with the number 2080 and the ticket is still not fixed. The last comment, May 17 2013, from a MongoDB Inc. member says that the Bug is still existing in the 2.4 version of MongoDB.
In Version 3.4 the Bug was no longer reproducable.
Related
I am using mongodb 3.2.11 in Ubuntu Zesty 17.04 and I am connecting from Nodejs 4.6 to mongodb in HTTPS, the database server is bound to its own address (127.0.0.1) and I have created a user besides admin for read/write to the database.
Although, most of my tables were certainly dropped somehow, only users (empty) and sessions table were left.
I grepped my logs for "drop" with grep -r "drop" and got no results. Despite I am using very recent versions of the software and made some security measures they don't seem enough. At this time I don't need to recover the data, but I wanted to know what else should I be looking at?
Try to use "show collections" in the mongo shell in ubuntu and see if the collections are shown after doing "use dbnamehere".
We just migrated our infrastructure on AWS from one account to another.
The mongo version installed on the server is 2.4.9
I am new to MongoDb and faced the following 2 errors when I ran the web app -
{"name":"MongoError","errmsg":"exception: FieldPath field names may not start with '$'.","code":16410,"ok":0}
and
{"name":"MongoError","errmsg":"exception: the $cond operator requires an array of 3 operands","code":16019,"ok":0}
The web app was working on our previous instances. Can anyone point me in the right direction?
Upgrading to the latest mongodb (3.0.2) helped resolve this issue for me.
P.S. - Make sure you kill the mongod process already running using killall -15 instead of pkill -9 as the latter could cause damage.
Folks,
When running a mongodump command, I get the following error:
assertion: 17369 Backing up users and roles is only supported for clusters with auth schema versions 1 or 3, found: 5
Any suggestions on how to address? MongoDB v2.8
Your version of mongodump might be to old. Running a v2.6 client with a v2.8+ server (with the new auth scheme) will give this error.
In my case I was running MongoDB v3.0 on the server, trying to make a dump with MongoDB v2.6 client. After upgrading mongodb-org-tools to v3.0 on my laptop, the problem went away.
I have a rails-app which uses both mongoid and mongo. I use mongoid for my own models, and I use mongo because I have ruote with a ruote-mon storage.
In production however; I get
Mongo::ConnectionFailure: Failed to connect to a master node at localhost:27017
when I try to connect to the ruote storage. Even when I just do Mongo::MongoClient.new
Steps I have taken so far to try to resolve this:
I have made my mongodb an explicit master by setting master = true in /etc/mongod.conf
There are no $ENV variables set that could intervene with Mongo::MongoClient.new (double checked)
I have tried to connect using Mongo::MongoClient.new(:slave_ok => true) - same error
I have restarted my mongo database several times (w/o success).
I have checked my firewall settings and I can connect to localhost:27017 with telnet (as said, the mongoid documents can be fetched and stored w/o issue)
I am out of my wits... Any suggestions?
The reason this happened is because we were sending queries with meta operators ($query, $orderby, etc...) for the ismaster command during a connect. This command's output is used to determine whether you are connected to a primary or not and would fail because very old versions of mongodb don't support the use of meta operators.
This fix will be in version 1.8.2 of the gem but I strongly encourage anyone who is still running pre-1.8 versions of mongodb to upgrade. 2.0 is the current legacy release as of the time of this post and even 1.8 is no longer widely supported.
As jmettraux mentioned you can find more details about this on the MongoDB project Jira under Ruby-525
please look at: https://jira.mongodb.org/browse/RUBY-525
Should be fixed by the 1.8.2 mongo gem.
It was corrected two days ago. And yesterday I committed some changes to heroku and the application crashed, I found from heroku logs that:
/app/.bundle/gems/ruby/1.9.1/gems/mongo-1.4.0/lib/mongo/db.rb:137:in `issue_authentication': Failed to authenticate user 'larryzhao' on db 'uthenera' (Mongo::AuthenticationError)
I even explicitly input the host/port/username/password/db name into mongoid.yml, still it could not get pass authentication.
I tried both database in Rackspace and in Amazon, but neither could authenticate.
Have you met with that before? Is there anything else I could check on Heroku besides heroku logs ?
Thanks.
Today I encountered the same on Heroku:
Mongo::AuthenticationError: Failed to authenticate user 'heroku_app111' on db 'heroku_app111'.
from /home/ad/.rvm/gems/ruby-2.1.3#app/gems/mongo-1.11.1/lib/mongo/functional/authentication.rb:205:in `issue_authentication'
It's not because of this RUBY-890 bug, but because MongoLab upgraded to MongoDB 3.0 which uses SCRAM-SHA-1 challenge-response user authentication mechanism. So I needed latest ruby mongo driver version which is counting with this. In my case latest 1.x branch.
The minimum driver versions that support SCRAM-SHA-1 are:
Driver Language Version
C 1.1.0
C++ 1.0.0
C# 1.10
Java 2.13
Node.js 1.4.29
Perl 0.708.0.0
PHP 1.6
Python 2.8
Motor 0.4
Ruby 1.12
Scala 2.8.0
Of course you have to be sure your credentils are ok :)
Make sure you're using the right username to connect to your database. The username you use to log into mongolab.com is different from the one attached to the 'uthenera' database. Have a look at the Users tab for that database at mongolab.com to see what database user(s) you've configured.
Hope that helps. Feel free to email support#mongolab.com if you need further assistance.
-Robert
You can get your database username and password using:
heroku config | grep MONGODB_URI
The response is in this format:
MONGOLAB_URI: mongodb://username:password#mlab.com:12345/db