I am trying an example at Spring 3 with MongoDB. I can reach MongoDB's interface on port 28017. However examples use 27017 in configuration files. Which one to use?
28017 is admin interface and admin operations can be checked from there via web. However when using MongoDb at applications 27017 should be defined as port. When trying to reach that port given information is that:
You are trying to access MongoDB on the native driver port. For http diagnostic access, add 1000 to the port number
I find it very interesting by doing a very stupid thing. Added 1000 to 27017 and it become 28017, I access localhost:28017 and the admin panel appeared.
best of luck
I suggest you do not use default port in your application.
that is the first hackers are looking for.
Related
I like to find out on which port MMS agent is running for Mongo. Please let me know how to find out. It is not defined on config file. It may be running on default port.
Thanks for your update. It is MongoDB Cloud Manager. I like to know if they use any port for connections like MongoDB database does. It looks it does not as per your answer.
(I've searched SO, AWS support and more widely without success.)
I've just successfully deployed a MEANjs application to a Bitnami MEAN instance on EC2, following Ahmed Haque's excellent tutorial on scotch.io. As part of the tutorial/deployment I altered the AWS Security Group to include port 27017 for MongoDB traffic. The CIDR notation for the port 27017 was 0.0.0.0/0 - which AFAIK means 'allow access from any IP address'.
Question: Why does MongoDB port 27017 need to be opened in AWS EC2
Security Group for a 'production' type environment? Surely this is directly exposing the DB to the
Internet. The only thing that should be talking to Mongo is the
"/server/api" code, which is running on the same instance -
and so shouldn't need the port opening.
If I change the Security Group rule for port 27017 by closing off 27017, changing the source to: localhost, the internal IP address, the public IP address, or hack a CIDR to be equivalent to any of those - then the web app hangs (static content returns but no responses to db backed api calls). Changing the SG rule back to 0.0.0.0/0 almost immediately 'fixes' the hang.
All is otherwise sweet with my install. I've closed port 3000 (the node app) in the Security Group and am using Apache to proxy port 80 traffic to port 3000. Set up like this, port 3000 does not need to be open in the Security Group; to me this implies that on-instance traffic doesn't need ports to be externally exposed - so how come that's not true of the Mongo port?
I cant see anything in the '/client' code which is talking direct to Mongo.
What am I missing?
Thanks in advance - John
OK, after further investigation and overnight/red wine reflection I think I have an answer for those learners like me following the above tutorial (or similar). Following the Agile principle that 'done' means 'working code in a production environment' I was trying to understand the last 5 meters as a developer trying to get code working in a representative production environment (which wouldn't have unnecessary ports open) - this answer is written from that perspective. (Builds welcome from wiser readers.)
What's Happening
The step in the tutorial which (a) changed the Mongo bind IP address from 127.0.0.1 to 0.0.0.0, and (b) specifies a connection URL which uses the external IP address of the same instance, appears to have two effects:
It makes the MongoDB on the instance you're configuring potentially available to other instances (0.0.0.0 tells Mongo to "listen on all available network interfaces".)
It means that the IP traffic from your MEAN app /server component on the same instance will talk to Mongo as though it was coming from off-instance (even though it's on the same instance). Hence the Security Group needs to make port 27017 open to allow this traffic to flow. (This is the nub of the issue in terms of MEANjs stack component interaction.)
Fix
On a single instance MEANjs server, if you change the Mongo bind IP address back to 127.0.0.1 and the Mongo connection url to be 127.0.0.1:27017 then you can close off port 27017 in the EC2 Security Group and the app still works.
To share one MongoDB across more than one MEANjs app server (without wanting to stray into serverfault territory):
Change the Mongo bind IP address to 0.0.0.0,
Use the private IP address of the Mongo server in other app/instance connection strings
Add a EC2 Security Group CIDR rule of private IP address/24, or private IP address/16 to allow access across instances in the specified internal IP address range.
The above is developer 'hack', not a recommendation for good practice.
How to disable TCP port?
Configure only unix socket.
For isolation of local users.
This is a 5 year old bug at least. The only issue I found was closed as WONTFIX and RTFM, but this issue logged against 2.4 here somewhat relates to the issue: https://jira.mongodb.org/browse/SERVER-9383.
MongoDB will refuse to create the unix domain socket unless the IPV4 IP Address is either 127.0.0.1 or 0.0.0.0. You don't get to run it on one interface or disable it (for reasons unstated). To me it's a reflection of the quality of the MongoDB code.
I traced the code back to 2011 and my belief is that it was a crude hack to prevent you from accidentally have 2 mongodb processes trying to create the same socket file. If you ran one instance on 192.168.1.1:27017 and 192.168.1.2:27017, they would both try to create the same socket file at: /tmp/mongod-27017.sock. Since no one at 10gen has a clue as to why that check is in there, no one has fixed it since 2011. It's easy to check that 127.0.0.1:27017 is already in use, because of EADDRINUSE, but it's hard to check that your socket file is stale or if another process created it. I'm not sure why they didn't just name the socket file differently.
See the code here: https://github.com/mongodb/mongo/blob/r2.2.4/src/mongo/util/net/listen.cpp#L91
if (useUnixSockets && (sa.getAddr() == "127.0.0.1" || sa.getAddr() == "0.0.0.0")) // only IPv4
out.push_back(SockAddr(makeUnixSockPath(port).c_str(), port));
I can understand that your concern here is with security in your setup but it is worth considering that MongoDB is built by design to interact in clustered systems and hence TCP networking is part of that design. That said, and as you are aware, there is by default a unix domain socket connection you can use for local access.
You can use the '--bind_ip' configuration option to bind to the loopback only ('127.0.0.1') or only the interface you wish to use, as mongod will by default bind to all available interfaces. For a full list of startup options you might want to look at the manual page to determine what you need.
For other security you can refer to your firewall rules.
Late to the game but for future viewers you can disable tcp by using a bindIP to a socket file.
For example:
net:
port: 8080
# socket filename has port in it
bindIp: /var/tmp/mongodb/mongodb-8080.sock
unixDomainSocket:
pathPrefix: /var/tmp/mongodb
If I start mongo and run lsof -i :8080 I don't see mongo listening on that port.
I'm trying to set up mongodb on webfaction. It works fine, currently running on port 36505 on the server. I can connect to it on the server just fine. But per the firewall, I can't connect to 36505 on the server from the 'net.
I can expose the port by mapping the port to port 80 under a sub-path. So I can make 1.1.1.1:36505 to 1.1.1.1:80/mongodb
My question is how do I actually connect to that? I'm not sure if mongo supports subpaths on port 80 or not...
The problem with what you are doing here is that the WebFaction firewall will prevent direct connections to your MongoDB instance because it isn't speaking straight HTTP and you don't have access to make it use port 80. The simple fix for this is to get a dedicated IP address and then have the support team open a hole in the firewall in order for you to connect directly to the database that way.
Here is an example on the WebFaction community page:
http://community.webfaction.com/questions/3448/using-websockets-with-a-nodejs-custom-app
Im reading the mongodb guide, but I dont get this:
mongodb://fred:foobar#localhost
It says I can connect to the mongodb through web browser.
I have tried this, but it doesn't work. Safari/Firefox can't recognize the mongodb protocol.
And why should I do it?
Isn't the mongodb server just for connecting through the command line?
And what is the difference between port 27017 and 28017?
Should I connect through http or mongodb protocol?
When you start mongod (the MongoDB daemon), it starts listening on two ports by default.
27017: the default port accessed by the various MongoDB drivers.
28017: a port that handles HTTP requests and provides some general monitoring.
What you've listed mongodb://fred:foobar#localhost actually represents this: mongodb://fred:foobar#localhost:27017 and this is the access protocol for MongoDB drivers.
The other "thing" you're seeing is port 28017. This is (by default) simply an overview of what's happening with the mongod instance on that server. Requests made from a web browser to this port will show an HTML output of the server overview.
If you start mongod with a different port number (i.e.: 7777), the "monitor" port will always be 1000 higher (i.e.: 8777).
If you want some advanced features like the ability to query via the web browser, you can start mongod with the --rest switch. You will then be able to run certain queries with a simple http get requestlink text (http://localhost:8777/mydb/mycollection/?filter_a=1).
If you're using language-specific MongoDB drivers (like most people will). Then you'll find that you'll have "connection strings" of the form mongodb://user:pwd#host:port/. These are similar in purpose to the usual connection strings you're used to for other Database products.
Increment by one thousand (28017), and use HTTP, not mongodb.
Note that this will "connect" you to the mongodb process, but it's not like phpMyAdmin or anything.