Block Microsoft Telemetry using NULL routes

Microsoft has hard coded the addresses to their telemetry servers. The known servers are:

We cannot block there via the “hosts” file due to the sites being hard coded.
But we can block them using NULL routes.

First, open an “administrative” command prompt.
Then run the following command.

route print

This will give us our current routing information. We want the first “Gateway” address listed in the “IPv4 Route Table”.
Substitute your own “Gateway” address for “” in the two commands below.

route add mask if 1 -p
route add mask if 1 -p

Now try to ping the hosts, and you will see they are now unreachable.

Quick System Info – Powershell

Here is a PowerShell script to get basic system inventory information about your computers and parse it into CSV format.
Tested on Dell,HP, and Lenovo systems.

$MyArray = $null
$MyArray = @()
$ComputerList = Get-Content "C:\Scripts\Computers.txt"
ForEach ($Computer in $ComputerList){
COMP = $Computer
$MyObj = "" | Select "Computer","Manufacturer","Model","ServiceTag","Memory","HDSerial","User"
$MyObj.Computer = $COMP
$MyObj.Manufacturer = Get-WmiObject Win32_BIOS -Computer $COMP |Select -ExpandProperty Manufacturer
$MyObj.Model = Get-WmiObject Win32_ComputerSystem -Computer $COMP |Select -ExpandProperty Model
$MyObj.ServiceTag = Get-WmiObject Win32_BIOS -Computer $COMP |Select -ExpandProperty SerialNumber
$MyObj.Memory = Get-WmiObject Win32_ComputerSystem -Computer $COMP |Select -ExpandProperty TotalPhysicalMemory
$MyObj.HDSerial = Get-WmiObject Win32_PhysicalMedia -Computer $COMP |Where-Object {$_.tag -like "*PHYSICALDRIVE0*"} |select -ExpandProperty SerialNumber
$MyObj.User = Get-WmiObject Win32_ComputerSystem -Computer $COMP |Select -ExpandProperty UserName
$MyArray += $MyObj
$MyObj = $null
$MyArray |export-csv "C:\Scripts\ComputerReport.csv"

Quick System Info – BASH

Here is a BASH script to get basic system inventory information about your computer and parse it into CSV format.

MANUFACTURER="$(dmidecode -s system-manufacturer)"
MODEL="$(dmidecode -s system-product-name)"
SERVICETAG="$(dmidecode -s system-serial-number)"
MEMORY="$(free |grep "Mem:" |awk '{print $2}')"
echo "${FIELDS}"$'\n'"${MYINFO}"

Troubleshooting Network Connectivity Issues

This tutorial will walk you through the steps of tracking down layer 1 & 2 connectivity issues on a Ethernet segment.

Scenario: Your connection to a device intermittently drops, or is painfully slow.

This could be the result of any number of factors, such as:

  • Bad Medium (cabling, etc.)
  • Electrical Interference
  • Bad Driver
  • Bad Device
  • Mis-configured Device

So let’s start at the top of the list.

Bad cabling is everywhere, I’ve come into an organization just two years after hundreds of new cables were pulled, to find 30% of them were bad, with 8% needing to be pulled again.

So how can we verify if our problem is cabling.

The first step is to verify that we are using the correct cable(s) and distances for the speed of our Ethernet Network. The University of Wisconsin has a great chart here:

The second step is to replace the cable(s), with a known good unit.

Step two doesn’t work very well on cabling that is run through the walls, ceilings, and floors, so you’ll need an analyzer for that purpose. Cable analyzers are expensive, and you’ll probably want to rent one or call in a professional low voltage wiring contractor to run the test for you.

Are you having electrical interference?
Try to see that your cables are not in close proximity to electrical motors, transformers, fluorescent lamps, etc.

Do you have a Bad Driver? Check the NIC’s hardware compatibility for your OS.

To determine your device in linux:
Use “ifconfig” to determine the device name (usually “eth0″)
Use “dmesg |grep DeviceName” to determine the device type

To determine your device in BSD:
Use “ifconfig” to determine the device name
Use “grep DeviceName /var/run/dmesg.boot

Check your compatibility at the sites below:

Do you have a bad device? Try a different port/NIC or completely different computer/switch/hub or other device if you have one available.

Do you have a mis-configured Device?

The first item to examine is our Duplex status. Are both ends set to the same speed and duplex? Are we seeing a lot (more than 0.5%) of packets being dropped?

For linux/bsd try “ifconfig” from the command line. Using “netstat -i” gives us a succinct look at our network statistics.

For linux, using “ethtool -S eth0” gives us a wealth of detailed information about “eth0″. You can also try “ip -s link“, “nstat“, and “sar -n DEV 1 3” if you have sysstat installed.

Our next step will be to whip out trusty old “tcpdump” or the graphical “wireshark” and take a look at the packets flying over the link, typically mirroring a port on our switch. How to use those tools will be a discussion for a future day.

Removable EXTx drive for non-root Linux user

Today, we will cover setting up an external removable drive using the EXT3 file system, and to allow us to mount the drive as a normal (non-root) user. This allows us to keep existing Linux file permissions when we write to the drive, and features journaling which ensures that what we write to the removable drive, is completely written to disk.

This system also allows us to easily create separate mount points for distinct removable drives, which facilitates the use of multiple drives in a scripted backup strategy.

So let’s get started!

First thing we do is determine how the drive is recognized by the kernel:

From the command prompt:

sudo tail -f /var/log/messages
su -c tail -f /var/log/messages

and look for something on the order of “[sdb] Attached SCSI disk” after we plug in our removeable device.

The kernel output will tell us if there are any existing partitions (look for “sdb1″, “sdc1″ etc.)

Ctrl-C to exit tail

Next we need to create a partition table, if there are existing partitions you’ll need to ensure thay do not contain important data before you remove or overwrite them.

Again from the command prompt:

sudo fdisk /dev/sdb
su -c fdisk /dev/sdb

Choose “n” for “new partition”

Then “p” for “primary partition”

Then “1” for the first partition.

Then the defaults for the sectors.

Then “w” to write changes and quit.

Our next step is to create a filesystem

Again from the command prompt:

sudo mkfs.ext3 /dev/sdb1
su -c mkfs.ext3 /dev/sdb1

This might take a while depending on the drive size

While we wait, open another terminal window and continue working.

We are going to name our disk “BU_Linux” but feel free to change the name, but avoid spaces and wildcard/reserved characters in the name (No: “.”, “\”, “?”, “!”, etc.). We will mount the disk using the same name under the “/media” directory.

Again from the command prompt:

sudo mkdir -p /media/BU_Linux
su -c mkdir -p /media/BU_Linux

Next we need to backup “/etc/fstab”

sudo cp /etc/fstab /etc/
su -c cp /etc/fstab /etc/

Then we can edit “etc/fstab” using vi:

sudo vi /etc/fstab
su -c /etc/fstab

and add a line as below:

"LABEL=BU_Linux  /media/BU_Linux  ext3  defaults,user,noauto  0 0"

We then will go back to our prior console window, hopefully mkfs.ext3 has finished.

We now create the disk label using “e2label” which can display or change the filesystem label on the ext2, ext3, or ext4 filesystems.

Again from the command prompt:

sudo e2label /dev/sdb1 BU_Linux
su -c e2label /dev/sdb1 BU_Linux

Now let’s mount the drive!

Again from the command prompt:

mount -L BU_Linux

Let’s check if the drive is mounted.

Again from the command prompt:

mount |grep BU_Linux

Which should return:

“/dev/sdb1 on /media/BU_Linux type ext3 (rw,noexec,nosuid,nodev,user=MyUserName)”

Now let’s examine the drive.

Again from the command prompt:

df -h /media/BU_Linux

Which tells us how much free space is available


ls -al /media/BU_Linux

which should show us the “lost+found” directory

Now if we try to write a file ie.:

echo "This is a test" > /media/BU_Linux/test.txt

You’ll see that you cannot write to the disk.

So let’s fix this!

Again from the command prompt:

sudo chmod 777 /media/BU_Linux
su -c chmod 777 /media/BU_Linux

And try again!

echo "This is a new test" > /media/BU_Linux/new_test.txt

And we should have success.

This change will survive remounts because the permission you just changed is resident on the volume’s filesystem.

When you are finished you’ll need to unmount the file system before removing the drive.

Again from the command prompt:

umount /dev/sdb1

vCenter 5.1 Simple Install – Not so simple

VSphere 5.1 came out just over a month ago, introducing a number of new features. One of particular importance to the userbase, is the addition of Single Sign On (SSO) to vCenter, and the separation of vCenter Inventory Service from the vCenter Server core. If you are setting up a proof of concept or lab environment, you are likely to choose the vCenter Simple Install which installs these three components on a single machine under one unified installer.

When both upgrading from vCenter 5.01 and doing a fresh install on a new x64 Windows 2008 Standard Edition R2 server, we encountered significant problems using the Microsoft SQL Server 2008 R2 Express database that is bundled with vCenter Server.

During the upgrade procedure your are prompted to use an existing database, and since you already have the express database installed you’ll likely want to just add a new database to the existing database instance. In order to use your existing database your are prompted for the database’s “sa” password, which we actually do not know. You may input any password to enable the SA account and set the password, but you’ll need to comply with the OS’s password policy. For a Server 2008 R2 Standard host:

Passwords must be at least six characters in length.
Passwords must contain characters from three of the following four categories:

  • English uppercase characters (A through Z).
  • English lowercase characters (a through z).
  • Base 10 digits (0 through 9).
  • Non-alphabetic characters (for example, !, $, #, %).

If you mistakenly enter a password that fails to meet the password complexity requirements, the installation fails soon thereafter. In order to resume the installation you’ll need to reset the “sa” password to meet complexity requirements. Below is one method from the command line:

sqlcmd –S 'localhost\VIM_SQLEXP'
sp_password @new = 'newpassword', @loginame = 'sa'

During a fresh installation we run into a few issues.

Firstly, we need to setup a x64 OBDC DSN, which is difficult to do before you start your vCenter 5.1 Simple Install, as there is no database installed! So, when the installer gets to installing vCenter Server, you’ll need to: cancel out of the installation, set up the DSN as shown below, then restart the vCenter Server installation.

On your Windows Server:

  1. Go to "Administrative Tools"
  2. Go to "Data Sources (ODBC)"
  3. Select "System DSN"
  4. Select "Add"
  5. Select "SQL Server Native Client 10.0"
  6. In the "Name" field enter "Vcenter DSN" or something similar
  7. In the "Description" field enter whatever you like
  8. In the "Server" drop down list select "localhost\VIM_SQLEXP"
  9. Goto the next page
  10. Select "With Integrated Windows authentication"
  11. Goto the next page
  12. Select the "Change the default database to:" and choose "RSA"
  13. Goto the next page
  14. Select "Finish"

Secondly, once we finish the installation we are allowed to log in ONE TIME to vCenter Server using your existing, Windows AD or localhost, credentials (you will also need to deal with the browser certificate errors) when using the vSphere Web Client.

In order to log into vCenter Server, you’ll need to configure your vCenter SSO credentials, so fire up the vSphere Web Client:

  1. Login as "admin@System-Domain"
  2. Navigate to "Home"
  3. Select "Administration"
  4. Select "Sign-On and Discovery - Configuration"
  5. Under "Identity Sources" make sure your preferred group is present
  6. Select "SSO Users and Groups"
  7. Under "vCenter Single Sign On Users and Groups" select the "Groups" tab
  8. Select "_Administrators_" then click on the little person with the "+" sign
  9. Select your preferred "Identity Source" from the pull down menu
  10. Select your vCenter administrative user and/or group and click "add"
  11. Click "Okay" then log out of the vSphere Web Client

You should now be able to login to your vCenter Server using the vSphere Web Client. In the case of using the local administrator account we had to use the username of “administrator@administrators”, which may be a side effect of adding both the local “administrator” user and “administrators” group to our list of preferred “Identity Sources”

Good luck and I hope you’ve found this information useful in your VMware vCenter Server 5.1 installation.

Removing Windows Clients from a non-existent domain

In this post we discuss removing windows clients (xp, etc.) from a domain that no longer exists, or which you no longer have access.

In the course of migrating a small group of computers to a new Linux server running file and print services, I realized that I had to first remove the client machines from a windows domain that no longer existed due to catastrophic hardware failure.

While I had local administrative access, I could not change the clients to workgroup membership, as this step requires authenticating to the domain as an domain administrator.

What to do: Recreate the domain temporarily, and remove the clients from the domain.

On the server side:

  • Navigate over to the “Technet Evaluation Center” and download an evaluation copy of Microsoft Server. You’re going to need to be patient as the download is a few gigabytes.
  • Load the server operating system on your hardware/VM
  • Install the “Dot Net” feature
  • Download updates
  • Configure a static address, setting the machine’s IP address as it’s DNS server’s address
  • Remove internet access from the attached local network
  • Add the “Domain Services” role
  • Run “dcpromo” in an administrative command shell, you’ll need to use the same domain naming schema as the missing domain
  • Create a new user and add them to the domain administrator’s group

On the client side:

  • Set a static IP address to be on the same subnet as the server. You’ll want to set IP address for the default gateway and DNS server to be the address of the newly created domain controller.
  • Navigate to system properties – computer name, then click change
  • Set it to workgroup mode, it will then ask you for the credentials of a domain administrator
  • Give the the credentials of the domain administrator that you created on the temporary domain controller
  • Reboot the client machine

That’s all there is to removing the client from domain membership.

Install Graylog2 web interface on CentOS 6

We will be installing Graylog2 Web interface on CentOS 6 as Part 4 of our series on Monitoring your systems with logstash and Graylog2. ::Part 1::Part 2::Part 3::

Please Note! This configuration is for the 0.9.5 version of Graylog2 Server and has not been verified to function with the changes implemented in version 0.9.6, although most of the implementation should be similar.

We will be installing a Ruby on Rails web application framework driven by Passenger which runs as an Apache module. This means you’ll obviously need Apache installed as well as the g++ compiler (try “yum list gcc*” if you’re stuck) and typical development tools.

The installation overview:

  1. Install required packages
  2. Download Graylog2 Web Interface
  3. Create directory and copy files
  4. Configure Ruby
  5. Configure Bundler
  6. Edit “yml” config files
  7. Install Passenger
  8. Configure Passenger
  9. Configure Apache for Passenger
  10. Restart Apache and check for errors
  11. Check SELinux Status
  12. Set SELinux to permissive mode
  13. Configure database
  14. Create pid directory
  15. Test Ruby install with Brick
  16. Launch Web Interface

So let’s get started!


We’ll need to install some other packages found in the table below.

ruby-static - Static libraries for Ruby Devel
ruby-libs - Libraries Necessary to run Ruby
ruby-gems - Ruby Standard for packaging libraries
rubygem-rake - Ruby based make like utility
rubygem-hoe - rake/rubygems helper for Rakefiles
rubygem-gem_plugin - Plugin System based on Rubygems
ruby-docs Manuals and FAQS
ruby-devel - Ruby development environment
ruby - Interpreter
ruby-irb - Interactive Ruby
compat-readlines - Library for editing typed command lines
ruby-rdoc - tool to generate docs from Ruby source
g++ - GNU C++ compiler
libcurl-devel - Curl development headers with SSL support
openssl-devel - OpenSSL development headers
zlib-static - Zlib development headers
httpd-devel - Apache 2 development headers
apr-devel - Apache Portable Runtime (APR) development headers
apr-util-devel - Apache Portable Runtime Utility (APU) development headers

We’ll next need to download and unpack the Graylog2-web-interface to our home directory.

Next we’ll create a graylog2-web directory and copy the files. As root:

mkdir /var/www/graylog2-web
cd ~/graylog2-web-interface-X.X.X && cp -R ./* /var/www/graylog2-web/
chown -R apache.apache /var/www/graylog2-web/*

We’ll next configure Ruby, so as root run the commands below:

cd /var/www/graylog2-web && gem update
gem install git rake bundler

We next configure bundler

cd /var/www/graylog2-web && bundle install

Edit all “*.yml” files in /var/www/graylog2-web/config as appropriate (I needed to remove the comments in general.yml that were after the directives). Make sure your mongoid.yml matches your graylog2.conf and mongoDB settings as below.

  port: 27017
  username: gluser
  password: grayloguser-password
  database: graylog2

Now we will install passenger to connect to apache. As root:

cd /var/www/graylog2 && gem install passenger

We next will Create and populate /etc/httpd/conf.d/passenger.conf

echo "LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.11/ext/apache2/
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.11
PassengerRuby /usr/bin/ruby" > /etc/httpd/conf.d/passenger.conf

Our next step is to configure apache so passenger can run. You’ll need to edit your “/etc/httpd/conf/httpd.conf” creating a virtual host “gray.localhost”.

DocumentRoot "/var/www/html"
<Directory "/var/www/html">
NameVirtualHost *:80
<VirtualHost *:80>
  ServerName gray.localhost
  DocumentRoot /var/www/graylog2-web/public
  RailsEnv production
  ServerAlias gray.localhost.localdomain
  ErrorLog logs/graylog2-error_log
  CustomLog logs/graylog2-access_log common
   <Directory /var/www/graylog2-web/public>
    Allow from all
    Options -MultiViews

We next restart apache and check for errors.

tail --lines=20 /var/log/httpd/error_log

We likely notice errors that passenger does not start. If your configuration is solid, this is likely caused by SELinux. To see if SELinux is being enforced, as root:


We can temporarily set SELinux to permissive mode. This will log the errors that are generated which will allow us to figure out which modules are being blocked. We can then tighten up the SELinux configuration at a later time. As root, run the following command:

echo 0 > /selinux/enforce

Restart apache again and see if passenger gets loaded this time. If you’re still having problems you will need to check your configuration.

We next create indexes and configure the database to our needs:

cd /var/www/graylog2-web
bundle exec rake db:mongoid:create_indexes RAILS_ENV=production --trace

We need to create a pid directory beneath the script directory and assign rights to apache

mkdir -p /var/www/graylog2-web/script/tmp/pids
chown -R apache.apache /var/www/graylog2-web/*

We can now to start Rails “brick” server as root from the application base directory. We do this to test if our rails setup is working correctly as brick gives us some nice status messages. If all seems good you can kill brick via Ctrl-C.

cd /var/www/graylog2-web
./script/rails server -e production

We should then be able to launch the interface via browser using passenger


Hopefully everything is working as we expect and we are presented with the initial Graylog2 interface. Don’t forget that you’ve probably set SELinux to Permissive mode and will need to configure our file security settings to allow our application to run under SELinux.

A more secure Graylog2 server install

We will installing and configuring Graylog Server on CentOS 6 as Part 3 of our series on Monitoring your systems with logstash and Graylog2. ::Part 1::Part 2::Part 4::

Please Note! This configuration is for the 0.9.5 version of Graylog2 Server and will be updated to reflect the changes in the message store implemented in version 0.9.6

Our goals are simple:

  • Run as an unprivileged user
  • Consistent installation, logging, and configuration locations
  • Automating the installation

The installation overview:

  1. Download Graylog2 Server
  2. Create Intallation environment
  3. Unpack the Archive
  4. Configure Server Parameters
  5. Test installation
  6. Download and install the Java Service Wrapper
  7. Configure the Java Service Wrapper
  8. Test the Java Service Wrapper

We will assume you know the basics of system administration (ie.file permissions, ownership, etc.).
So let’s get this working!

Our first step will be to download the graylog2 server to our home directory.

Our next step is to create the installation environment. I’ve previously created a shell script for also installing logstash which will create the directories we’ll be needing, as well as to create our unprivileged user. You’ll need to run the script as root, but can test it as a normal user quite easily (with some minor modifications to the script).

The command to run the script is:

./prog_dir_setup graylog2

Our script will create the following directories:

~ create “/usr/local/bin/greylog2” to hold our greylog2 executables
       then create “bin” and “lib” directories underneath
~ create “/var/spool/greylog2” for our logs and pid
      then create “log”, “pid” and “data” directories underneath
         Note: we will not be using the data directory
~ create “/etc/greylog2” for our greylog2 config files

Our script will then create a system user named “graylog2”, and
modify directory permissions so “graylog2″ can write to those locations.

~ Create user “graylog2” and group “graylog2” as a system account
       pointing $HOME to “/var/spool/graylog2”
~ Change ownership of directories under “/var/spool/graylog2” to “graylog2.root”

We should next unpack the graylog2 server archive to “/usr/local/bin/graylog2” as root from our home directory.

We next copy the config file to “/etc/graylog2″

cp /usr/local/bin/graylog2/graylog2.conf.example /etc/graylog2/graylog2.conf

Our next step will be to configure our graylog2 server config file. Using your favorite editor edit /etc/graylog2/graylog2.conf such that it resembles the entries below. Remember to use the same username and password from setting up MongoDB

#since we will be getting syslog local from logstash
syslog_listen_port = 9514
# Or any other port over 1024 that you wish to use
#MongoDB Configuration
mongodb_useauth = true
mongodb_user = gluser
mongodb_password = grayloguser-password
mongodb_host =
mongodb_database = graylog2
mongodb_port = 27017

Now we can test if graylog2 server will run with our current configuration. “su” as user “graylog2″ and run the following command.

java -jar -DconfigPath=/etc/graylog2/graylog2.conf \

Now see if you are logging anything to Mongo in another terminal window as root.

tail -f /var/spool/mongo/log/mongod.log

If everything seems to be working as we hoped, we now configure graylog2 to run under the “Java Service Wrapper” which will allow us to run graylog2 as a service, launching as root and forking to run as user “graylog2″.

If you had not done previously, we should now download the Community version of the Java Service Wrapper and unpack it to ~/wrapper (ie. “/home/username/wrapper”).
We will then copy some files from the ~/wrapper directory for our graylog2 config.

~ Copy ‘wrapper.conf” to /etc/graylog2
 "cp ~/wrapper/src/conf/ /etc/graylog2/wrapper.conf"
~ Copy Shell File and rename it to something meaningful
 "cp ~/wrapper/src/bin/ /usr/local/bin/graylog2/bin/graylog2_wrapper"
~ Copy “wrapper” executible
 "cp ~/wrapper/bin/wrapper /usr/local/bin/graylog2/bin/"
~ Copy wrapper/lib/
 "cp ~/wrapper/lib/ /usr/local/bin/graylog2/lib/"
~ Copy wrapper/lib/wrapper.jar
 "cp ~/wrapper/lib/wrapper.jar /usr/local/bin/graylog2/lib/"

Edit the below lines in /usr/local/bin/graylog2/bin/graylog2_wrapper with your favorite editor.

 APP_LONG_NAME="Graylog Server"

Edit the below lines in /etc/graylog2/wrapper.conf with your favorite editor (Note: I’ve hard coded some perfectly valid variables contained in Tanuki’s provided script).

You should now be able to launch graylog2 as root and have it run as graylog2.

In a terminal window as root:

"/usr/local/bin/graylog2/bin/graylog2_wrapper console"

If you run the wrapper script without any parameters, you’ll see it has a number of options available for our use.

[root@mylaptop sphughes]# /usr/local/bin/logstash/bin/logstash0_wrapper

Usage: /usr/local/bin/logstash/bin/logstash0_wrapper [ console | start | stop | restart | condrestart | status | install | remove | dump ]


console     Launch in the current console.
start       Start in the background as a daemon process.
stop        Stop if running as a daemon or in another console.
restart     Stop if running and then start.
condrestart Restart only if already running.
status      Query the current status.
install     Install to start automatically when system boots.
remove      Uninstall.
dump        Request a Java thread dump if running.

That’s a wrap! We’ll next be posting instructions for setting up the Graylog2 web interface for viewing your logs.

Installing MongoDB for Graylog2

We will installing and configuring MongoDB on CentOS 6 as Part 2 of our series on Monitoring your systems with logstash and Graylog2. ::Part 1::Part 3::Part 4::, in order to support our Graylog2 server.

Our goals are simple:

  • Run as an unprivileged user
  • Consistent installation, logging, and configuration locations
  • Ability to scale to securely monitor other remote systems
  • Automating the installation
You may be concerned about the installation of unsigned RPMs onto your system from the 10gen site. It this is the case, you should build from source.

The installation overview:

  1. Add 10gen as a yum repository
  2. Download and install MongoDB
  3. Configure MongoDB
  4. Start MongoDB
  5. Create Admin User
  6. Create Greylog2 database
  7. Create Greylog2 user

We will assume you know the basics of system administration (ie.file permissions, ownership, etc.).
So let’s get this working!

We’ll first configure yum to check the 10gen repository for the lastest MongoDB
We’ll just echo the meager contents to create our file as root.
Below is for x86_64 CentOS

echo "[10gen]
name=10gen Repository
gpgcheck=0" > /etc/yum.repos.d/10gen.repo2

And below would be for the i386 32 bit CentOS

echo "[10gen]
name=10gen Repository
gpgcheck=0" > /etc/yum.repos.d/10gen.repo2

Next we’ll download and install MongoDB using yum, again as root:

yum info mongo*
yum install mongo-10gen*

Next we edit the MongoDB config file “/etc/mongod.conf” with our favorite editor
We want to set the following options

 port = 27017
 auth = true

Now we will create the data directory and set permissions so mongod can write to the database. Again as root:

mkdir -p /var/spool/mongo/data
mkdir -p /var/spool/mongo/log
chown mongod.root /var/spool/mongo/*

Now we’re ready to start MongoDB. As root:

/etc/init.d/mongod start

Our next step is to create our default admin user. As normal user:

~ mongo now changes to a “>” shell prompt
>use admin
>db.addUser('admin', 'secure-password')

We next first authenticate, then create the graylog2 database.

>db.auth('admin', 'secure-password')
>use graylog2

That’s all there is to creating the database. Just too easy!

Next we create the graylog2 user and password for connecting to the database. Note the credentials for configuring the graylog2 server

>db.addUser('gluser', 'grayloguser-password')

We are now finished with configuring MongoDB, I hope it took just a few minutes. If you’d like to read up on MongoDB security, just head on over to the documentation.