I decided to write an article on installing it onto an Arch Linux distribution, as that’s what I run as a server instance at home. You can install Nagios on a physical system or virtual machine; there’s no limitations there. The reason I wanted to focus on the Arch Linux distribution was due to the fact that there is no much information on installing Nagios on Arch Linux; the main Arch Linux Wiki has an article on it, though.

Getting Started

So, the first thing to do, is make sure you have all the dependencies. You can tell Arch Linux to install a series of packages and it is smart enough to know what’s already installed and needs updating, so the following is just to outline the main requirements for Nagios. Technically, the only requirement is a C compiler, but it’s not entirely useful, unless you just want a command line version of Nagios (which is completely legit, but having a web interface, for me, is always a plus).
Dependencies:

• Apache
• PHP
• GCC compiler
• GD development libraries

Installing Dependencies

Like I stated before, Arch Linux makes it simple to install packages, so, all you have to do is run a single command and you will be able to install all the required dependencies:

pacman -S apache php-apache gcc php-gd

This will download the required dependencies for Nagios, but also will have several dependencies of their own, and Arch Linux will handle all of this for you.

Installing Nagios Core

Nagios Core is one of the easiest configure, compile, and install application I’ve ever dealt with, so this step-by-step documentation should get you set up pretty quick.

Setting Up Users/Groups

Let’s add the nagio user and give it a password.

useradd -m nagios
passwd nagios
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Now, we need to add the Nagios command group:

groupadd nagcmd

Finally, we just add the nagcmd and http (Apache user) groups to the nagios user.

usermod -a -G nagcmd nagios
usermod -a -G nagcmd http

Download and Extract Nagios

At the time of this writing, go here and download both the Nagios Core (3.3.1) and Nagios Plugins (1.4.15) compressed files. At this time, the direct downloads are:

• Nagios Core
• Nagios Plugins

You could easily use wget to download the files, as I did.

wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.3.1.tar.gz
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz

Okay, we are now ready to extract both; we only need Nagios Core right now, but let’s extract both so that we don’t have to mess with doing that later. I’ll assume that the files are in /root/Downloads.

cd /root/Downloads
tar -xzvf ./nagios-3.3.1.tar.gz
tar -xzvf ./nagios-plugins-1.4.15.tar.gz

You should have two directories (something similar to the following): nagios-3.3.1 and nagios-plugins-1.4.15.

Run Nagios configure Script

Now it’s time to get down to the actual configure/compile/install part. Before, we can install, or even compiling Nagios, we have to run the configure script with some very important flags set. Note: Nagios’ default prefix is /usr/local/nagios; if this is an issue, you need to also set the prefix by --prefix=/your/desired/prefix

cd /root/Downloads/nagios-3.3.1/
./configure --with-command-group=nagcmd --with-httpd-conf=/etc/httpd/conf/extra

Once this completes and everything looks good, go ahead and compile the source

make all

The moment you’ve been waiting for, now let’s actually install Nagios.

make install
make install-init
make install-config
make install-commandmode
make install-webconf

Let’s discuss what each one does:

• install installs the Nagios Core base
• install-init installs the init script (/etc/rc.d/)
• install-config installs some sample configuration files so you can start with something
• install-commandmode installs/configures the correct permissions on the directory holding the external command file
• install-webconf installs the Apache configuration files in the directory you provided the configure script, in this case, /etc/httpd/conf/extra/

Create nagiosadmin User

Now we need to create a user that has permissions to manage the Nagios system. As a whole, Nagios is open, there is no authentication in Nagios Core, so the way to “protect” Nagios, is to just set up a user/password via htaccess. I’m using nagiosadmin since that’s been the adopted user for as long as I’ve used Nagios.

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
New password: 
Re-type new password: 
Adding password for user nagiosadmin

Configure Apache

We have to configure Apache to use the configuration file placed in /etc/httpd/conf/extras/, which is how Arch Linux sets up its base httpd.conf file. Towards the bottom of the /etc/httpd/conf/httpd.conf file, you will see a few Include sections. After the last Include sections add the following:

# Nagios
Include conf/extra/nagios.conf

Configure PHP

Next we have to make a few modifications to PHP in order to get things to work, in the long run. Based off this installation of Nagios, the Nagios web files are in /usr/local/nagios/share/. The problem is, by default, PHP is configured to use the open_basedir, which is a security mechanism. You can either disable it (comment it out) or you can just add /usr/local/nagios/share/ to open_basedir, which is what I recommend. Your open_basedir should look something similar to:

open_basedir = /srv/http/:/usr/local/nagios/share/:/home/:/tmp/:/usr/share/pear/

The last thing you have to do with PHP is enable the GD extension that you installed as a pre-requisite, earlier (it is more towards the bottom):

extension=gd.so

Restart Apache

Easy, peasy – just restart Apache so that your Apache and PHP configuration are reflected.

/etc/rc.d/httpd restart

Install Nagios Plugins

Now, let’s install the Nagios Plugins. You’ll need to go into the directory you extracted, when you extracted that archive for the Nagios Plugins. From there, you just need to run the configure script with the appropriate flags.

cd /root/Downloads/nagios-plugins-1.4.15/
./configure --with-nagios-user=nagios --with-nagios-group=nagios

Next compile the source code for Nagios Plugins:

make

Finally, install Nagios Plugins:

make install

Update /etc/rc.conf (bootup items)

To finish up, you will need to make sure that Nagios starts up upon a reboot, so you will need to add nagios to the DAEMONS section of /etc/rc/conf.

Start Nagios

Now you can go ahead and start up Nagios. All the configuration files are in /usr/local/nagios/etc and the templates and host-based configuration files are in /usr/local/nagios/etc/objects/. From here you can start configuring all that. Just remember, after you update a configuration item, you’ll need to restart Nagios.

/etc/rc.d/nagios

Reproducing The Issue

To reproduce the issue, all you need to do is open Activity Monitor and make note of your Dock application. Is it spiking around the 100% mark? You should see something like the following:

Steps To Resolve The Issue

To resolve this issue, the following steps will have to be taken:

• Remove the Windows Applications folder from the Dock application
• Kill the Dock application
• Verify the Dock application is functioning normally

Very simple set of steps that takes longer to document and explain than to actually fix!

Dock: Windows Application Folder

Dock: Remove Windows Application Folder From The Dock

Dock: Windows Application Folder Removed From The Dock

Kill The Current Dock Application

Confirm Quit (Kill) of Dock Application

Confirm CPU Usage Has Subsided

Proof.

So, just to prove how much of an impact this was, my battery life went from about 2:24 battery (remaining) to 8:33 battery (remaining).

Before

After

Placing the MySQL system into read-only mode is very quick and easy:

Login:

mysql -u root -p

Note: This requires the SUPER MySQL privilege.

Enable Read-Only Mode:

mysql> set GLOBAL read_only = true;

That’s it! I’m sure you’ll need to know how to disable read-only mode and let users write back to the database, so in order to do that, do the following:

Re-enable Read/Write Mode:

mysql> set GLOBAL read_only = false;

I ran into an Ubuntu-specific issue where the configuration default was set to not run the PHP engine for the user directories (/home/*/public_html). When I say Ubuntu-specific, that doesn’t mean that this only happens with Ubuntu, however, Ubuntu tends to add defaults into the system when packages are installed so that the end-user just has to enable these modules. The setting in general was the php_admin_value engine option. This was, by default, set to Off. All I did to fix this was remove it entirely from the configuration file.

Before:

<IfModule mod_userdir.c>
    <Directory /home/*/public_html>
        php_admin_value engine Off
    </Directory>
</IfModule>

After:

<IfModule mod_userdir.c>
    <Directory /home/*/public_html>
 
    </Directory>
</IfModule>

You will need to restart Apache in order for these changes to take effect:

sudo /etc/init.d/apache2 restart

The syntax of the command goes zip [switches] zipped-up-filename.zip [files or directory]. The command is very simple, although, it took me a second to figure out to correct syntax to getting the command to zip up a folder recursively.

Zipping Up a File

[root@server]# zip zipped-up-filename.zip file1.txt

Zipping Up More Than One File

[root@server]# zip zipped-up-filename.zip file1.txt file2.txt file3.log file4.inc

Zipping Up A Subdirectory (and its subdirectories)

[root@server]# zip -r zipped-up-filename.zip folder-to-be-zipped/

Zipping Up the Current Directory (and its subdirectories)

This one’s similar, but a bit different, from the previous command:

[root@server]# zip -r zipped-up-filename.zip .

Hope this helps with getting used to (hopefully you don’t get used to this command to much) the zip command; comes in very useful when you least expect it.

First, let’s see if the terminal can fix itself. Check to see how many columns your terminal is set to:

[root@server:~]# stty -a |  awk '/columns/ { print $6 }' 
127

Now, resize your window on your SSH session. Then re-run the command:

[root@server:~]# stty -a |  awk '/columns/ { print $6 }'
207

If the value changed, you should be good, however, if it did not change you will have to manually change it to something bigger. This value is up to you. To change the value, issue the following command:

[root@server:~]# stty cols 207     # Where 207 is the number of columns set
# nothing should be returned
 
# Now verify the setting took affect
[root@server:~]# stty -a |  awk '/columns/ { print $6 }'
207    # Sample output

error_reporting(E_ALL); 
ini_set("display_errors", "1");

Easy as that, and now you have PHP errors now displaying for this application, but nothing else (such as production code) will display errors.

On Linux, it’s pretty simple (md5sum), however, on Solaris, it’s a totally different set of commands – and on top of that – Solaris 9 and 10 are totally different. First thing though, my disclaimer is, I’m using stock Solaris 9 and 10 machines and I am well aware that I could install md5sum and/or the Solaris 10 equivalent onto the Solaris 9 machine, however I assume that you cannot just install software without proper change management schedules.

Solaris 9

## Full Format
[root@server:~]# cksum /dev/null
4294967295      0       /dev/null
 
## Only display the checksum
[root@server:~]# cksum /dev/null | cut -f1
4294967295

Solaris 10

cksum

## Full Format
[root@server:~]# cksum /dev/null
4294967295      0       /dev/null
 
## Only display the checksum
[root@server:~]# cksum /dev/null | cut -f1
4294967295

digest

## Full Format - MD5
[root@server:~]# digest -v -a md5 /dev/null 
md5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e
 
## Full Format - SHA1
[root@server:~]# digest -v -a sha1 /dev/null     
sha1 (/dev/null) = da39a3ee5e6b4b0d3255bfef95601890afd80709
 
## Full Format - SHA256
[root@server:~]# digest -v -a sha256 /dev/null   
sha256 (/dev/null) = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
 
## Full Format - SHA512
[root@server:~]# digest -v -a sha512 /dev/null 
sha512 (/dev/null) = cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
 
## Only display the checksum - MD5
[root@server:~]# digest -a md5 /dev/null          
d41d8cd98f00b204e9800998ecf8427e
 
## Only display the checksum - SHA1
[root@server:~]# digest -a sha1 /dev/null    
da39a3ee5e6b4b0d3255bfef95601890afd80709
 
## Only display the checksum - SHA256
[root@server:~]# digest -a sha256 /dev/null  
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
 
## Only display the checksum - SHA512
[root@server:~]# digest -a sha512 /dev/null    
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e

For comparing files, I usually just use mksum or MD5 algorithm.

gem install localgem.gem

It’s as easy as that. I needed to install a gem locally due to a bug causing my remote gem install to fail.