diff options
Diffstat (limited to 'debian/README.Debian')
| -rw-r--r-- | debian/README.Debian | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 0000000..b1eaa35 --- /dev/null +++ b/debian/README.Debian @@ -0,0 +1,95 @@ +================================================================================ +monitoring-plugins for Debian +================================================================================ + +below is a collection of various bits of information that might be +helpful to users of monitoring-plugins in debian. + +================================================================================ +plugins and dependencies +================================================================================ + +some plugins require additional libraries and programs. to prevent you from +having to install dozens of further packages that you don't actually need, +there is no strict dependency on some of them. +see /usr/share/doc/monitoring-plugins-standard/README.Debian.plugins for details. + +================================================================================ +how to use plugins +================================================================================ + +- you can invoke the plugins with "--help" to get help how to use the plugins +- a short usage can be usually obtained by just running the check without + arguments +- if you need more information, how to use plugins, have a look at: + http://www.monitoring-plugins.org/doc/faq/index.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 +================================================================================ + +if you're frustrated by all the crap being brought in by monitoring-plugins (for +example if you're installing nrpe or nsca on a remote host), try the +monitoring-plugins-basic package. + +================================================================================ +plugins needing root privilege or capabilities(7) set +================================================================================ + +the check_dhcp, check_icmp and maybe others plugins require root privileges or +capabilities(7) 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. +if setcap is able set the necessary capabilities, you are fine. if the setcap +binary is not installed or not able to set the capabilities, you need to +either set the capabilities (eg. cap_net_raw+ep) for your own or provide root +privileges. You could go the lazy way and install libcap2-bin and run the +following afterwards: + +# /var/lib/dpkg/info/monitoring-plugins-basic.postinst configure + +there are two recommended ways about providing root priviles to your plugins +on your system: + +- set the suid bit with dpkg-statoverride: + +# dpkg-statoverride --update --add root nagios 4750 $plugin + +where $plugin is the specific plugin you want to grant such privileges. + +- use sudo to grant the permissions and modify your plugin config + +of these two, the first is recommended because it's the simplest and +has the same effect as the second. |