Space banner

   

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

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.
  • SecondaryStores 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

Setting up an auto-failover replica set for a production environment requires a minimum of three MongoDB systems.

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

ProcedureSection 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:

ProductVersions supportedVersion 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.

  1. Run with root access:
    (Linux) Run the sudo su command.
    (Windows) Run as the system administrator.
  2. Download MongoDB:
  3. Extract the MongoDB archive:
    (Linux) tar -zxvf mongodb-linux-x86_64-2.6.8.tgz
    (Windows) Unzip.

  4. 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.
    M
    ove the extracted folder to c:\dbdata\mongodb.

  5. Create the database data directory:
    (Linux) mkdir -p /dbdata/mongodata
    (Windows) Create c:\dbdata\mongodata.

  6. 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

    OR

    tr -cd '[:alnum:]' < /dev/urandom | fold -w50 | head -n1 > "mongo.key"

    Example command for Windows:
    Create the mongo.key file in c:\dbdata\mongodb with the following content: mysecretkey007
  7. 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
  8. 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" } ]
    });
    
  9. Stop the mongo process that was started in step 7.
  10. (Linux only) Add MongoDB as a service with the key file parameter:

    1. 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
    2. 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

       

    3. 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
  11. (Windows only) Start the MongoDB service with the key file:
    1. 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
    2. 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
    3. 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

  1. 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
  2. Start the mongo shell.
    Example: /dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongo
  3. 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 
    }
  4. 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" 
           } 
       ] 
    }
  5. For the other MongoDB servers, follow the procedure in To set up MongoDB except for steps 7 to 9.
  6. From the mongo shell on the first server (MongoDB1), complete the following tasks:
    1. Run the following command:
      /dbdata/mongodb/mongodb-linux-x86_64-2.6.8/bin/mongo
    2. Run the db.auth command:
       > db.auth("admin", "<your-password-goes-here>"); 1
    3. Add member:
      >rs.add("10.20.30.41:27017")
      >rs.add("10.20.30.42:27017")
    4. 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 
      }
  7. (Optional) To rotate mongodb logs, run the logRotate command from the admin schema:

    use admin
    db.runCommand( { logRotate : 1} )
  8. For Linux, ensure that ulimit is set to 64000:
    ulimit -n 64000
  9. 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).

  1. 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” } ] 
    });
  2. 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.
  3. 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 valueNew value
    mongodb://localhost:27017/mongodb://social_admin:yourPassword@ipAddress:portNumber/
  4. 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

If you have used the port configuration setting to configure different ports, you must modify the rules accordingly.
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:

  1. Windows service hardening 
  2. Connection security
  3. Authenticated bypass
  4. Block
  5. Allow
  6. Default

By default, the policy in Windows Firewall allows all outbound connections, and blocks all incoming connections. 

Note

If you used the 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.

TaskCommandDescription
Delete all Windows Firewall rules

netsh advfirewall firewall delete rule name="Open mongod port 27017" protocol=tcp localport=27017

netsh advfirewall firewall delete rule name="Open mongod shard port 27018" protocol=tcp localport=27018

Delete the firewall rule allowing mongod.exe traffic.

 

List all Windows Firewall rulesnetsh advfirewall firewall show rule name=all
Return a list of all Windows Firewall rules.
Reset Windows Firewallnetsh advfirewall resetReset the Windows Firewall rules.
Back up and restore Windows Firewall rules

netsh advfirewall export "C:\path\MongoDBfw.wfw"

netsh advfirewall import "C:\path\MongoDBfw.wfw"

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.

  1. Run the setmongodbpassword.js script in \social\scripts\:
    1. 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 valueNew value
      mongodb://social_admin:yourPassword@ipAddress:portNumber/mongodb://<ip_address>:<port>/
    2. Open the command prompt window and navigate to the MyIT_SmartIT installation folder\social\scripts directory.

    3. Run the setmongodbpassword.js script in pathToNodeExecutable\binary.
      (Windows) node.exe setmongodbpassword.js mongodbUsername mongodbPassword
      (Linux) node setmongodbpassword.js mongodbUsername mongodbPassword

      After 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.
  2. Restart the social service.

Related topics

Preparing for Smart IT installation

Setting up Search with Social database in Smart IT

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments