I moved a mongoDB from one atlas cluster to a different account/different cluster.
To do this I did a dump from the source db and a restore to the new account's cluster.
I did NOT have a problem restoring the db - that went fine - I can visually confirm that the hashes in the new db ARE the same as the old.
When I try to login to my app (pointed to the source) I get in fine, when I change my db setting and point to the new db I get a log in failed.
The api code is the same - running locally, the only thing that is different is the connection string.
I am using bcrypt to hash the passwords - but because the api is sitting on my local machine, that kind of takes any application layer variable out of my problem list.
With the exception of the connection string - I was using the 3.1 driver connection string to connect to the 'old' version, and I decided to try the 3.6 driver version to connect to the 'new'.
Can someone confirm that moving a db from one cluster to another, using the dump and restore method SHOULD not effect hashed password matching.??
And maybe offer suggestions on where to look for answers?
so the only difference on the code is this:
// Old
DB_URI=mongodb://u***:p***#dev0-shard-00-00-1xxx.mongodb.net:27017,dev0-shard-00-01-1xxx.mongodb.net:27017,dev0-shard-00-02-1xxx.mongodb.net:27017/db?ssl=true&replicaSet=Dev0-shard-0&authSource=admin
// new
DB_URI=mongodb+srv://n***:h***#prod-xxx.mongodb.net/test?retryWrites=true
Ok, So I finally got around to playing with stuff, and since the URI was the only change, I switched back to the 3.4 driver syntax (that long ungodly string), and it works fine.
For the record, all my "open" (non-authenticated) API calls, such as with signup, or requesting a forgotten password. and a slew of drop down lookup, all processed thru the api with the 3.6 driver, I also signed up and logged in fine - the only issue is logging in with an account that was created in the previous cluster, with the new driver connection string.
And as confirmation - now that I switched the connection string back to 3.4 - I cannot log into the account I created with the 3.6 connection string.
Related
For this project, I am using a prisma / Postgres database. I have made no changes to my code, and I have pulled a coworkers working version of the code to no avail. I am unable to do anything with the database, I cannot migrate, I cannot run mutations, and I cannot even open the psql console, as every command is met with
P1001: Can't reach database server at localhost:5432
Please make sure your database server is running at localhost:5432
I am not sure what I could have possibly done, I don't know enough about ports or even the contents of app.json well enough to have messed anything up. Now, no mutations can go through.
Interestingly enough, this all happened after I ran npx primsa migrate deploy on the deployed database which is on a EC2 VM from AWS. Since then, the native app associated with the database refuses to work, though it is worth nothing that the webapp connects to the deployed database just fine. This being said, nothing works locally, as the database / Port / Server don't exist anymore according to my machine, which makes no sense. I have no idea how to try to re-spin it, or why every single query / mutation from my Native App now ONLy returns Response not successful: Received status code 400 despite it having the same exact syntax it did when it worked, as well as the WebApp having the same syntax and server (ExpressJS). Does anyone have any ideas what could be causing this?
The error code 400 refers to a bad request coming from the client: too large request, malformed syntax, invalid request message framing, etc.
First step: make sure that your database server is indeed running. Try connecting to it with other SQL Clients or Libraries. Sometimes Prisma is just being difficult.
Second thing: are you hosting the database on the local server? I can assume you are because of the localhost. Make sure no other programs are using this port or maybe waiting for it.
Sorry if this doesn't help. Good luck!
Situation:
Have created today a new Compose for MongoDB Service instance in Bluemix
Need:
I have to access this MongoDB DIRECTLY with tools (eg. Mongo Managemant Studio Pro, mongo.exe, etc.) for bulkloading, testing, ad-hoc data fix, etc.
Problem:
I have not found any docs, samples nor a CLEAR statement that
a) gives me some confirmation that THIS is possible
b) gives me COMPLETE information (not just some technical fragments that might have worked year ago) how to do it.
Maybe I am looking to the wrong places or do not know the right people. However I am stuck on this, and before quitting Bluemix MongoDB maybe somebody has a copy/past solution or handson step by step manual.
Any help welcome. Thanks!
Connecting to MongoDB service in Bluemix from an application is possible. For this answer I have used the application "Robo3T" and here are the steps:
Access your MongoDB Service on you Bluemix account. Usually under
"Cloud Foundry Services"
Open section "Manage", from "Connection Settings" copy from "HTTPS" the connection address and port. In this example "sl-eu-lon-2-portal.5.dblayer.com" and "20651"
In Robo3T create a new connection with the connection address from previous step
In tab Authentication configure database name, username and password
. The credentials are found as in step 1
From "Connection Settings" copy the SSL Certificate into a text file and save locally.
In Robo3T Add the certificate to the connection in the "SSL" tab
Test the connection and save the settings
Answer
YES, Bluemix hosted Compose for MongoDB instances can be connected from the mongo Shell and some updated DB Managment tools.
However, you have to make sure, that in case you are running the newest DB versions, that your tools (shell and DB management GUIs) comply with the newest DB features such as encryption etc.
Origin of the Problem
My problem was due to older and therefore incompatible versions of the mongo shell and DB-managment tools running against the newest MongoDB versions with their specialities on encription and multiple servers to be handled in the URI.
At least two DB managment tools are not compatible with the newest DB version and will take their time to get fixed. The problem is, that both will not tell you about this. They just do not not connect. No logs on either side. Period.
So my advise here: look for tool providers who express dedicated compliance with the specific version of your DB.
Advise to the Bluemix Team
It might not take much time to provide some sample connection strings for the most common tools like the mongo shell, MongoBooster, etc. to take the hassle and guesswork out of interpreting the Environment variables and figuring out what is needed for specific connection strings and what is not.
For instance MongoDB Atlas hosting provides for every cluster readymade connection strings for many tools you can just copy/past and done!
Connecting to Atlas took me 5 Minutes. For Bluemix I have lost hours! Not because it is complex, but because the documentation and the generated Info is somehow incomplete and messy - at least for the ones who do not connection strings for their living!
I am working on Mongodb authorization.
I added users and am using mongod --auth while connecting to the database so that only authorized users are able to see the database.
Right now, mongo db can only be able to access throught vpn.
Suppose if a hacker breaks into the server machine, he can close the existing mongod connection(which was running with security using --auth) and can start a new connection without authentication mode after which he can see all the data of the database.
How can we secure database so that everytime it asks for the username/password to be provided.
Or some other ways to prevent this.
Thanks.
If he breaks into the server machine, he won't restart mongo. He would simply copy the mongo database and open it on his own machine, without using mongo at all.
If the attacker has the control of a server running process P1, P2, ... each Pi has to be considered breached, including theirs data.
The exception is strong isolation (i.e. virtual machines) and crypto; if the application crypts all its data with a key whose generation is not fully automated (i.e. a passphrase to be inserted on the startup, a challenge/response the administrator needs to pass during the boot, etc ...) this may prevent the attacker from getting all the bits to decrypt it. Otherwise, if the application is able to encrypt and decrypt without any human help, the attacker is able to do it as well.
Those things do not apply to mongo, that does not have support for stuff like that. Good old SQLs have it but they are not trendy any more ;)
On the specific user: are you afraid they will break into as mongodb or as another user? Because if they get the user foo, they still may have problems in accessing mongodb (data or process) if local permissions are well set. But again, people tend to consider the local privilege escalation (i.e. moving from foo to root and then to mongodb) something that happens when someone breaches. In roughly 100 pentests I managed to get access to a machine, probably just once or twice I could not escalate.
I'm trying to get a Play (2.1) app with ReactiveMongo (0.9) working on the app's test server. However, when our application is run on my dev box, is able to store image metadata just fine, even pointing to the mongo 2.2 install on the mongo test server. Even ran it with "play stage", then run directly with java 1.6.0. However, run the same way, also with Java 1.6.0 on the test server, the app continuously logs this error:
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
And not just during initialization... it repeats indefinitely. I've seen this error mentioned elsewhere, but I don't think those solutions apply to this. From the app's test server, I'm able to telnet to port 27017 on the mongo test server successfully. I see both my local install and the test server install of the app log that it's using the same mongodb url.
So based on what I said, I believe I can eliminate:
Blocked port
Mongo server down
Pointing to wrong mongo server
Mongo version mismatch
Java version mismatch
I'm going through the reactivemongo source but it seems the error is spewed when the MongoChannels are not set as authenticating or ready state (usable). I'm planning to try remote-debugging to see where it's going wrong, but I'm running out of time on this, so I'm hoping for a troubleshooting tip or two if I can get any.
Thanks!
Alright, figured it out. We're running Casbah/Salat on the same app, for now. There's a mongodb.uri in the config file that gets read in by both. However, ReactiveMongo seems to only work if the database name is included, which according to the mongodb "connection string uri" spec:
http://docs.mongodb.org/manual/reference/connection-string/
... you only need to include the database if you have credentials you need to authenticate with. In our case, we don't have credentials, so Casbah wasn't including the database. I added it in anyway... casbah ignored it safely, and reactivemongo worked. I neglected to do the same in the test config file, so even though it was showing the correct host, it wasn't about to work correctly.
I see how the host url + db name in one string replaces the two fields "mongodb.servers" and "mongodb.db", but it can be confusing if not conforming to mongo's similar spec.
I'm using the datanucleus mongodb maven plugin and "access platform" for connecting my java app to mongodb using JPA.
I've followed the instructions on http://docs.mongodb.org/manual/tutorial/deploy-replica-set/
on a ubuntu VM, added db1.mongo, db2.mongo and db3.mongo into the hosts file on both the guest vm and the host (Mac OS X).
I got a simple java app connecting to the servers, (as described in http://www.datanucleus.org/products/accessplatform_3_0/mongodb/support.html).
When I connect the app to the primary (connection url: mongodb:db1.mongo:27017/ops?replicaSet=rs0) everything works just fine, but when I add the other two mongodb's to the connection url, so it becomes mongodb:db1.mongo:27017/ops?replicaSet=rs0,db2.mongo:27018,db3.mongo:27019 I get the exception:
com.mongodb.MongoException: can't find a master
at com.mongodb.DBTCPConnector.checkMaster(DBTCPConnector.java:503)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:236)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:216)
...
I've searched for this error, but the ones I have found concerns use of localhost/127.0.0.1. I tried to mitigate that by running mongodb on a separate VM and thus a non-local IP as well as adding the names to the hosts file.
The primary goal with trying mongodb is to achieve availability so replication and being able to failover is extremely important. Transactions and consistency between nodes in case of failure is not a problem, neither are we concerned about loosing an update or two once in a while so mongodb looks like a good alternative using JPA (I'm utterly fed up with mysql :-)
Thanks in advance for your help!
I used multiple MongoDB servers when I originally wrote that support and worked back then. Not got time now, but you can look at the DataNucleus code that parses your datastore connection URL and converts it into MongoDB java API calls. Should strip the servers apart and then call "new Mongo(serverAddrs);". If its passing it in correctly (debugger?), then the problem is possibly Mongo-specific, as opposed to what DataNucleus does for you.
Also make sure you're using v3.1.2 (or later) of datanucleus-mongodb
I think you've misformatted your MongoDB URI. Instead of this:
mongodb:db1.mongo:27017/ops?replicaSet=rs0,db2.mongo:27018,db3.mongo:27019
Do this:
mongodb:db1.mongo:27017,db2.mongo:27018,db3.mongo:27019/ops?replicaSet=rs0