debian/pkg-monitoring-plugins
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

explanation about predefined check commands

Browse source
This commit is contained in:
Jan Wagner 2009-05-14 21:42:36 +00:00
parent 591967c72c
commit e405699f11
3 changed files with 39 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
debian/README.Debian vendored
View file

@ -15,6 +15,38 @@ how to use plugins
- if you need more informations, how to use plugins, have a look at:
http://nagios.sourceforge.net/docs/3_0/plugins.html
================================================================================
predefined / shipped check commands
================================================================================
we are shipping predefined checks, to make users life easier. at the first look,
this seems really nice. providing checks for every special case (see check_http)
may end up in a unsupportable state of our package.
for example one check is testing a service on a special port, where we provide
a check command. after some time, this service changes its port after some time,
cause the developers of this software decided for any reason to do so. changing
the port in the existing check will break installations, which are using the
service with the old behavior. new users will getting confused of not using the
correct port for their shiny service.
cause of this conflict, we try to provide flexible checks, which may look
complicated at first, but giving the user more power.
a good example for using such a general approach is check_nt / check_nscp. some
3rd party sources (guessing they can traced back to one) are suggesting using
two args in some way like:
define command {
command_name check_nt
command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$
}
beside specifying not the port, we are not using "$ARG2$", cause all arguments
of "$ARG2$" can just be used in "$ARG1$" without any problem.
this gives you the possibility to use every check in your service definition,
without the problem about changes in your environment. you can easily change
your service definition as soon your environment changes without breaking the
command definition.
================================================================================
different plugin packages and how to avoid installing massive dependencies
================================================================================
@ -27,7 +59,7 @@ nagios-plugins-basic package.
plugins needing root privilege
================================================================================
the check_dhcp and check_icmp plugins require root privileges to
the check_dhcp, check_icmp and maybe others plugins require root privileges to
run, because of the low-level packet mangling that they perform.
but, in the interest of the "safe default", these plugins will not
be installed with the suid bit set. there are two recommended ways

2
debian/changelog vendored
View file

@ -3,6 +3,8 @@ nagios-plugins (1.4.12-6) UNRELEASED; urgency=low
* add trailing $ to check_httpname, thanks Daniel Pocock (Closes: #524629)
* add informations into README.Debian how to use plugins (Closes: #525168)
* add check_nscp which uses the default port of NSClient++ (Closes: #528262)
* providing some explanation about predefined check commands in README.Debian
* pointing to README.Debian in nt.cfg
* add 43_check_ntp_segfaults.dpatch to fix buffer overflow in check_ntp and
check_ntp_peer, thanks to Andreas Olsson (Closes: #528686)

4
debian/pluginconfig/nt.cfg vendored
View file

@ -1,3 +1,7 @@
# If you are confused about this command definition, cause you was
# reading other suggestions, please have a look into
# /usr/share/doc/nagios-plugins/README.Debian
# 'check_nt' command definition
define command {
command_name check_nt