Building Nagios from sources requires a C compiler, standard C library development files, and the make/imake command. Additionally, development files for OpenSSL should be installed so that network-based plugins will be able to communicate over an SSL layer. MySQL and PostgreSQL development packages should also be installed so that database checks can be run.

First of all, if we're planning to build the Nagios system, a compiler along with several build tools will be required. These are gcc, make, cpp, and binutils. It also needs standard C library development files. All these packages are often already installed, but make sure that they are present as they are needed before compilation.

Nagios by itself does not have a large number of packages that need to be installed on your system in order for it to offer basic functionality. However, if we want to use all the functionalities that Nagios can offer, it is necessary to install additional software.

If we want to use the Nagios web interface, a web server capable of serving CGI scripts is required. Apache web is the recommended and also the most popular web server on a Linux installation. This section, as well as automated scripts describe setting up Apache as the web server, but Nagios should work with any web server supporting CGI and PHP-such as NGINX.

Several of the standard Nagios plugins are written in Perl and will not work if Perl is not installed. Some plugins also need Perl's Net::Snmp package to communicate with devices over the SNMP protocol.

The GD graphics library is also needed for the Nagios web interface to create status map and trends images. We will also install libraries for JPEG and PNG images so that GD can create images in these formats.

All of the packages mentioned earlier are usually installed with many operating systems and most of them are already available for almost any Unix-based platform.

A majority of popular Linux distributions use package managers. There are two popular package formats and package managers:

Fortunately, the list of dependencies is the same for all deb format based distributions. So, to install all of the prerequisites on any recent Ubuntu (such as 12.04, 14.04, or 16.04 LTS editions) or Debian (7 or 8), all that is needed is to run the following commands:

apt-get -y install wget gcc make binutils cpp 
    libpq-dev libmysqlclient-dev 
    libssl1.0.0 libssl-dev pkg-config 
    libgd2-xpm-dev libgd-tools 
    perl libperl-dev libnet-snmp-perl snmp 
    apache2 apache2-utils libapache2-mod-php5 
    unzip tar gzip

This will download all of the tools needed to compile Nagios as well as the Apache 2 web server and the PHP module for serving PHP files, which Nagios requires. Similarly, the package list is also same for all distributions that use the rpm package format. To install all the prerequisites, we need to run the following commands:

yum -y install wget gcc make imake binutils cpp 
    postgresql-devel mysql-libs mysql-devel 
    openssl openssl-devel pkgconfig 
    gd gd-devel gd-progs libpng libpng-devel 
    libjpeg libjpeg-devel perl perl-devel 
    net-snmp net-snmp-devel net-snmp-perl net-snmp-utils 
    httpd php unzip tar gzip

This will install prerequisites as well as the Apache 2 web server and PHP module for serving PHP files.

The first thing that needs to be done is to decide where to install Nagios. For the purpose of this book, we are installing Nagios binaries into the /opt/nagios directory. This is a location for all Nagios binaries, plugins, and additional files.

The Nagios local state data will be stored in the /var/nagios directory. This is where the all statuses and historical data are kept. It can be a part of the Nagios binaries installation directory or a separate directory, as in our case. The Nagios configuration will be put into /etc/nagios. These directories will be created as part of the Nagios installation process.

After we have decided on our directory structure, we need to set up the users and groups for Nagios data. We'll also create a system user and a group named nagios, which will be used by the daemon. We'll also set up the nagioscmd group that can communicate with the daemon. The nagios user will be a member of the nagios and nagioscmd groups. The following commands will create the groups and users:

groupadd nagios
groupadd nagioscmd
useradd -g nagios -G nagioscmd -d /opt/nagios nagios

The Nagios daemon will use a dedicated user and group. This increases security and allows a more flexible setup. Nagios also communicates with external components over a Unix socket. This is a socket that works similar to a file on your filesystem. All commands are passed to Nagios via the pipe; therefore, if you want your processes to be able to send reports or changes to Nagios, you need to make sure that they have access to the socket. One of typical uses for this is that the Nagios web interface needs to be able to send commands to the monitoring process.

In order to properly set up Nagios to use the web interface, it is necessary to determine the user that the web server is running as and add the user that your web server runs as to the nagioscmd group. This will allow the web interface to send commands to Nagios.

The user that the web server is working as is usually www-data, apache, httpd, or daemon. It can be checked with a simple grep command:

root@ubuntu:~# grep -r ^User /etc/apache* /etc/httpd*
/etc/apache2/apache2.conf:User www-data

For our preceding example, we now know that the username is www-data. Sometimes on Ubuntu, the setting is slightly different, as shown in the following command:

root@ubuntu:~# grep -r ^User /etc/apache* /etc/httpd*
/etc/apache2/apache2.conf:User ${APACHE_RUN_USER}

In that case, the value is defined in the /etc/apache2/envvars file:

# grep APACHE_RUN_USER /etc/apache2/envvars
/etc/apache2/envvars:export APACHE_RUN_USER=www-data

In this case as well, the username is www-data.

Now let's add this user to the nagioscmd group using the following command:

usermod -G nagioscmd www-data

The next step is to set up the Nagios destination directories and change their owners accordingly. The following commands will create the directories and change their owner user and group to nagios:

mkdir -p /opt/nagios /etc/nagios /var/nagios
chown nagios:nagios /opt/nagios /etc/nagios /var/nagios

Nagios is an open source application, which means that the source code of all Nagios components is freely available from the Nagios home page:https://www.nagios.org/projects/nagios-core/.

Nagios is distributed under the GNU General Public License (GPL) Version 2 (refer tohttp://www.gnu.org/licenses/old-licenses/gpl-2.0.html for more details), which means that the Nagios source code can be redistributed and modified almost freely under the condition that all changes are also distributed as source code.

Nagios plugins is a project that provides over fifty Nagios plugins that allow monitoring many types of services and devices. They are developed independently of the Nagios service itself and are an open source project using the GNU GPL Version 3 (refer to http://www.gnu.org/licenses/gpl-3.0.html for more details).

We will now create a source directory for compilation. This is where all of our compilation will take place. For the purpose of this book, it will be /usr/src/nagios.

We need to extract our Nagios and standard plugins tarball into this directory using the following commands:

mkdir /usr/src/nagios
tar -xzf /path/to/nagios-4.1.1.tar.gz
tar -xzf /path/to/nagios-plugins-2.1.1.tar.gz

The extraction will create the nagios-4.1.1 and nagios-plugins-2.1.1 sub-directories (or similar ones, depending on your source versions). The /path/to/ path should be replaced with the actual path to where both tarball with source code have been downloaded.

Now let's go to the directory where the Nagios sources are located; in our case it is /usr/src/nagios/nagios-4.1.1. We'll configure Nagios parameters for the directories, we plan to install it by running the configure script. Some of the options that the script accepts are described in the following table:

For the directory structure that was described earlier in this section, the following configure script should be used:

sh configure 
    --prefix=/opt/nagios 
    --sysconfdir=/etc/nagios 
    --localstatedir=/var/nagios 
    --libexecdir=/opt/nagios/plugins 
    --with-command-group=nagioscmd

The script might take time to complete as it will try to guess the configuration of your machine and verify how to build Nagios. If the configure script fails, the most probable reason is that one or more prerequisites are missing. At this point, you will need to analyze which test failed and install or configure additional packages. Most of the times, the output is quite clear, and it is easy to understand what went wrong.

Assuming the configure command worked, we now need to build Nagios. The build process uses the make command, similar to almost all Unix programs. The following commands can be used to build or install Nagios:

First, we'll need to build every module within Nagios. To do this, simply run the following command:

make all

If an error occurs, it is probably due to some header files missing or a development package not being installed. The following is a sample output from a successful Nagios build. It finishes with a friendly message saying that compiling has completed successfully.

cd ./base && make
make[1]: Entering directory '/usr/src/nagios/base'
[...]
*** Compile finished ***
[...]
*************************************************************
Enjoy.

If an error occurs during the build, the information about it is also shown. For example, the following is a sample output from the build:

[...]
In file included from checks.c:40:
../include/config.h:163:18: error: ssl.h: No such file or
directory
[...]
make[1]: *** [checks.o] Error 1
make[1]: Leaving directory '/usr/src/nagios/base'
make: *** [all] Error 2

If this or a similar error occurs, please make sure that you have all the prerequisites mentioned earlier installed. Also, please make sure that you have enough memory and storage space during compilation as this might also cause unexpected crashes during builds.

On Ubuntu systems, it is possible to look for development packages using the apt-cache search command; for example, apt-cache search ssl will find all packages related to OpenSSL. Development packages always have the -dev suffix in their package name; in this case, it would be the libssl-dev package. Combined with the grep command to filter only development packages, for SSL the command would be as follows:

apt-cache search ssl | grep -- -dev

On RedHat Enterprise Linux, CentOS, and Fedora Core, it is possible to look for development packages using the yumsearch command:

yum search ssl | grep -- -devel

Now, we need to install Nagios by running the following commands:

make install
make install-commandmode

For a fresh install, it is recommended that you also install sample configuration files that will be used later for configuring Nagios:

make install-config

At this point, Nagios is installed. It is recommended that you keep all of your Nagios sources as well as prepare dedicated scripts that install Nagios. This is just in case you decide to enable/disable specific options and don't want to guess how exactly Nagios was configured to build the last time it was installed.

The next step is to make sure that Nagios is working properly after being set up. To do this, we can simply run Nagios with the sample configuration that was created by install-config.

We should run it as a nagios user, since the process will be run as normally only as a nagios user. We will use the su command to switch the user and run the Nagios binary with the -v option, which validates the correctness of the configuration file:

# su -c '/opt/nagios/bin/nagios -v /etc/nagios/nagios.cfg'
    nagios
Nagios Core 4.1.1
Copyright (c) 2009-present Nagios Core Development Team and
    Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 08-19-2015
License: GPL
Website: https://www.nagios.org
Reading configuration data...
   Read main config file okay...
   Read object config files okay...
Running pre-flight check on configuration data...
Checking objects...
        Checked 8 services.
        Checked 1 hosts.
        Checked 1 host groups.
        Checked 0 service groups.
        Checked 1 contacts.
        Checked 1 contact groups.
        Checked 24 commands.
        Checked 5 time periods.
        Checked 0 host escalations.
        Checked 0 service escalations.
Checking for circular paths...
        Checked 1 hosts
        Checked 0 service dependencies
        Checked 0 host dependencies
        Checked 5 timeperiods
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors:   0
Things look okay - No serious problems were detected during the
    pre-flight check

In order to compile Nagios plugins manually, first change the working directory to the directory where Nagios plugins source code is located. In our case, it is /usr/src/nagios/nagios-plugins-2.1.1.

We'll configure Nagios plugin parameters for the directories we plan to install it by running the configure script. Some of the options that the script accepts are described in the following table:

The --enable-perl-modules option enables installing additional Perl modules (Nagios::Plugin and its dependencies) that aid in developing your own Nagios plugins in Perl. It is useful to enable this option if you are familiar with Perl.

The --with-pgsql and --with-mysql options allow us to specify locations for the installations of the PostgreSQL and/or MySQL databases. It is used to create plugins for monitoring PostgreSQL and/or MySQL. If not specified, the build process will look for the development files for these databases in their default locations. Installing development files for these databases is described in the Installing prerequisites section. For the directory structure that was described earlier in this section, the following configure script should be used:

sh configure 
    --prefix=/opt/nagios 
    --sysconfdir=/etc/nagios 
    --localstatedir=/var/nagios 
    --libexecdir=/opt/nagios/plugins

The script should run for some time and succeed, assuming that all prerequisites are installed. If not, the script should indicate what the missing component is. The build process also uses the make command similar to how Nagios is compiled. In this case, only all and install targets will be used. Therefore, the next step is to run the make commands shown here:

make all
make install

If any of these steps fail, an investigation into what exactly has failed is needed, and if it is due to a missing library or a development package, install these and try again. If all of the preceding commands succeeded, then you now have a fully installed Nagios and Nagios plugins setup. Congratulations!

The final step is to add the Nagios configuration to the web server. For Debian and Ubuntu, run the following commands to enable CGI and the basic authentication:

a2enmod cgi
a2enmod auth_basic

This will enable the required modules for Apache 2. For other distributions, the CGI and authentication are enabled already, but these are not needed.

First, we need to determine where the configuration should be placed. The Apache configuration directory should be either /etc/apache2 (which is the case for Debian and Ubuntu) or /etc/httpd (for all rpm based distributions).

If the conf-available and conf-enabled sub-directories exist (that is, /etc/apache2/conf-available is a directory), then our configuration file should be placed as /etc/apache2/conf-available/nagios.conf.

If the conf.d directory exists inside the Apache configuration directory (that is, /etc/httpd/conf.d), we can simply place the file as /etc/apache2/conf.d/nagios.conf.

The contents of the file should be as follows:

ScriptAlias /nagios/cgi-bin /opt/nagios/sbin
Alias /nagios /opt/nagios/share
<Location "/nagios">
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios/htpasswd.users
require valid-user
</Location>
<Directory "/opt/nagios/share">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Require all granted
Order allow,deny
Allow from all
</Directory>
<Directory "/opt/nagios/sbin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Require all granted
Order allow,deny
Allow from all
</Directory>

This will make alias to the /nagios URL that will serve the Nagios website. It will also add the /nagios/cgi-bin URL prefix that will be used for CGI scripts. The additional options also ensure that both directories can be accessed as many Linux distributions prevent access to pages outside of the /var/www directory structure completely by default.

If the file was put in the conf-available directory (such as on Debian and Ubuntu Linux distributions), we'll also need to explicitly enable the configuration by running the following command:

a2enconf nagios

This will create a proper symbolic link and ensure that Apache reads the configuration file on next restart.

Finally, we need to create the htpasswd.users file, which should contain the username and hash of the password for the user that will be able to access the UI console.

The username should be nagiosadmin, and the password can be anything. The file can be created by running the following command:

htpasswd -c /etc/nagios/htpasswd.users nagiosadmin

This will prompt for the password for the user. Using nagiosadmin as username is described in more details in Chapter 4, Using the Built-in Web interface.

After that we can restart the Apache web server. Restarting the web server itself varies by Linux distributions, but it should be one of the following commands:

apachectl restart
service apache2 restart
service httpd restart

We can now check that the web interface is available at http://(ip-address)/nagios/, where (ip-address) should be the actual IP address of the machine where Nagios was set up. The page should look similar to the following image:

There might be cases where accessing the Nagios URL shows an error instead of the welcome screen. If this happens it can be due to many things—web server not started, Nagios-related configuration set up incorrectly, or incorrect permissions on directories.

The first thing that we should check is whether Apache is working properly. We can manually run the check_http plugin from Nagios. If the web server is up and running we should see something similar to the following example:

# /opt/nagios/plugins/check_http -H 127.0.0.1
HTTP OK HTTP/1.1 200 OK - 296 bytes in 0.006 seconds

If Apache is not currently running, the plugin will report an error similar to the following one:

# /opt/nagios/plugins/check_http -H 127.0.0.1
HTTP CRITICAL - Unable to open TCP socket

If it was stopped, start it by running one of the following commands, depending on the Linux distribution:

apachectl restart
service apache2 restart
service httpd restart

The next step is to check whether the http://127.0.0.1/nagios/ URL is working properly. We can also use the same plugin for this. The -u argument can specify the exact link to access and -a allows specifying the username and password to authorize. It is passed in the form of <username>:<password>.

# /opt/nagios/plugins/check_http -H 127.0.0.1 

  -u /nagios/ -a nagiosadmin:<yourpassword>
HTTP OK HTTP/1.1 200 OK - 979 bytes in 0.019 seconds 

We can also check actual CGI scripts by passing a URL to one of the scripts:

# /opt/nagios/plugins/check_http -H 127.0.0.1 

  -u /nagios/cgi-bin/tac.cgi -a nagiosadmin:<yourpassword>
HTTP OK HTTP/1.1 200 OK - 979 bytes in 0.019 seconds 

If any of these checks returned any HTTP code other than 200, it means that this is the problem.

If the code is 500, then it means that Apache is not correctly configured. In such cases, the Apache error log contains useful information about any potential problem. On most systems, including Ubuntu Linux, the filename is /var/log/apache2/error.log. An example error log could be:

[error] [client 127.0.0.1] need AuthName:
/nagios/cgibin/tac.cgi

In this particular case, the problem is missing the AuthName directive for CGI scripts.

Internal errors can usually be resolved by making sure that the Nagios-related Apache configuration is correct. If you followed the installation steps from this and the previous chapters, Apache configuration should be exactly the same as in the preceding examples.

If this does not help, it is worth checking other parts of the configuration, especially those related to virtual hosts and CGI configuration. Commenting out parts of the configuration can help to determine which parts of the configuration are causing problems.

Another possibility is that either check whether the /nagios/ or /nagios/cgi-bin/tac.cgi URL returned code 404. This code means that the page was not found. In this case, make sure that Apache is configured according to the previous steps.

Another option for troubleshooting the issue is to enable more verbose debugging to a custom file. The following Apache 2 directives can be added to the nagios.conf configuration file created earlier in the appropriate directories of either /etc/apache2 or /etc/httpd:

LogFormat "%h %l %u "%r" %>s %b %{Host}e %f" debuglog
CustomLog /var/log/apache2/access-debug.log debuglog

The /var/log/apache2 path may also be different depending on the Linux distribution. It is recommended that you check if that directory exists and change it appropriately or use the /var/log directory.

The first entry defines the custom logging format that also logs exact paths to files. The second one enables logging with this format to a dedicated file. An example entry in such a log would be as follows:

127.0.0.1 - - "GET /nagios/ HTTP/1.1" 404 481 127.0.0.1
/var/www/nagios

This log entry tells us that http://127.0.0.1/nagios/ was incorrectly expanded to the /var/www/nagios directory. In this case, the Alias directive describing the /nagios/ prefix is missing. Making sure that the actual configuration matches the one provided in the previous section will also resolve this issue.

Another error that you can get is 403, which indicates that Apache was unable to access either CGI scripts in /opt/nagios/sbin or Nagios static pages in /opt/nagios/share. In this case, you need to make sure that these directories are readable by the user that Apache is running as.

It might also be related to directories above /opt/nagios or /opt. One of these might also be inaccessible to the user that Apache is running as, which will also cause the same error to occur.

If you run into any other problems, then it is best to start by making sure that the Nagios-related configuration matches the examples from the previous section. It is also a good idea to reduce number of enabled features and virtual hosts in your Apache configuration.