BaerConsulting LLC Blog

Virtual Machines are great ways to test something before actually using a physical computer. Programs such as VMWare Workstation ($ – Windows and Linux), VirtualBox (Free – Windows, Mac, Linux), and Parallels ($ – Mac) have been used for years by administrators for running different operating systems under a pre-existing operating system. They function just like a normal program. You double-click on it and you can specify your desired hardware settings even down to the number of CPU cores that you’ll want (keep in mind that the hardware that you plug in should not exceed the hardware of the machine that you’re running the application on), and you can install an operating system within that application just as you would on a regular machine. We here and BaerConsulting love them because if we’re trying something new or untested, we can simply install and configure it within a virtual machine. If there’s a mistake, you can delete the virtual machine or the hard drive file just as you would any other file. Some companies even use these in a production environment. Say you were to have a dual quad core processor, 16GB of RAM, and a 2TB hard drive in a physical computer. You could run a Web Server under Mac OSX (if you can get Mac running in a virtual machine), a Monitoring Server under Windows 2003 Server, a Mail Server under CentOS, a NAS on the actual machine running whatever flavor of OS you prefer, and a PBX Server on Ubuntu, all running on that one physical machine. They would all run flawlessly because of the physical hardware specs you have on the physical machine. It’s a great way to learn Linux without having to clear your drive and dump Windows as well. Linux is free, so is VirtualBox, the only thing you’ll lose is some time and hard drive space.

Oooo such a dirty word. In all actuality, Nagios is only intimidating. Once you find the right walkthrough and decide for or against compiling from source, you’re already through most of the battle. We decided that a free Windows based monitoring system that had device and probe limitations just wasn’t going to cut it anymore. Since we have a very beautiful 5TB total available storage NAS with a dual-core processor and 2GB of RAM sitting there just storing data, we figure we might as well use it for some monitoring. We went through Zabbix and determined that it was going to take longer to get it set up than most of the server would even be in production. Not to mention SNMP based monitoring of system resources can be a security risk as well as difficult to troubleshoot. Nagios has a very comprehensive support base out there. It has been customized and modified to do just about anything that is desired, so we opted for Nagios.

As previously stated, the NAS is a Ubuntu 9.04 desktop with the hardware specs above. Luckily, Nagios and most plugin packages are in the repositories, meaning that can be downloaded and install using your favorite package manager, on Ubuntu, by default, it’s apt. From there, it’s quite simple to figure out how to monitor things. We did print outs of all the commands that were available in the /etc/nagios-plugins directory with (while in /etc/nagios-plugins) ‘cat *.cfg > all.txt’. Marked each one that we’d like to use and started making our host .cfg files. Whenever you make a change to the Nagios configuration files (any of them), you have to restart Nagios for the change to take effect. This is where Nagios can get somewhat tedious. We highly recommend doing one host at a time. Do a few hosts one at a time, restarting after each one. When Nagios catches an error, it won’t restart successfully and it will usually tell you why. Go back in to the config file and make the necessary changes. Once you’ve mastered hosts, you should start adding services to the host files. You can do your file structure however you like. We used one .cfg file for the mail server, one for the web server, so on and so forth. This way, if you take that server out of production, you can just remove the file or move it to another file with another extension. Also, if something goes wrong, you’ll know exactly where to start looking.

Also, there is a Nagios ‘agent’ called NRPE that is used to monitor system resources on the local machine and sends them back to Nagios. The nice thing is that NRPE uses one single port and utilizes SSL so it’s pretty secure. Those commands are defined in the nrpe.cfg file. We have ours running under xinetd which means we can modify commands as much as we want without having to restart NRPE, although you will have to restart Nagios when you add your check_nrpe command. It’s basically a beefier version of SNMP. We’ve only had one hiccup where NRPE failed SSL handshakes for about an hour, but we believe it was due to an NTP misconfiguration. Time is very important when dealing with secure connections. Right now, we’re experimenting with adding some extensive Zimbra monitoring utilizing NRPE. We just altered some perl paths to get Nagios monitoring the postfix mail queue on the Zimbra server, letting us know whenever it reaches a certain point. This tells us that it is possible to do some very interesting things with Nagios. We’ll post the most interesting parts.

We have not and will not post anything pertaining to the actual set up of Nagios such as a walkthrough. Honestly, it took about 15-25 hours to get it successfully monitoring 52 different services, but that includes setting up NSClient++ (basically NRPE for Windows), NRPE on the Mail Server (CentOS) and the Web Server (Ubuntu), importing all publicly available and privately available services such as POP, SMTP, IMAP, HTTP, etc., public IP addresses, private IP addresses, and domains. We went through and used at least a dozen walkthroughs. At some point, we may set up an additional box just to do the walkthrough, but don’t hold your breath. Nagios documentation is pretty thorough. Google NRPE documentation in order to find the best document for the job. It’s posted by Nagios but couldn’t be readily found on the site. Nagios mailing lists are great resources when all else fails. Also, don’t forget your notification profiles. IT IS HIGHLY ADVISED THAT YOU USE THE ‘NEVER’ NOTIFICATION PROFILE OR CREATE ONE IF YOUR SPECIFIC INSTALL DOESN’T HAVE ONE ON EACH AND EVERY HOST/SERVICE UNTIL IT IS UP, RUNNING, AND STABLE. I’D SAY ONCE EVERYTHING IS GREEN, LET IT RUN FOR A WEEK, THEN YOU’LL KNOW YOU CAN TURN ON NOTIFICATIONS. OTHERWISE, YOUR INBOX WILL FILL QUICKLY WHILE YOU WORK OUT THE BUGS.

This weeks tip is about web hosting. When doing any sort of web hosting, it’s important to remember that the web pages themselves are typically compatible with any web server such as Apache, IIS, etc. Some may require plug ins to be compatible with languages such as CGI and PHP but the code can be read by any HTTP server. Our personal preference is Apache2 on either Ubuntu or CentOS with virtual hosting. Our very first blog post was about configuring a virtual host on Ubuntu 8.04 with Apache2. It may take a little bit of configuring and quite a bit of frustration, but once you get all of the tumblers to sit just right, that lock will open up and run for a very long time. Just goes to show you that the simpler router, may not always be what is best in the long run.