Setting up the Web Interface
The Nagios web interface is part of the main Nagios sources and binary distributions. Therefore, if you installed Nagios, you also have the web interface files. The only thing you need now is a web server—in our case, it will be Apache 2 (visit http://httpd.apache.org/).
The web interface uses CGI mechanisms to work, as this is the most-commonly offered way to run applications. It also allows a more flexible set-up in terms of security as CGI binaries can be run as a different user than the one the web server is running as. It also uses additional files such as many static HTML pages, CSS, and images.
As described in the previous chapter, Nagios CGI scripts need to be able to write to the Nagios external command pipe. If you have followed the installation instructions provided in Chapter 2, Installation and Configuration, your Apache server already has the correct access rights. If you set up Nagios on your own, you need to make sure your web server can write to the Nagios pipe. Please check your external command pipe permissions and make sure—for our installation parameters—that the file is called /var/nagios/rw/nagios.cmd, and it is writable by the nagioscmd group. It needs to be writable by the user your web server is running as; so, it is best to add your web server user to a group owning the file.
Configuring the Web Server
By default, all Nagios HTML and other static files that are used by the web interface are copied into the share subdirectory of the Nagios installation, and all CGI binaries go into the sbin subdirectory. Assuming that Nagios has been configured using the default directories used in the previous chapter, these would be /opt/nagios/share and /opt/nagios/sbin respectively.
If you installed Nagios from a binary distribution, it might have configured the web server so that it is accessible. In that case, the package management should have asked you for a password to access the Nagios Web interface. You should start by trying to access http://127.0.0.1/nagios/ from the machine that has Nagios installed. It should prompt you for a username and password. The main Nagios administrator is called nagiosadmin, and the password will be the one you supplied during the package installation. In such a case, you should skip this section and proceed to the next ones that describe how Nagios's web interface works.
If you have followed the steps in the previous chapter to install Nagios, then all that's needed is to configure Apache to use proper aliasing and to create a valid user that will be able to access Nagios.
The following instructions assume that your Apache configuration is under /etc/apache2, and that your web server will read all configuration files under /etc/apache2/conf.d. If your paths are different, please modify them in the following examples, accordingly.
The first thing that we will do is create a configuration file called /etc/apache2/conf.d/nagios.
We will need to add an alias to the /nagios URL that will point to /opt/nagios/share and the CGI scripts under /nagios/cgi-bin URL to /opt/nagios/sbin, as follows:
ScriptAlias /nagios/cgi-bin /opt/nagios/sbin Alias /nagios /opt/nagios/share
Next, we need to set up password protection for the Nagios web interface. We can also limit IP addresses from being able to access the site. To do this, add the following directives to the /etc/apache2/conf.d/nagios file:
<DirectoryMatch /opt/nagios/share>
Options FollowSymLinks
AllowOverride AuthConfig
Order Allow,Deny
Allow From All
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios/htpasswd.users
AuthGroupFile /etc/nagios/htpasswd.groups
require valid-user
</DirectoryMatch>
<DirectoryMatch /opt/nagios/sbin>
Options ExecCGI
AllowOverride AuthConfig
Order Allow,Deny
Allow From All
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios/htpasswd.users
AuthGroupFile /etc/nagios/htpasswd.groups
require valid-user
</DirectoryMatch>
If you want to limit the hosts that will be able to access the Nagios web interface, you can replace the Order and Allow directives in both of the DirectoryMatch definitions as follows:
Order Deny,Allow Deny From All Allow From 192.168.0.0/16
This will only allow access to the Nagios web site from IP addresses starting with 192.168.
The final step is to create the files that will be used for authorization.
We will need to run the following commands to set these up:
# cp /dev/null /etc/nagios/htpasswd.groups # htpasswd -bc /etc/nagios/htpasswd.users nagiosadmin yourpassword Adding password for user nagiosadmin
Make sure you replace yourpassword with the actual password you want to use.
The last thing that needs to be done is to restart Apache by invoking:
/etc/init.d/apache restart
On some operating systems, such as RedHat Linux, this script might be called /etc/rc.d/init.d/httpd or /etc/init.d/httpd.
Accessing the Web Interface
After restarting the web server, we can now access Nagios Web interface by going to URL http://127.0.0.1/nagios/ from that machine. This will prompt for a username and password—these are the ones used in the example above. After a successful login, you should see a welcome screen similar to the following one:
Troubleshooting
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 various reasons, for example, because the web server has not started, or the Nagios related configuration setup is incorrect, or permissions on the Nagios directories are incorrect.
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 what is shown here:
# /opt/nagios/plugins/check_http -H 127.0.0.1
HTTP OK HTTP/1.1 200 OK - 296 bytes in 0.006 seconds
and if Apache is not running currently, 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 /etc/init.d/apache2 start.
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 you to specify the username and password to be authorized. 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 the 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 return any HTTP code other than 200, it means that this is the problem.
If the code is 500, it means that Apache is not configured correctly. In such cases, the Apache error log contains useful information about any potential problems. On most systems, including Ubuntu Linux, the file name of the log is /var/log/apache2/error.log. An example entry in the error log could be:
[error] [client 127.0.0.1] need AuthName: /nagios/cgi-bin/tac.cgi
In this particular case, the problem is the missing 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 chapter and the previous one, Apache configuration should be exactly the same as in the examples above.
If this does not help, it is worth checking other parts of the configuration, especially the ones related to virtual hosts and CGI configuration. Commenting out parts of the configuration can help in determining which parts of the configuration are causing problems.
Another possibility is that either the check for /nagios/ or the check for the /nagios/cgi-bin/tac.cgi URL returned code 404. This code means that the page was not found. In this case, please make sure that Apache is configured according to the previous steps.
If it is, then it's a good idea to enable more verbose debugging to a custom file. The following Apache 2 directives can be added either to /etc/apache2/conf.d/nagios or to any other file in Apache configuration:
LogFormat "%h %l %u \"%r\" %>s %b %{Host}e %f" debuglog
CustomLog /var/log/apache2/access-debug.log debuglog
The first entry defines a 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:
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 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 Apache is running as.
The error might also be related to the directories above—/opt/nagios or /opt. One of these might also be inaccessible to the user Apache is running as, which will also cause the same error to occur.
If you run into any other problems, it is best to start with making sure that Nagios related configuration matches the examples from the previous section. It is also a good idea to reduce the number of enabled features and virtual hosts in your Apache configuration.