Linux – Multiple MongoDB instances on same server

centoslinuxmongodb

We set up a MongoDB development server on CentOS 6.3 and were able to separate different projects by using separate config files and rc scripts. Now we're looking at setting up a MongoDB production environment.

I've read that it is not recommended to host multiple instances of MongoDB on the same server in production. Does that mean each project will need its own production MongoDB environment?

These projects are not very "big" and so do not require a lot of resources, so it feels like we're jumping the gun by giving each its own host. Perhaps we just need to get our heads out of the RDBMS world.

We will be monitoring our development server to see how it fares, but I'm looking for some insight and some of your own personal experience to supplement what I've read.

Best Answer

The reason Mongo/10Gen recommends against running multiple instances of Mongo on the same system has to do with resource availability assumptions. The mongod process assumes it's the only major tenant of the system, and running two such side-by-side will lead to overall worse performance than just running one mongod just with two databases.

Mongo is quite capable of running multiple databases under a single mongod process. These are discrete databases, just under a single master process. Each database handles its own authentication, which gives you separation. You'd run multiple mongod processes if you need different mongo versions for your products.

I'm not enough of an RDBMS DBA to know the best-practice arguments behind separating products by discrete database-binary processes, so I can't refute/assuage/talk-down each point. But as I understand it, accepted practice in Mongo environments is to have a separate database per product.

Related Solutions

Linux DNS Client Update Tool – Comprehensive Guide

Make sure nsupdate is installed, then use it to register your names. The one problem with nsupdate is that you are going to need to permit non-secure dynamic updates. Unless your platform supports nsupdate-gss, and your linux machines are setup with kerberos to be part of the domain.

I have a script that looks like somewhat like this I use in a couple situations, like dynamic registration of OpenVPN clients. In the real script, the IP and actual hostname comes from the vpn server. If you are using a Debian based distribution it would be pretty easy to tweak this script and place it in /etc/network/if-up.d/.

#/bin/bash

dnssrv="192.168.47.12"   # the dns server that will accept the ddns request.
zone="dyn.example.org"   # the name of the zone
ttl="7200"               # 
hostname=`hostname`      # the name of your local host
ip='192.168.47.193'      # IP of the host

(
 echo "server ${dnssrv}"
 echo "zone ${zone}"
 echo "update delete ${farm}"
 echo "update add ${hostname}.${zone} ${ttl} A ${ip}"
 echo "send"
) | /usr/bin/nsupdate

Another alternative may be to just use DHCP for both interfaces at to setup reservations.

Linux – How to safely store proxy passwords in system-wide linux config files

Plain answer it is not possible. The root user has complete access to the server. There are tools like SELinux that could make it harder for other admins but not impossible.

Basically there are three options:

obfuscate it a little by hiding the password somewhere in your directory. I.e. run your own proxy with configuration in ~/boring/work/stuff/completely/unrelated/to/proxy/password.cfg as Steve suggested. Or convince the proxy to ask a program to get the password (or the config file) from some binary that will try to check whether it is sending the password to the proxy process. Or compile the proxy binary with password hardcoded. There are many possibilites but all are security through obscurity.
Store the password somewhere where you are the only admin or you are the only owner (some other server, flashdrive, etc..) and try to convice the proxy to get the password somehow from that location.
Ask for a different password that would not need to be protected against other admins.

First option would be good if you "trust" the oter admins and you just want to protect the password against accidental stuff. The second one would be the "correct secure" way. And the third one would be "correct enterprise" way.

But there is another thing that you should think of. Once the password is loaded into the proxy, bad guy can try to get it out of the proxy. As this may seem to be not so big issue, if the authentication process to the parent proxy uses passwords in plaintext, it may be very easy. And even it could happen as accident by some of the other admins analyzing the network traffic for a valid reason.

Best Answer

Related Solutions

Linux DNS Client Update Tool – Comprehensive Guide

Linux – How to safely store proxy passwords in system-wide linux config files

Related Topic