Adding debian version 2.3.5-1.debian/2.3.5-1debian

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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.