This is done by looking at some common directories and files each
MTA installs on the system. If no known file is found, the old default
sendmail is used. Of course this still can be overridden by -M.
This
| allows you to choose whether the so called "rebuild rules" should be
| enabled or disabled. With AM_MAINTAINER_MODE([enable]), they are
| enabled by default, otherwise they are disabled by default. In the
| latter case, if you have AM_MAINTAINER_MODE in configure.ac, and run
| `./configure && make', then make will *never* attempt to rebuild
| configure, Makefile.ins, Lex or Yacc outputs, etc. I.e., this
| disables build rules for files that are usually distributed and that
| users should normally not have to update.
|
| The user can override the default setting by passing either
| `--enable-maintainer-mode' or `--disable-maintainer-mode' to
| configure.
|
| People use AM_MAINTAINER_MODE either because they do not want their
| users (or themselves) annoyed by timestamps lossage (see CVS), or
| because they simply can't stand the rebuild rules and prefer running
| maintainer tools explicitly.
[ https://www.gnu.org/software/automake/manual/automake.html ]
The old name has been deprecated years ago. The Autoconf documentation
says:
| Previous versions of Autoconf promoted the name configure.in, which is
| somewhat ambiguous (the tool needed to process this file is not
| described by its extension), and introduces a slight confusion with
| config.h.in and so on (for which `.in' means "to be processed by
| configure"). Using configure.ac is now preferred.
[ https://www.gnu.org/software/autoconf/manual/autoconf.html ]
thats because check_procs verifys there is a user for a
given uid filter. So even we use sample data for this
test, we still need a real user.
Signed-off-by: Sven Nierlein <Sven.Nierlein@consol.de>
check_snmp becomes capable of evaluating negative values properly,
but it might be returning CRITICALs where it used to return OK and was ignored,
if a negative value turns out to actually be a valid value.
If negative values are valid, this can be worked around,
by adding "~:" to the warning/critical threshold : 100 -> ~:100
When a timeout value is specified with the -t option, dig will sometimes
timeout before the timer is actually reached.
The problem occurs because the check_dig plugin does not pass the specified
timeout value to dig, leaving dig to timeout with it's default value which
seems to be around 10-15seconds.
To reproduce:
time ./check_dig -H 127.0.0.2 -l www.google.com -t 30
It will not run for 30secs, which is the expected behaviour.
The following will work, because the timeout is less than the default dig
timeout, so the plugin cancels the dig command:
time ./check_dig -H 127.0.0.2 -l www.google.com -t 2
This fix passes the timeout value to dig, and sets the number of retries which tends to vary from system to system by default.
Closes#1168
Check_swap used to allow no swap when thresholds were only specified in
percent. This is no longer the case and the state now must be specified
explicitly. The default is to always return CRITICAL when the swap is
absent regardless of thresholds.
Also default to "-u test -ptest" which are default MySQL accounts only
missing the prescribed privileges.
The database is no longer specified as it is not used.
If wanted is should be its own parameter/tests.
The NPTest.cache cannot be loaded when empty, and this prevents
getting the data and populating the file. This patch skips the file when
empty as if it didn't exist.
If a plugin still has suid privileges at the time np_enable_state() is
called, the MP_STATE_DIRECTORY environment will be ignored.
There is no need for a NEWS entry as no suid plugins use np_enable_state
yet.
