This is the frequently asked questions
General questions about this project
The Nagios Plugins is currently distributed using the GNU General Public License version 2.
There is a task to convert the project to be under GPLv3. This is because some C code that we depend upon, from the GNUlib project, is under GPLv3 and therefore some of our C plugins also need to be GPLv3.
So the team has decided rather than having a mixed license, we'll distribute the core Nagios Plugins code as GPLv3.
This page will be updated when this has been completed.
Currently, the copyrights for individual files and plugins are mixed. Sometimes, they are copyrighted to the individual that originally wrote the plugin, though any new changes are copyrighted by the Nagios Plugin Development Team (as listed on Sourceforge).
All code is released under the GPLv2.
There is a task to ensure all code is owned (solely or dual copyright) to the Nagios Plugins Development Team, to avoid confusion about ownership in future. This page will be updated to reflect when this has been completed.
Of course you can! This is an open source project!
Ideally, raise a tracker item in Sourceforge, so your patch doesn't get lost. Then chase up via the nagiosplug-devel mailing list, if nothing happens. But be aware, this project is run by volunteers, so there is not necessarily immediate response!
By submitting a patch, you are stating that:
If you disagree with handing over copyright, it maybe possible to dual copyright your change - please ask on the nagiosplug-devel mailing list.
We require the copyright ownership for legal reasons.
If your patch is accepted, we will:
To compile the plugins, you run:
gunzip -c nagios-plugins-1.4.10.tar.gz | tar -xf -
cd nagios-plugins-1.4.10
./configure
make
If you find that the configure script appears to hang on this line:
checking for redhat spopen problem...
Then you probably have a badly configured DNS server. This part of configure is testing for a pthread problem in Bind that is a kernel problem on some Red Hat derived versions of Linux (around kernel 2.6.9-11). It runs 10 x 100 nslookup calls to see if your kernel has this problem. If it does, then at least 1 of those calls will fail. Failure rate could be anywhere between 1% and 50%.
To force the workaround and ignore the test, run ./configure with the --enable-redhat-pthread-workaround switch.
You can run ./configure with --disable-redhat-pthread to ignore this test.
Due to a bug in the 1.4.7 and 1.4.8 releases, check_ldap, check_radius and check_pgsql won''t compile if MySQL libs are present even if configure output says the required libraries are present. This is fixed in 1.4.9
Here's the easiest way to compile and install these plugins:
To get the SSL features, you need to have the SSL libraries available. Either OpenSSL or GNUTLS is suitable.
Check the ./configure output to see if the SSL libraries have been detected.
This is currently an optional setting at configure time. You need to run:
./configure --enable-perl-modules
Then, make, make install, make test, and make clean, will include the perl modules that are in the perlmods/ directory as expected.
The perl modules are installed into $prefix/perl.
This is a known problem with the Nagios::Plugin perl module: http://rt.cpan.org//Ticket/Display.html?id=29339.
However, it is now fixed in Nagios::Plugin 0.21, which is distributed with Nagios Plugins 1.4.10.
make install
There are a few plugins which require root access. These are compiled under the plugins-root subdirectory. A make install will install it with the install user's owner and group permissions. However, if you run make install without root, this message will appear:
WARNING: insufficient access; not installing setuid plugins
NOTE: to install setuid plugins, run 'make install-root' as root"
To install, run as root:
make install-root
Even if you are not root, the plugins will still be installed. This is for packagers which can then alter the permissions of the plugins before packaging.
This behaviour is used by coreutils for the su binary and is duplicated for this project.
If you run ./configure with --with-user=nagios, then at make install time, the installation will set the ownership of the plugins to the nagios user (similarly for --with-group). If these options are not set, the plugins will be installed with the install user's owner and group permissions - it is your responsibility to set other permissions, if required.
The only exception are root plugins. These are under plugins-root/ and are also installed with the install user's owner and group permissions.
If you run:
make install-root
This will set permissions to root, assuming you are either root or using fakeroot. If not, the setuid is still set, but the plugin may not work correctly. This is the behaviour used by coreutils for the su binary and is duplicated in this project.
There are two types of plugins included in the distribution:
Sooner or later all the contrib plugins should be hosted at the official 3rd Party Nagios plugin page www.NagiosExchange.org
Contrib plugins have to be installed manually. They are not affected by the build process.
Here is a list of the actively maintained Plugins:
check_apt, check_breeze, check_by_ssh, check_clamd, check_cluster, check_dhcp, check_dig, check_disk, check_disk_smb, check_dns, check_dummy, check_file_age, check_flexlm, check_fping, check_ftp, check_game, check_hpjd, check_http, check_icmp, check_ide_smart, check_ifoperstatus, check_ifstatus, check_imap, check_ircd, check_jabber, check_ldap, check_load, check_log, check_mailq, check_mrtg, check_mrtgtraf, check_mssql, check_mysql, check_mysql_query, check_nagios, check_netdns, check_nntp, check_nntps, check_nt, check_ntp_peer, check_ntp_time, check_nwstat, check_oracle, check_overcr, check_pgsql, check_ping, check_pop, check_procs, check_radius, check_real, check_rpc, check_sensors, check_simap, check_smtp, check_snmp, check_spop, check_ssh, check_ssmtp, check_swap, check_tcp, check_time, check_udp, check_ups, check_users, check_wave
And these plugins are currently distributed in the contrib directory:
check_adptraid, check_apache, check_apc_ups, check_appletalk, check_arping, check_asterisk, check_axis, check_backup, check_bgpstate, check_breeze, check_cluster, check_cluster2, check_compaq_insight, check_cpqarray, check_digitemp, check_dlswcircuit, check_dns_random, check_email_loop, check_fan_cpq_present, check_fan_fsc_present, check_flexlm, check_frontpage, check_hltherm, check_hprsc, check_http-with-client-certificate, check_hw, check_ica_master_browser, check_ica_metaframe_pub_apps, check_ica_program_neigbourhood, check_inodes, check_inodes-freebsd, check_ipxping, check_javaproc, check_joy, check_linux_raid, check_lmmon, check_log2, check_lotus, check_maxchannels, check_maxwanstate, check_mem, check_ms_spooler, check_mssql, check_nagios, check_nagios_db, check_nagios_db_pg, check_netapp, check_nmap, check_oracle_instance, check_oracle_tbs, check_ora_table_space, check_pcpmetric, check_pfstate, check_qmailq, check_rbl, check_remote_nagios_status, check_rrd_data, check_sap, check_smart, check_smb, check_snmp_disk_monitor, check_snmp_printer, check_snmp_process_monitor, check_snmp_procs, check_sockets, check_temp_cpq, check_temp_fsc, check_timeout, check_traceroute, check_traceroute-pure_perl, check_uptime, check_vcs, check_wave, check_wins
There are two mailing lists you can ask for support:
Note: Before sending email to a list, you must be subscribed to it. This is due to the amount of spam received and the administrative burden it was causing.
These mailing lists are specifically for the Nagios Plugins. If you have a question about Nagios (or NRPE, NSCA or NDOutils), see here for the relevant lists.
You can find archives of the nagiosplug-help and nagiosplug-devel mailing lists at gmane.org.
Be aware that these mailing lists are read by volunteers, so responses may take time, if at all.
There is an IRC channel, #Nagios at irc.freenode.net, where the topic is anything about Nagios.
The Nagios Plugins team use Subversion (SVN) for its code repository. This document is a quick introduction to Subversion.
There are three projects:
You can see all the projects by running:
svn list https://nagiosplug.svn.sourceforge.net/svnroot/nagiosplug
Go on, run this now! (You may get a message about certificates - you will need to accept it permanently).
The following notes are for the nagiosmib project, but can be substituted for any of the others.
Run the command:
svn co https://nagiosplug.svn.sourceforge.net/svnroot/nagiosplug/nagiosmib/trun... nagiosmib
This will create a directory called nagiosmib in your current directory with all the "trunk" code (this is equivalent to CVS HEAD). Change into nagiosmib/.
Edit the files in the working area. To check the status, use:
svn status file1 dir1
This will check the status of file1 and everything under dir1 and list them. If you miss out file1 and dir1, the status of all files from the current directory will be listed. Use svn diff to show the differences you have locally.
When you are ready to update from the central repository (usually before you commit), run:
svn update
This will try and merge any changes from the central repository. You will need to resolve any conflicts (marked with a C in svn status) before committing. When resolved, you need to manually tell SVN that the file is now resolved by running:
svn resolved file
When you are happy with changes, commit your changes with:
svn commit
Add a comment (you have read the developers guidelines, right? :) ). If this is your first commit, you will get prompted for a password - use your Sourceforge password. If you still don't have access, are you sure you are a developer on this project? :)
More about subversion can be found at the official documentation site.
The idea with the testing is to move as many functions as possible "lower down", ie to the lib/utils_*.c files. These functions can then be tested using the libtap routines in the lib/tests/test_*.c files. It is easier to do unit testing here than to try and do higher level plugin testing, because you can fake data easier at this level.
The routines available via libtap are equivalent to perl's Test::Simple ones.
The libtap tests are separated out from the plugins ones (in plugins/t) because:
* it is testing the files in lib/, so should reside there
* it requires compiling to run
Firstly, there is a distinction between a Nagios plugin and plugins from the Nagios Plugins project.
Although Nagios (the system) is licenced under the GPL, plugins are executed in their own environment so does not fall under the viral aspect of the GPL. Therefore, any plugin written for use by Nagios can be under any licence the copyright holder selects.
However, the plugins contained within the Nagios Plugins project are distributed under the GPL. If you distribute an application that includes the Nagios Plugins (modified or not), you are required to distribute a copy of the source code for the plugins under the terms of the GPL, regardless of the licensing for the rest of the application.
If you write a plugin which is a derivative work from code of the Nagios Plugins project, then your plugin must also be licenced under the GPL, although you own thecopyright for your modified portions.
Derivative work usually includes:
and does not usually include:
The developer guidelines provides the specifications for writing a Nagios plugin.
This is a document in DocBook format that is held in the Nagios Plugin subversion repository.
We use libtap to test C routines that are in lib/utils_*.c. The tests are in lib/tests/test_*.c.
To start running tests with libtap, download the latest libtap. The latest version is currently 1.01. However, there is a bug with the thread implementation. To workaround, run:
CPPFLAGS="-UHAVE_LIBPTHREAD" ./configure
make
make check
make install
Now when you run the Nagios Plugins ./configure, it should find the libtap library and compile the tests and run them when you run "make test".
This document should be considered work-in-progress until the final transition to Git
The Nagios Plugins team will soon use Git for its code repository. This document is a quick introduction to Git.
There is one huge difference between Git and SVN: Git is a distributed SCM (Source Code Management) while SVN is a centralized one. This doesn't mean we can't have a central Git repository and we will indeed have one; this means distributed development can occur around that central repository.
Another visible difference is that Git tracks content rather than files. Obviously content has to be associated to files for it to be usable and those changes in file ownership are tracked as well. When you want git to track content of a changed file, you use git add to tell is to track changes in that file. git add is also capable of adding specific changes - we'll see that later.
Finally you can't miss the fact that there is no more revision numbers, and the distributed nature of Git is the reason for that: there is absolutely no way a single number could be tracked in a distributed way. Instead Git uses SHA1 hashes to identify commits (as well as other objects in the repository). Each branch and tag refer to an object name (SHA1 hash), and each commits have one or more parents (commit objects). Although SHA1 hashes are 40-digits long, with Git you only have to type a handful of digits to reference one.
There are three projects:
You can see all the projects from the following web page:
http://about:blank
The following notes are for the nagiosplug project, but can be substituted for any of the others.
To work on a project you first have to clone it. This creates your own local repository and until you want to distribute your change or merge changes from someone else everything that follows can happen offline.
If you have push access, run the command:
git clone git://about:blank (push url here)
If you just want a local copy or wish to mirror it to your own server, you can run this command instead:
git clone git://about:blank
This will create a directory called nagiosplug in your current directory with all the "master" code (this is roughly equivalent to CVS/SVN HEAD). Change directory to nagiosplug/.
You can edit the files in the working area. To check the status, use:
git status
This will show a list of tracked (green) and untracked (red) changes in the working dir. You can use git diff to see untracked changes (untracked files will not be shown)
Use git add to specify which new files/changes you want to track. You can select only partial diffs with git add -p too. If you want to commit everything you can use git commit -a directly.
You can see the changes you are about to commit with git diff --cached, and then commit them with:
git commit
Add a comment (you have read the developers guidelines, right? :) ). This commit will be local (affecting only your own repository) so you will have to either push your changes, or have someone to pull them from you.
If you realize that you forgot something in your commit and haven't pushed it yet to a remote repository, you can amend your last commit with git commit --amend. You can also amend after a push and force the next update, however this will cause non-linear updates and should be done only if the developers using your repository are aware of it.
You can revert local modiffications with the following steps.
First, if you have already staged the changes you will have to unstage them. As indicated in the "git status" message you can do so with the following command:
git reset HEAD <file>
Then you can revert unstaged changes with:
git checkout <file>
If you have already committed changes locally and need to undo your commit(s), you can use git reset. First find the commit names with git log and then do either one of these:
To keep local modifications (you can commit them again, stash them, etc.)
git reset --soft <commit>
Note that for the purpose of "re-doing" the last commit, git commit --amend will be much easier than a reset/commit with the same end result.
To discard local modifications (if you lose important changes with this command you may be able to recover them with git reflog and git checkout <commit>):
git reset --hard <file>
Do not reset changes that have already been pushed to remote repositories as this will cause non-linear updates. If you do so, developers using those repositories should be aware of it.
When you work on your local repository you'll need to keep it up to date with the development tree. This is very similar to svn update with the difference that it can't be done if the working tree has any unmerged changes. If you do, either commit them or put them aside (Tip: git stash). If you cloned from the main Git repository, this command will do a fetch then merge any new changes:
git pull
You can also merge changes from any other fork of the repository. This usually happens if someone ask you to pull from his own repo for some fix or enhancements. Together with --no-commit you will have a chance to review the changes and make any relevant correction before the merge. Ex:
git pull --no-commit git://host.xz/path/to/repo.git/ master
Once you're done with your commits and after pulling from the main repository, you can push you change back to it. If you cloned using the push url this command will push the master branch:
git push
It you're trying to push something that would generate merge conflicts, the push will be rejected. You will have to do a pull first, fix the conflicts locally and then push again.
The Nagios::Plugin perl module can be obtained from two main locations:
If you install from the nagiosplug tarball, the perl module will be installed in $prefix/perl.
If you install from CPAN, the perl module will be installed by default into your perl's system directories.
To write your plugin, you should start it with:
use FindBin;
use lib "$FindBin::Bin/../perl/lib";
use Nagios::Plugin;
This bit of code tells perl to look for the Nagios::Plugin module in a directory relative to where the plugin is executed - this is a hard dependency. If Nagios::Plugin is not found there, perl's system directories will be searched.
This approach allows a system administrator to decide whether they want Nagios::Plugin installed via system directories or within the $prefix area of the plugins.
NPTest.pm is a perl module, originally written by Peter Bray, and provides some basic functions for testing the plugins. It has two main helpers:
Used to get parameters given in previous test runs. Use the 3 parameter version (the 4 parameter version is deprecated).
Saved parameters are put in /var/tmp/NPTest.cache. Unfortunately, there is no easy way of altering this - you will have to manually change this file to edit existing parameters
If you are adding new parameters, there are three values for the parameters that you need to be aware of:
You should try and ensure current tests are not affected when a new parameter is added. So it maybe better to say "NP_INTERNET_ACCESS", with information like 'default "yes", disable with "no"' and check for NP_INTERNET_ACCESS == "no" to skip the tests.
This runs a command and returns an NPTest object back. You can combine Test::More routines with the object to get the return code, output or perf data to test against expected values.
See plugins/t/check_disk.t as an example test script.
This website is for a friendly introduction into the Nagios Plugins.
Anyone can browse the site for information. If you wish to leave a comment, you must register (this is to prevent spam). Comments are published immediately, but may be subsequently edited.
This site has been created on Drupal CMS.