http://github.com/DavidS/puppet-nagios

http://mysqldba.blogspot.com/2009/09/nagios-event-handlers-love-them.html

It’ll be interesting to see who gets the position. If he weren’t already busy being chief architect of OSS strategy at BMC, I’d bet that whurley would be a great pick to take on the challenge.

What are your thoughts on this position at Microsoft? I’d love to hear what the Nagios community thinks about it, as Microsoft is certainly a dominant player in the ITOM space, and most admins have to work with MS products alongside their OSS toolbox.

In order to install Nagios on SLES you will need the following RPM packages:

• gd-devel
• libpng-devel
• fontconfig-devel
• freetype2-devel
• apache2
• apache-prefork
• libapr-util1
• libapr1
• apache2-mod_php5
• openssl-devel #if you are installing NRPE
• mcrypt-devel #if you are installing NSCA
• mysql #if you are installing NDOUTILS

All these RPMs are found on the installation media. Having the RPMs on the media will provide consistency throughout your enterprise in regard to server builds. You will also have access to the free version of Xen, which if your enterprise is going green can offset the OS and licensing costs.

Yes, your organization will need to purchase a license for the operating system. A whopping $250 – $300 for licensing and support per server per year. However, that does include a service agreement and free updates. That is a fraction of what other enterprise server operating systems cost and many times a fraction of what the support and licensing fees are for the software running on SLES.

Comments and or Thoughts?

Mike Kniaziewicz, MIS

RedHat package manager is compatible with every flavor of Linux. Ubuntu Linux requires installation of the RPM packages through Synaptic Package Manager. Once the RPM packages are installed, the enterprise now has a method for tracking software packages and versions installed on Linux servers though the RPM database. RPM’s also perform other functions in regard to the SDLC.

The RPM database keeps track of software dependencies. RPM will not allow the administrator to remove a package that other packages are dependent upon. NRPE is dependent upon the Nagios-Plugins package. Trying to remove the Nagios-Plugins package before the NRPE package will result in an error message. Reversing the scenario and trying to install the NRPE package will result in an error message to install the Nagios-Plugins package. Do not “force” the removal of the package or use the option “nodeps” to install the package, the result will be a fragmented package manager database and having to issue a “rebuild” command.

Upgrades are another method RPM incorporates to support the SDLC. RPM will prohibit the installation of a lower or older version of a software package. Say an administrator does not perform a RPM query “rpm -qa” and tries to install nagios-plugins-1.4.12-1.i586.rpm when nagios-plugins-1.4.13-1.i586.rpm is currently installed on the server. The administrator will receive an error message that a newer version is installed along with the version number.

Ease-of-deployment is another aspect of RPM. Administrators can maintain an architecture dependent depository with the Nagios RPMs. Adding the RPMs to any server build instructions or “jumpstart” image means the packages will be deployed when the system is built. Meaning better compliance with adding Nagios monitoring throughout the enterprise. Configuring Nagios on every new server will lead to inconsistency and enterprise failure to monitor critical hosts and services.

My favorite aspect of RPM is the ability to custom create packages for various architectures. The “rpmbuild” feature enables the administrator to create a RPM using existing system libraries. Once the RPM is created it can be deployed on similar architectures throughout the enterprise by anyone having root access. Administrators can also modify the tar file for enterprise requirements, thus maintaining consistent deployment of Nagios across the enterprise.

Nagios needs to adhere to the software development life cycle (SDLC). Every enterprise uses a format of the SDLC. Redhat package manager keeps track of: dependencies, versions and upgrades. RPM also provides deployment ease and consistency across the enterprise with the ability to build architecture specific packages. Nagios administrators are the primary source for moving Nagios into a larger enterprise role. Adhering to the SDLC and using RPMs will ensure the continued growth and success of Nagios.

Mike Kniaziewicz

http://www.unixmen.com/linux-tutorials/285-add-linux-host-to-nagios-server

Here are a few tips for making your notifications impress and convey the message to your recipients:

1. Define objects as fully as possible. As a System Administrator you may know all the systems and what they do for the organization. When you contact another group they may know the server by another name. Take time to define your notes and aliases in both host and service objects.
2. Read about and understand ALL the MACROS provided by Nagios. The MACROS can be found with every installation of Nagios under the Documents section. The MACROS provide a broad range of functionality within Nagios that many developers and System Administrators overlook.
3. Create contact groups and broad contacts. Creating an on-call rotation means identifying individuals. Email contacts means you may have to contact the same individual for multiple, types of problem.
4. Keep your subject short and recipient specific. A Systems Administrator needs to know the host name and problem in the subject. End users need to know their is a problem and how that relates to them.
5. Keep the message body to the point. You do not need to provide a link to acknowledge a problem within the body of the email when you want them to fix the problem immediately.

Here is an example of a notification that my organization sends to end users when an NFS file system is sending a warning or critical alert:

define command{
command_name notify-nfs-service-by-email
command_line /usr/bin/printf “%b” “You have been identified as part of the group that has access to this NFS mount. Please remove any unneeded files in order to reduce the size of this directory.\n\nService:\t\t$SERVICEDESC$\nState:\t\t\t$SERVICESTATE$\nDate/Time:\t\t$LONGDATETIME$\nAdditional Info:\t$SERVICEOUTPUT$ \n\nThis directory may also be known as $SERVICENOTES$” | /usr/bin/mailx -s “$NOTIFICATIONTYPE$:$SERVICESTATE$ – $SERVICEDESC$” $CONTACTEMAIL$ -r core.admin@your domain
}
Remember, when providing notifications keep it simple and to the point. Keeping the message simple means planning ahead and using notes and aliases. To-the-point means content related to the recipient’s need to know. All this begins by using proper design techniques when initially setting up Nagios objects.

Keeping these tips in mind reduced our System Administrator’s email by 70% and we no longer receive email for problems that need to be resolved by other groups, i.e. /oracle file size alerts go the our Database Administrators. We also spend more time implementing system solutions and less time tracking down people to handle problems outside our realm. Why should you be notified about a problem that you need to contact another group to resolve?

Hope these tips make your notification process as robust as my organization’s.
Mike Kniaziewicz, MIS