Volume Number: 21 (2005)
Issue Number: 12
Column Tag: Programming

Patch Panel

Nagios on OS X, Part 1

by John C. Welch

Installing and Setting Up One of the Best Net Monitoring Tools Around

If you read my website, http://www.bynkii.com/, you may know I have talked about installing Nagios in the past. For a while now I've wanted to write an updated, in-depth piece on this subject, and felt now was time to do so, and of course, only in MacTech! I've managed to simplify the install quite a bit, thanks to the hard work of the folks at DarwinPorts, http://darwinports.org.

Welcome

This article is going to have a few sections. First, we'll get DarwinPorts installed and configured. Then we'll use it to install the backend components Nagios needs. Third, we'll do the actual Nagios installation, and the plugin installation. Then we'll go over some of the basics of configuring Nagios. Note that this applies to the current version, which is 1.2. Version 2.0 is in final beta, but I prefer to wait until that's done before installing it on production systems

We should also talk a bit about what Nagios is. Nagios is a network monitoring tool. It allows you to monitor services running on various hosts on your network. For example, you can monitor your switches to ensure they're working, or you can monitor various critical server processes on an Xserve, like the KDC process, AFP processes, etc. You can, with various plugins from the Nagios Exchange site, at http://www.nagiosexchange.org/ monitor internal counters on Windows servers too. If you're skilled with Perl, or any one of dozens of programming languages, you can write your own plugins.

Darwinports

DarwinPorts, like Fink, or any other of a dozen ports management systems is a way to make installing and configuring software easier. If you compile and install open source software manually, you have to figure out all the various dependencies and configuration issues yourself. This is not hard per se, but it is tedious. Ports managers, like DarwinPorts manage this for you. If the DarwinPorts repository has the software you want, you install it, and it handles all the dependencies for you. While, like everything else, there is any number of religious wars about ports systems, I like DarwinPorts, because it does the job well for me. If you like Fink better, great! They're both really good systems.

To avoid modifying Apple-supplied directories, DarwinPorts lives in /opt/local/. If you install on Mac OS X Server, then you'll already have/opt: it's where Apache2 is installed. The advantage to this is that it makes uninstalling DarwinPorts dead simple. Remove /opt/local and all its contents, and DarwinPorts is gone.

Since DarwinPorts doesn't have a Nagios port, we can't just use it for the full install, but we can use it, and some other tools for the support libraries and applications Nagios needs. However, the first thing we have to do is install DarwinPorts itself. The easiest way to do this is to get the disk image with the installer from DarwinPorts, currently at http://darwinports.org/downloads/DarwinPorts-1.1.dmg. Download the disk image, and run the installer. Once you're done with that, we're going to be doing the rest of our work in Terminal.

To make life simpler, we're going to set up a .profile in our home directory that will make using DarwinPorts easier. While you don't have to do this, if you have multiple versions of software installed in various places, a .profile file will make your life a lot simpler. My .profile is a bit simplistic, but it works for my needs. In any text editor that will allow you to create .files, (pico, vi, emacs, TextWrangler, SubEthaEdit, BBEdit, they're all good) create a file with the following entries, and save it in the root of your home directory as .profile:

PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/share/aclocal:/opt/
   local:/opt/local/bin:/opt/local/lib:/opt/local/sbin"

export PATH

PKG_CONFIG_PATH="/opt/local/lib/pkgconfig"

export PKG_CONFIG_PATH

MANPATH="/usr/share/man/:/usr/X11R6/man/:/opt/local/share/man"
export MANPATH

INFOPATH="/opt/local/share/info"

The path statement ensures that when you enter a command, that the /opt/local tree is used automatically. It also leaves the standard paths for /bin, /sbin, /usr/bin, /usr/sbin, etc. The PKG_CONFIG_PATH is used to ensure that software you install under your login can find pkg-config, a tool used to make compiling libraries and applications easier. The MANPATH statement makes finding man pages in the /opt/local/ tree easier. The INFOPATH variable is used by things like gettext, which figures into a lot of open source packages. If you already have your own .profile, then just add the /opt/local information if you wish. I rely heavily on DarwinPorts, so for me, having this .profile setup is a real timesaver. If you don't use DarwinPorts a lot, you may not wish to modify your .profile.

So, once you're done setting up, (or not) your .profile, we're ready to go. If you did modify your .profile from within the Terminal, you'll want to read that file so your environment is set up. Just run

source ~/.profile

to set up your environment with the new information from .profile. Now we need to make sure DarwinPorts is up to date. To do this, run:

sudo port selfupdate

and wait a few minutes. If there is any updating to do, you'll see some short status messages on the screen, and if all goes well, you'll get the "selfupdate done!" message, and you're set. If you want to see all the status messages for a selfupdate, then run:

sudo port -d selfupdate

which enables debug mode for that command, you'll get all the status messages. Below, I have the two screenshots for the same command on an updated system to give you an idea of the difference the -d makes.

I tend to only use the -d option if I'm having problems, so I can better see where the problem is occurring. I like to run the selfupdate option at the beginning of any install session, so I know I'm starting with the most current version of DarwinPorts.

Once that's done, we install the various background libraries that Nagios needs using DarwinPorts and the install switch:

sudo port install zlib
sudo port install libpng
sudo port install jpeg
sudo port install gd2

Once all of those are done, congrats, you've installed the support libraries for Nagios. Note that there are tons of ports in DarwinPorts, so this is only the barest smidgen of what you can get with DarwinPorts.

We'll need to install at least one particular Perl package for Nagios, namely Net::SNMP. To do this, run:

sudo cpan -i Net::SNMP

If you've never run cpan before, you'll have to run through some configuration steps first. They're pretty easy to follow, and if you're unsure of what to do in a given step, take the defaults. There's even an option to let cpan try to autoconfigure itself. I do it manually, but if autoconfigure works for you, so much the better. Using cpan is much like using DarwinPorts, only just for Perl. If you're trying to install a Perl module that has dependencies that you don't have installed, cpan will prompt you to install those as well. (If you've only ever hear horror stories about downloading and installing open source software, I'm here to tell you that thanks to a lot of hard work by not a lot of people, that process has gotten much easier, and thanks to tools like cpan and DarwinPorts, should no longer be thought of as scary to the uninitiated.)

Installing Nagios

Now that we have the support libraries installed, it's time to set up for Nagios. We'll need to create the directory that Nagios lives in, /usr/local/Nagios. Next we have to create the users and groups that Nagios will use. (Security note: All of this assumes that you have a proper firewall and other protective measures in place. I would highly recommend that you don't install Nagios on a system directly exposed to the public Internet. A lot of the protocols that Nagios uses, like SNMP v2c are not encrypted or terribly secure, and having a Nagios box exposed to the public Internet will potentially create real problems for you. )

You'll need to create at least a Nagios user and a Nagios group. Note that the nagios user does not need a login shell, just that the account works. Regardless of how you create the nagios user account, (System Preferences, NetInfo Manager, Workgroup Manager, command line), you want to make it a local machine account only, and you want to set the login shell to /usr/bin/false. Don't give the account a password. You'll also need to create a nagios group. The Nagios group needs two members, nagios and www. (Adding www to the nagios group makes setting up the integration between Apache and Nagios much easier.) Once you've created the user and group for Nagios, then we're ready to download the Nagios source code files.

Go to the Nagios download site, http://www.nagios.org/download/, and download the 1.2 version of the Nagios tarball, and the most recent version of the Nagios plugin tarball, 1.4.2 as of this writing. Save them both to whereever you want, I ususally save them to my desktop. Unzip and untar the Nagios source code files. In the Terminal, cd to the nagios-1.2 directory. The first thing we have to do is run the configure utility so that we can compile and build the code correctly. As we're using some non-standard (for Nagios) library locations, we'll need to tell it where to find things. We also need tell Nagios where its own base directory is going to be, where the CGI directory it will use is going to be, and where the base web root directory it's going to use is. For this article, I'm using:

./configure --with-gd-lib=/opt/local/lib --with-gd-inc=/opt/local
   /include --prefix=/usr/local/nagios --with-cgiurl=/cgi-bin --with-htmlurl=/

Make sure you don't have any spaces between the = and the leading / of the paths in the configure command, and let it rip. When you get done, you should not have seen any warning s or errors during the configure, and you should see a status screen like the one below:

You'll want to save this screen somewhere, in case you aren't sure where things are. With this setting, Nagios is going to use the defaults for things, so we'll have to change a few things. First, it assumes that you're going to have all your web files originating from /nagios in the URLs. We'll fix that later. The cgi-bin directory is the system default one, or /Library/WebServer/CGI-Executables. That we'll leave alone.

Assuming your configure went okay, we're going to run the various Nagios make and install commands:

make all

If make all completes successfully, you'll see a status screen like the one below. We're going to run the other make commands with the exception of make install-init, since Mac OS X doesn't handle startup items like that, and we'll want to test a bit before we make Nagios a startup item.

sudo make install

If the make install goes well, you'll get another status screen telling you so.

sudo make install -commandmode

This command sets up the external command directory for you, important if you want to extend Nagios beyond the basics

sudo make install-config

This sets up the sample configuration files, which we'll go into later. Next is to configure and install the plugins. As with Nagios, unzip and untar the source files for the Nagios plugins. Change directory into the nagios-plugins directory and run ./configure. If there are no errors, run make, then sudo make install.

Initial Post - Install Setup

So Nagios is installed, the plugins are installed, we just start and go, right? Well, not so fast. First, we have to make sure that the web server side of things is set, since Nagios uses a web interface to show you what its monitoring. If you installed Nagios on Mac OS X Server, then you just use Server Admin to point the web server root at /usr/local/nagios/share. You'll want to make sure you have CGI Execution enabled for the site, and that you have the necessary Apache modules enabled to allow you to run Perl and other language CGIs on the site. If you are using Mac OS X instead of Mac OS X Server, you'll have to edit the necessary Apache config files by hand to do this. Oh yes, make sure that evil Performance Cache is turned off.

Next, we copy the Nagios CGIs into /Library/WebServer/CGI-Executables/. The CGIs can be found in /usr/local/nagios/sbin. You want to make sure that at least the group for the CGIs is set to www, and that the permissions are set so that the owner and group can execute. (I'll leave world executable rights up to your particular needs and security posture).

The next step is to ensure that Nagios knows where its various web files really are. To do this, we want to open up side.html in /usr/local/nagios/share, and make sure that all the references to CGIs look like this: href="/cgi-bin/statuswrl.cgi If they do, then you're all set there.

If you've got everything pointed right, then we can test the basic operation, aka "can we see the Nagios Home Page". Just point your browser at the Nagios URL, and if it's all set up correctly, you'll see:

Note that nothing works yet, and in fact, the Nagios process isn't even running. But at least we know it can see the home page. So that's something. Next we want to make sure that just anyone cannot see all the information that Nagios can provide. If nothing else, you don't want the entire world, or even your entire company, getting detailed information on your servers.

There are a lot of ways to set up access control to web sites. I'm covering one here, namely using .htaccess files. To do this, we're going to make a couple of changes to httpd.conf, and set up a .htaccess file for locking down access.

httpd.conf changes:

Note: This a fairly simple way to set this up. There are other ways to do the same thing, and they will work just as well. This one works in my situation.

?Open /etc/httpd/httpd.conf in your text editor of choice (I use BBEdit) and look for the following directive:

<Directory "/Library/WebServer/CGI-Executables">
   AllowOverride None?
   Options None?
   Options ExecCGI
   Order allow,deny
   Allow from all
</Directory>
and change it to read:
<Directory "/Library/WebServer/CGI-Executables
   #AllowOverride None
   AllowOverride AuthConfig
   # Options None
   Options ExecCGI
   Order allow,deny
   Allow from all
</Directory>

This will allow you to run the CGI's after you have authenticated yourself for the CGIs. To do that, we need to set up a .htaccess file in the cgi-bin directory, and then set up the passwords. Create a file named .htaccess in /Library/WebServer/CGI-Executables/ and set it up thusly:

AuthName "Nagios Access"?
AuthType Basic?
AuthUserFile /usr/local/nagios/etc/htpasswd.users
?require valid-user

Once you've done that save it and close it. Now, before we create the password file for this, you want to know all the users that will be authenticating. At the very least, you want some sort of catchall Nagios admin user. For our example, we used nagiosadmin, jwelch, and admin

Run the following:

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

This will create the user file that our .htaccess file is looking for, and set the first user to nagiosadmin. You'll be asked for the password for this user, set it to what you feel is correct.

To add other users, you run:

sudo htpasswd /usr/local/nagios/etc/htpasswd.users <username>

You do this once for each user you want to add. You only need the -c swtich when you are creating the file and first entry.

Then, edit the "use_authentication" line in /usr/local/nagios/etc/cgi.cfg (or cgi.cfg-sample) to read:

use_authentication=1

If you read that file, you'll also note this is where you set which nagios user can do what. The docs that are a part of Nagios explain this thoroughly, and are available from the "Documentation" link on your Nagios home page, so I don't have to.

Conclusion

I want to stop the article here, because the next part is going to go into the configuration files, which covers a lot of detail, and can be pretty dry. Unfortunately, there's no nice or easy way to jump in to that. I highly encourage anyone who wants to go ahead on their own to do so, but with caution, the config files can get a little odd at times. I'd also encourage any readers who are not going to plow ahead to read the Nagios documentation thoroughly. Nagios has its own language, and the more familiar you are with it, the happier you'll be using it. As always, thanks for reading!

Bibliography and References

DarwinPorts, http://darwinports.org.

CPAN, the Comprehensive Perl Archive Network, http://www.cpan.org/

Nagios, http://www.nagios.org/

Nagios Exchange, the Nagios Plugins and Add Ons Exchange, http://www.nagiosexchange.org/

John Welch jwelch@bynkii.com is Unix/Open Systems administrator for Kansas City Life Insurance, (http://www.kclife.com/) a Technical Strategist for Provar, (http://www.provar.com/) and the "GeekSpeak" segment producer for Your Mac Life, (http://www.yourmaclife.com/). He has over fifteen years of experience at making Macs work with other computer systems. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.