Issue with bind_ip on mongodb mon Virtualbox

mongodbnetworking

I have been struggling with mongo bind IP for a while , I think this is the time to shout for help. I am using hostonly network 192.168.56.0/24 . I have 4 boxes. 3 boxes for mongo 192.168.56.111,192.168.56.112,192.168.56.113. and one box for the app 192.168.56.114.

So for mongo bind param is : bind_ip =127.0.0.1,192.168.56.114,192.168.56.113,192.168.56.112,192.168.56.111,10.0.2.1

2015-08-22T12:35:44.547+0000 E NETWORK  [initandlisten] listen(): bind() failed errno:99 Cannot assign requested address for socket: 192.168.56.114:27017
2015-08-22T12:35:44.553+0000 I JOURNAL  [initandlisten] journal dir=/var/lib/mongodb/journal
2015-08-22T12:35:44.554+0000 I JOURNAL  [initandlisten] recover : no journal files present, no recovery needed
2015-08-22T12:35:44.623+0000 I JOURNAL  [durability] Durability thread started
2015-08-22T12:35:44.624+0000 I JOURNAL  [journal writer] Journal writer thread started
2015-08-22T12:35:44.624+0000 I CONTROL  [initandlisten] MongoDB starting : pid=3519 port=27017 dbpath=/var/lib/mongodb 64-bit host=vagrant-ubuntu-trusty-64
2015-08-22T12:35:44.625+0000 I CONTROL  [initandlisten] db version v3.0.5
2015-08-22T12:35:44.625+0000 I CONTROL  [initandlisten] git version: 8bc4ae20708dbb493cb09338d9e7be6698e4a3a3
2015-08-22T12:35:44.625+0000 I CONTROL  [initandlisten] build info: Linux ip-10-183-35-50 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49
2015-08-22T12:35:44.625+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2015-08-22T12:35:44.626+0000 I CONTROL  [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1,192.168.56.114,192.168.56.113,192.168.56.112,192.168.56.111,10.0.2.15", port: 27017 }, storage: { dbPath: "/var/lib/mongodb" }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log" } }
2015-08-22T12:35:44.631+0000 I CONTROL  [initandlisten] now exiting
2015-08-22T12:35:44.631+0000 I NETWORK  [initandlisten] shutdown: going to close listening sockets...
2015-08-22T12:35:44.632+0000 I NETWORK  [initandlisten] removing socket file: /tmp/mongodb-27017.sock
2015-08-22T12:35:44.632+0000 I NETWORK  [initandlisten] shutdown: going to flush diaglog...
2015-08-22T12:35:44.632+0000 I NETWORK  [initandlisten] shutdown: going to close sockets...
2015-08-22T12:35:44.632+0000 I STORAGE  [initandlisten] shutdown: waiting for fs preallocator...
2015-08-22T12:35:44.632+0000 I STORAGE  [initandlisten] shutdown: final commit...
2015-08-22T12:35:44.635+0000 I JOURNAL  [initandlisten] journalCleanup...
2015-08-22T12:35:44.635+0000 I JOURNAL  [initandlisten] removeJournalFiles
2015-08-22T12:35:44.636+0000 I JOURNAL  [initandlisten] Terminating durability thread ...
2015-08-22T12:35:44.735+0000 I JOURNAL  [journal writer] Journal writer thread stopped
2015-08-22T12:35:44.736+0000 I JOURNAL  [durability] Durability thread stopped
2015-08-22T12:35:44.736+0000 I STORAGE  [initandlisten] shutdown: closing all files...
2015-08-22T12:35:44.736+0000 I STORAGE  [initandlisten] closeAllFiles() finished
2015-08-22T12:35:44.737+0000 I STORAGE  [initandlisten] shutdown: removing fs lock...
2015-08-22T12:35:44.737+0000 I CONTROL  [initandlisten] dbexit:  rc: 48

I really don't see what's wrong anything with any other IP. aside loopback, own IP and 0.0.0.0/0 every other IP fails to start mongodb.

Best Answer

The bind_ip directive is meant to specify the IP addresses on that same system to which MongoDB listens for connections, not IP addresses from which it receives connections.

Set this option to configure the mongod or mongos process to bind to and listen for connections from applications on this address. You may attach mongod or mongos instances to any interface; however, if you attach the process to a publicly accessible interface, implement proper authentication or firewall restrictions to protect the integrity of your database.

So it should either be absent (recommended), or contain 127.0.0.1 to accept only local connections, or the IP address of the local network interface.

If you want to restrict what IP addresses can connect to MongoDB, you'll need to use the firewall.

Related Solutions

How to filter MongoDB Replica Set Heartbeats with tcpdump

Building on this document, first we need to decide what our identifying trait is, so that the filter is successful and only picks out the heartbeats. Then, we need to get the hex representation of that identifier. Starting with the outbound heartbeat itself (which is essentially just a query/command), it is an admin command and contains the following string:

replSetHeartBeat = 0x7265706c536574486561727446265174 (16 bytes)

Now that we have the identifying string, we need to figure out where to look inside TCP. The offset is calculated like so:

32 bytes for TCP gets you to the MongoDB wire protocol, and then:

4 bytes - message length
4 bytes - request ID
4 bytes - response to
4 bytes - opcode
4 bytes - flags
11 bytes - collection name (this is always the same in this case, but could vary in general)
4 bytes - numtoskip
4 bytes - numtoreturn
4 bytes - doc length
1 byte - type

Therefore the total offset is: (32+4+4+4+4+4+11+4+4+4+1) = 76 bytes

Hence you would think something like this is what is required:

sudo tcpdump -i eth0 'tcp[76:16] = 0x7265706c536574486561727446265174'

Sadly, tcpdump only allows up to 4 byte matches at a time, so you actually need to break it up into 4 x 4 byte chunks and use a logical AND to combine the matches:

sudo tcpdump -i eth0 '(tcp[76:4] = 0x7265706c) and (tcp[80:4] = 0x53657448) and (tcp[84:4] = 0x65617274) and (tcp[88:4] = 0x62656174)'

That covers the outbound part of the heartbeat, but what about the reply?

Thankfully the reply on the heartbeat is a lot easier to match - we are looking for the rs:true part of the document, and that translates as follows, handily fitting into 4 bytes:

rs : true = 0x72730001 (4 bytes)

Calculating the offset in a similar way (the only real difference is an 8 byte cursor ID rather than the 11 byte collection name) we get a 73 byte offset, and that gets us this filter:

sudo tcpdump -i eth0 'tcp[73:4] = 0x72730001'

Finally, let's put that all together and add some of my preferred tcpdump options. In the end we get this command:

sudo tcpdump -Xs0 -nnpi eth0 -w heartbeats.pcap '((tcp[76:4] = 0x7265706c) and (tcp[80:4] = 0x53657448) and (tcp[84:4] = 0x65617274) and (tcp[88:4] = 0x62656174)) or tcp[73:4] = 0x72730001'

(Tested successfully using MongoDB 2.4.4 on Mac OS X and on Linux)

Of course, this can also be applied more generally, you just need to work out the appropriate matching criteria, offset and byte matches.

For reference, you can use the same criteria, but with a slightly different syntax to test this type of filtering in Wireshark. The equivalent Wireshark filters for the above criteria are:

tcp[76:16]==72:65:70:6c:53:65:74:48:65:61:72:74:62:65:61:74
tcp[73:4]==72:73:00:01

MongoDB copyDatabase failed with dbOwner

There are access requirements on both the source and target databases in order to be able to perform a copy. Assuming you are using 2.6 (which I think you are given that the dbOwner role was introduced in 2.6), the requirements are laid out in detail here (note: you should not use copyDatabase with roles in 2.4):

http://docs.mongodb.org/manual/reference/method/db.copyDatabase/#required-access

The copy actually runs on the target instance (the one you are copying to), so I'm guessing that is the issue here, that you do not have the correct permissions on the target host.

Best Answer

Related Solutions

How to filter MongoDB Replica Set Heartbeats with tcpdump

MongoDB copyDatabase failed with dbOwner

Related Topic