Configuring MongoDB for Smart IT
MongoDB is included with and used by BMC MyIT and BMC Remedy with Smart IT (Smart IT). MongoDB is a database intended for very large amounts of data. It is high performance, because the lack of joins or embedding make reading and writing data fast. MongoDB can be used in high availability environments through replicated servers with automatic fail-over. MongoDB is scalable through automatic sharding, which means automatic partitioning of data across partitions.
The MongoDB database provides replica sets to support high availability and automatic failover. Replica sets are clustered servers that use the following types of servers:
- Primary — Stores the data; all read/write operations go to this server from any client. One server is always the primary server.
- Secondary — Stores backup data and is synchronized with the primary server. If the primary server is unavailable, the replica set elects a secondary server to become the primary server.
- Arbiter — Stores no data, cannot become the primary server during failover, and participates in the election process during failover only. Typically, arbiters are required only to break ties when there is an even number of secondary servers.
Note
The installer for BMC MyIT and SmartIT can install MongoDB only on the same server as it installs BMC MyIT and Smart IT. While that configuration is suitable for development and testing, it does not provide the high availability and scalability that you need for your production environments. Use the guidelines and procedures in this topic to securely set up and configure MongoDB for your production environment.
Overview of deploying MongoDB securely in a production environment
The following table summarizes the process of deploying MongoDB securely in a production environment
Procedure | Section with instructions |
---|---|
Install MongoDB on the primary server and configure it. | Installing and setting up MongoDB |
Deploy MongoDB as a replica set on the secondary server and on the arbiter server. | Deploying MongoDB as a replica set |
Apply security settings. | Applying security settings |
Supported versions
The following table indicates the versions of MongoDB and Elasticsearch that BMC MyIT and Smart IT support:
Product | Versions supported | Version provided |
---|---|---|
MongoDB | MongoDB 2.4.x MongoDB 2.6.x (recommended) | MongoDB 2.6.8 |
Elasticsearch | (MongoDB 2.4.x) Elasticsearch 0.9.10 (MongoDB 2.6.x) Elasticsearch 1.4.2 | Elasticsearch 1.4.2 |
Installing and setting up MongoDB
Follow this procedure to install and set up MongoDB on your primary server.
- Run with root access:
(Linux) Run thesudo su
command.
(Windows) Run as the system administrator. - Download MongoDB:
- (Linux)
curl -O http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.6.8.tgz
- (Windows) http://downloads.mongodb.org/win32/mongodb-win32-x86_64-2008plus-2.6.8.zip
(Or, to get specific versions: http://www.mongodb.org/downloads#previous)
- (Linux)
Extract the MongoDB archive:
(Linux)tar -zxvf mongodb-linux-x86_64-2.6.8.tgz
(Windows) Unzip.Copy MongoDB to the target directory:
(Linux)mkdir -p /dbdata/mongodb
cp -R -n mongodb-linux-x86_64-2.6.8/ /dbdata/mongodb
(Windows)
Create c:\dbdata\mongodb.
Move the extracted folder to c:\dbdata\mongodb.Create the database data directory:
(Linux)mkdir -p /dbdata/mongodata
(Windows) Create c:\dbdata\mongodata.- If you are installing MongoDB as part of a replica set, create a key file. Your replica set deployment will use this key to authenticate servers to each other.
Ensure that your key file meets the following requirements:- Contains 6 to 1024 characters and contains only characters in the base64 set.
- (Linux only) Does not have group or world permissions on UNIX systems (the
chmod 600 yourKeyFile command
). - Setting keyFile enables authentication and specifies a key file for the replica set members to use when authenticating to each other.
- Key file content is arbitrary but is the same on all members of the replica set instances that connect to the set.
Example commands for Linux:openssl rand -base64 741 > mongo.key
chmod 600 mongo.key
ORtr -cd '[:alnum:]' < /dev/urandom | fold -w50 | head -n1 > "mongo.key"
Example command for Windows:
Create themongo.key
file inc:\dbdata\mongodb
with the following content:mysecretkey007
- Start the MongoDB server.
Windows:
c:\dbdata\mongodb\mongodb-linux-x86_64-2.6.8/bin/mongod --dbpath c:\dbdata\mongodata --port 27017
Unix:/dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongod --dbpath /dbdata/mongodata --port 27017
Connect to the mongo shell and create the administrator user and the social database administrator:
use admin db.createUser( { user: "siteUserAdmin", pwd: "password", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] }); db.createUser( { user: "siteRootAdmin", pwd: "password", roles: [ { role: "root", db: "admin" } ] }); use social db.createUser( { user: "social_admin", pwd: "password", roles: [ { role: "dbOwner", db: "social" } ] });
- Stop the mongo process that was started in step 7.
(Linux only) Add MongoDB as a service with the key file parameter:
On Red Hat Enterprise Linux (including CENT OS), create the file /etc/mongod.conf and add the following settings:
Note
For MongoDB 2.6.x, remove setParameter = textSearchEnabled=true.
dbpath = /dbdata/mongodata port = 27017 logpath = /dbdata/mongodb/mongo_social.log logappend = true quiet = true journal = true replSet = myitsocial fork = true keyFile = /dbdata/mongodb/mongo.key nohttpinterface = true
Create the file /etc/init.d/mongorepl with the appropriate permissions and the following content:
#!/bin/sh # # /etc/init.d/mongorepl # Subsystem file for "MyIT-MongoRepl" server # # chkconfig: 2345 95 05 (1) # description: MyIT-MongoRepl server daemon #MONGOBIN -> point to mongod binary. MONGOBIN="/dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongod" do_start() { echo "starting!"; eval "$MONGOBIN -f /etc/mongod.conf"; } do_stop() { echo "stopping!" eval "$MONGOBIN -f /etc/mongod.conf --shutdown"; } case "$1" in start) do_start ;; stop) do_stop ;; esac exit 0
- Use Redhat's
chkconfig
utility to start the service automatically:- To add to chkconfig:
chkconfig --add mongorepl
- To enable in run levels:
chkconfig mongorepl on
- To start:
service mongorepl start
- To stop:
service mongorepl stop
- To add to chkconfig:
- (Windows only) Start the MongoDB service with the key file:
Create the file c:\dbdata\mongodb\mongodb-win32-x86_64-2008plus-2.6.8\mongod.cfg and add following settings:
Note
For MongoDB 2.6.x, remove setParameter = textSearchEnabled=true.
dbpath=c:\dbdata\mongodata port=27017 logpath=c:\dbdata\mongodb\mongo_social.log logappend=true quiet=true journal=true replSet=myitsocial keyFile = c:\dbdata\mongodb\mongo.key nohttpinterface = true
As administrator, open the command prompt window and run the following command:
c:\dbdata\mongodb\mongodb-win32-x86_64-2008plus-2.6.8\bin\mongod.exe --config c:\dbdata\mongodb\mongodb-win32-x86_64-2008plus-2.6.8\mongod.cfg --install
- To start the service, run the
net start MongoDB
command.
Deploying MongoDB as a replica set
Best practice
For your production environment, deploy MongoDB as a replica set.
Replication provides redundancy and increases data availability. With multiple copies of data on different database servers, replication protects a database from the loss of a single server. Replication also allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster recovery, reporting, or backup.
You can use replication to increase read capacity. Clients have the ability to send read and write operations to different servers. To increase the locality and availability of data for a distributed environment, you can maintain replica servers in different data centers.
For development and testing environments, you can skip this procedure and run MongoDB as a stand-alone server. The examples in this procedure use the following configuration:
- MongoDB1 server with the IP address 10.20.30.40
- MongoDB2 server with the IP address 10.20.30.41
- MongoDB3 server with the IP address 10.20.30.42
Before you begin
Log on to the first MongoDB server and install MongoDB following the steps in To set up MongoDB.
To deploy MongoDB as a replica set
After you log on and install MongoDB, verify that MongoDB is running:
ps -aef|grep mongo
You should see output similar to the following example:rlakkamr 35368 35347 0 06:10 pts/0 00:00:00 grep mongo root 46274 1 0 Aug08 ? 00:13:32 /dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongod --replSet myitsocial \--logpath .1.log. --dbpath /dbdata/mongodata \--port 27017 --keyFile /dbdata/mongodb/mongo.key \--setParameter textSearchEnabled=true once verified
- Start the mongo shell.
Example:/dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongo
Issue the following commands:
> use admin > db.auth("siteRootAdmin", "<your-password-goes-here>"); 1
> rs.initiate() { "info2" : "no configuration explicitly specified -- making one", "me" : "10.20.30.40:27017", "info" : "Config now saved locally. Should come online in about a minute.", "ok" : 1 }
After a few minutes, verify in the same window with the
rs.conf()
command:> rs.conf() { "_id" : "social", "version" : 1, "members" : [ { "_id" : 0, "host" : "10.20.30.40:27017" } ] }
- For the other MongoDB servers, follow the procedure in To set up MongoDB except for steps 7 to 9.
- From the mongo shell on the first server (MongoDB1), complete the following tasks:
- Run the following command:
/dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongo
- Run the
db.auth
command:
> db.auth("admin", "<your-password-goes-here>"); 1
- Add member:
>rs.add("10.20.30.41:27017")
>rs.add("10.20.30.42:27017") To check the status of the replica set, run the
rs.status()
command.
You should see output similar to the following example:{ "set" : "myitsocial", "date" : ISODate("2014-08-12T06:15:02Z"), "myState" : 1, "members" : [ { "_id" : 0, "name" : "10.20.30.40:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 303165, "optime" : Timestamp(1407521114, 1), "optimeDate" : ISODate("2014-08-08T18:05:14Z"), "self" : true }, { "_id" : 1, "name" : "10.20.30.41:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 302985, "optime" : Timestamp(1407521114, 1), "optimeDate" : ISODate("2014-08-08T18:05:14Z"), "lastHeartbeat" : ISODate("2014-08-12T06:15:02Z"), "lastHeartbeatRecv" : ISODate("2014-08-12T06:15:02Z"), "pingMs" : 0, "syncingTo" : "10.20.30.40:27017" }, { "_id" : 2, "name" : "10.20.30.42:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 302985, "optime" : Timestamp(1407521114, 1), "optimeDate" : ISODate("2014-08-08T18:05:14Z"), "lastHeartbeat" : ISODate("2014-08-12T06:15:02Z"), "lastHeartbeatRecv" : ISODate("2014-08-12T06:15:02Z"), "pingMs" : 0, "syncingTo" : "10.20.30.40:27017" } ], "ok" : 1 }
- Run the following command:
(Optional) To rotate mongodb logs, run the
logRotate
command from the admin schema:use admin db.runCommand( { logRotate : 1} )
- For Linux, ensure that ulimit is set to 64000:
ulimit -n 64000
For each BMC MyIT or SmartIT server, change the config.js file in Smart_IT_MyIT/social:
"db_host":"mongodb://10.0.0.1:27017,10.0.0.2:27017,10.0.0.3:27017/", "db_name": "social", "db_auth": true, "db_username": "social_admin", "db_pw": "password",
Applying security settings
You can restrict MongoDB access by using any combination of the following methods:
Restricting MongoDB access by enabling authentication
Follow this procedure for a stand-alone environment only (not when running MongoDB as a replica set).
Log on to the MongoDB shell and enter the following commands:
use admin db.createUser( { user: "siteUserAdmin", pwd: "password", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] }); use social db.createUser( { user: "social_admin", pwd: "password", roles: [ { role: "dbOwner", db: “social” } ] });
- Enable authentication by using either of the following methods:
- Start the mongod process by using the
--auth
option. - In the mongo configuration, set
auth = true
and restart the mongo service.
- Start the mongod process by using the
To connect the BMC MyIT or Smart IT social service to mongo, change config.js in Smart_IT_MyIT/social to use the following value:
Original value New value mongodb://localhost:27017/
mongodb://social_admin:yourPassword@ipAddress:portNumber/
- Restart the social service.
Restricting MongoDB access by explicitly binding mongod to an IP address
You can explicitly bind mongod to a particular IP address such as a private network. You do so by using the bindIp configuration file option. For details, see http://docs.mongodb.org/v2.6/reference/configuration-options/#bind_ip.
Restricting MongoDB access by using network layer security
This section describes the following security configurations for Linux and Windows:
Configure Linux iptables Firewall for MongoDB
On contemporary Linux systems, the iptables program provides methods for managing the Linux Kernel netfilter or network packet filtering capabilities. These firewall rules enable administrators to control which hosts can connect to the system, and limit risk exposure by limiting the hosts that can connect to a system.
Rules in iptables configurations fall into chains, which describe the process for filtering and processing specific streams of traffic. Chains have an order, and packets must pass through earlier rules in a chain to reach later rules. Only the following chains are addressed here:
- INPUT — Controls all incoming traffic
- OUTPUT — Controls all outgoing traffic
The default policy of iptables is to allow all connections and traffic unless explicitly disabled.
Note
Allow traffic from the BMC MyIT and Smart IT server to and from mongod Instances
This pattern is applicable to all mongod instances running as stand-alone instances or as part of a replica set.
The goal of this pattern is to explicitly allow traffic to the mongod instance from the BMC MyIT and Smart IT server. In the following examples, replace <ip-address> with the IP address of the BMC MyIT and Smart IT server:
iptables -A INPUT -s <ip-address> -p tcp --destination-port 27017 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d <ip-address> -p tcp --source-port 27017 -m state --state ESTABLISHED -j ACCEPT
The first rule allows all incoming traffic from <ip-address> on port 27017, which allows the application server to connect to the mongod instance. The second rule allows outgoing traffic from the mongod instance to reach the application server.
Change default policy to DROP
The default policy for iptables chains is to allow all traffic. After completing all iptables configuration changes, you must change the default policy to DROP so that all traffic that is not explicitly allowed will be unable to reach components of the MongoDB deployment. To change this policy, issue the following commands:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
Make all iptables rules persistent
By default, all iptables rules are stored in memory only. When your system restarts, your firewall rules revert to their defaults. When you have tested a rule set and have guaranteed that it effectively controls traffic, you can use the following operations to make the rule set persistent:
On Red Hat Enterprise Linux, Fedora Linux, and related distributions, issue the following command:
service iptables save
On Debian, Ubuntu, and related distributions, use the following command to dump the iptables rules to the /etc/iptables.conf file:
iptables-save > /etc/iptables.conf
Run the following operation to restore the network rules:
iptables-restore < /etc/iptables.conf
Add this command to the rc.local file or the /etc/network/if-up.d/iptables file with other similar operations.
Configure Windows netsh Firewall for MongoDB
On Windows Server systems, the netsh program provides methods for managing the Microsoft Windows Firewall. These firewall rules enable administrators to control which hosts can connect to the system, and limit risk exposure by limiting the hosts that can connect to a system.
The Windows Firewall processes rules in an order determined by rule type. Rules are parsed in the following order:
- Windows service hardening
- Connection security
- Authenticated bypass
- Block
- Allow
- Default
By default, the policy in Windows Firewall allows all outbound connections, and blocks all incoming connections.
Note
port
configuration setting to configure different ports, modify the rules accordingly.Allow traffic from the BMC MyIT and Smart IT server to and from mongod.exe instances
This pattern is applicable to all mongod.exe instances running as stand-alone instances or as part of a replica set. The goal of this pattern is to explicitly allow traffic to the mongod.exe instance from the BMC MyIT and Smart IT server.
netsh advfirewall firewall add rule name="Open mongod port 27017" dir=in action=allow protocol=TCP localport=27017
This rule allows all incoming traffic to port 27017, which allows the BMC MyIT and Smart IT server to connect to the mongod.exe instance.
Windows Firewall also allows enabling network access for an entire application rather than to a specific port, as in the following example:
netsh advfirewall firewall add rule name="Allowing mongod" dir=in action=allow program=" C:\mongodb\bin\mongod.exe"
Manage and maintain Windows Firewall configurations
This section contains a number of basic operations for managing and using netsh. While you can use the graphical interface to manage Windows Firewall, all core functionality is accessible from netsh.
Task | Command | Description |
---|---|---|
Delete all Windows Firewall rules |
| Delete the firewall rule allowing mongod.exe traffic.
|
List all Windows Firewall rules | netsh advfirewall firewall show rule name=all | Return a list of all Windows Firewall rules. |
Reset Windows Firewall | netsh advfirewall reset | Reset the Windows Firewall rules. |
Back up and restore Windows Firewall rules |
| To simplify administration of a larger collection of systems, you can export or import firewall systems from different servers) rules on Windows. Replace path with the directory of your choice. |
Storing the MongoDB password in encrypted format in the configuration file
As an additional security measure, you can encrypt the MongoDB password instead of storing it in plain text.
- Run the setmongodbpassword.js script in \social\scripts\:
If you have already set the MongoDB username and password in the Smart_IT_MyIT/social/config.js file, remove the username and password:
Original value New value mongodb://social_admin:yourPassword@ipAddress:portNumber/
mongodb://<ip_address>:<port>/
Open the command prompt window and navigate to the MyIT_SmartIT installation folder\social\scripts directory.
Run the setmongodbpassword.js script in pathToNodeExecutable\binary.
(Windows) node.exe setmongodbpassword.js mongodbUsername mongodbPassword
(Linux) node setmongodbpassword.js mongodbUsername mongodbPasswordAfter the setmongodbpassword.js script runs, the social\config.js file is updated with the following attributes:
"db_username": "social_admin", //user_name of DB "db_pw": "2738327c3d7eb81bc40b57c818dcbd62", // password is encrypted using the auto generated cipher and will be handled in the application to decrypt. "db_auth": true // Is set to true for authentication of mongoDB on the application.
- Restart the social service.
Comments
Log in or register to comment.