Hi,
currently check_zone_auth does not distinguish between a nameservers v4 and v6 address and queries whatever Net::DNS::Resolver finds appropriate.

As v4 and v6 may be broken individually or serve different data on error the check_zone_auth should explicitly query the nameservers v4 and v6 addresses. v6 needs to be enabled as the icinga host may not have v6 connectivity.

Flo

When LC_TIME is non english, the default_date_header in check_smtp_send will output, for example:

Date: mar., 7 août 2018 10:55:41 +0200 (CEST)

This does not conform to RFC822 for several reasons:

• the day and months must be in english
• the trailing time zone name is not allowed.
• the hour is expressed in GMT but the +0200 time displacement claims that's it local, i.e. in the above example, it should be 12:55:41 +0200, or 10:55:41 +0000 if GMT is prefered for some reason.

Date and time spec in RFC822: https://tools.ietf.org/html/rfc2822#page-14

Proposed fix:

use POSIX qw(strftime locale_h);
...
sub default_date_header {
 my $old_locale = setlocale(LC_TIME, "C");
 my $date_rfc822 = strftime("%a, %d %b %Y %H:%M:%S %z", localtime);
 setlocale(LC_TIME, $old_locale);
 return "Date: $date_rfc822";
}

Please update to 4.0.3 (https://github.com/glensc/nagios-plugin-check_raid/blob/4.0.3/ChangeLog.md)

./check_httpd_status -H localhost

Argument "6 hours 28 minutes 17 seconds" isn't numeric in subtraction (-) at ./check_httpd_status line 322.
HTTPD_STATUS OK - 1.294 s - 1/5 Busy/Idle, 144/150 Open/Total, 0.0 requests/s, 0.0 B/s, 0 B/request | ReqPerSec=0.000req/s;; BytesPerSec=0.00B/s;; OpenSLot=144;; Closing=0;; DNS=0;; Finishing=0;; Idle=0;; Keepalive=0;; Logging=0;; Reading=0;; Starting=0;; Sending=1;; Waiting=5;; FreeWorker=149;;;0;

Some plugins, like check_ssh, add a leading space to the perf data and check_v46 should remove this space or the prepended ipv4_a1_ and ipv6_a1_ will have a trailing space and service-perfdata scripts will fail to parse the performance data because of too many spaces.

See Pull request for check_v46 with a proposed fix for this issue.

I still have The following processes have libs linked that were upgraded after a reboot and I think it may be related to this :

bbigras@ubuntunew:/usr/lib/nagios/plugins$ sudo ./check_libs --verbose
[...]
adding mysqld(1588) because of [/[aio]]:
fDELa l tREGD0xbi11788n/[aio]

bbigras@ubuntunew:/usr/lib/nagios/plugins$ sudo lsof -p 1588 | grep aio
mysqld  1588 mysql  DEL    REG       0,11              11797 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11796 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11795 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11794 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11793 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11792 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11791 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11790 /[aio]
mysqld  1588 mysql  mem    REG      252,0       4880 2485748 /lib/i386-linux-gnu/libaio.so.1.0.1
mysqld  1588 mysql  DEL    REG       0,11              11800 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11789 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11788 /[aio]
mysqld  1588 mysql  DEL    REG       0,11              11782 /[aio]

Nagios Core 4.0.8
nagios-plugins-contrib 9.20140106
Ubuntu 14.04.1 LTS (32-bit)

I'm using check_libvirt on my CentOS 7 KVM-Host:

# /usr/lib64/nagios/plugins/check_libvirt -V
check_libvirt 0.1.0

I receive this error-infos whil checking I/O

# /usr/lib64/nagios/plugins/check_libvirt --host=qemu:///system -N freifunk-controller -l io
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 428.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 430.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 431.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 428.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 430.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 431.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 428.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 430.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 431.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 428.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 430.
Use of uninitialized value in addition (+) at /usr/lib64/nagios/plugins/check_libvirt line 431.
CHECK_LIBVIRT OK - IO read bytes = 0, read req = 0, write bytes = 23945.84, write req = 0, errors = 0 | rd_bytes=0;; rd_req=0;; wr_bytes=23945.84;; wr_req=0;; errors=0;;

@petterreinholdtsen - check_shutdown has a broken control file + I think it won't work with systemd. Please fix it.

check_ajp needs to catch SIGPIPE and do something appropriate (...critical...).

The website http://git.op5.org/gitweb seems not available anymore.

https://travis-ci.org/bzed/pkg-nagios-plugins-contrib/jobs/180384889#L3899-L3907

Dear Bernd and Jan,

while working on recent improvements to the check_running_kernel program at #91, we also found another issue. In order to keep things separated, we've split this amendment off the other patch and want to report about our observations here first.

The problem was that the comparison of running kernel's /proc/version against the on-disk version failed on Ubuntu kernels and derivates, because Ubuntu (and maybe others?) adds another suffix to the on-disk string defined by CONFIG_VERSION_SIGNATURE. At runtime, this string is apparently stripped off and presented through /proc/version_signature instead, so /proc/version does not match the original representation. Sigh.

Based on the findings outlined below, we ask for further guidance. The problem might have to be solved differently than with our ad hoc patch.

With kind regards,
Andreas.

Introduction

We discovered that on both a bullseye-based PVE/Proxmox machine, and on another vanilla Ubuntu 20.04 machine, both running 5.x Linux kernel versions, there was a suffix added to the on-disk kernel image, which we stripped off using sed in order to satisfy the comparison operation in an ad hoc manner, see patch below.

Observations

We've only been able to spot this on systems running non-vanilla Debian derivates with 5.x Linux kernel versions. On a standard Debian bullseye machine running 5.10.0-12, this is not an issue.

No suffix on vanilla Debian

root@kraftwerk:~$ dd if=/boot/vmlinuz-5.10.0-12-amd64 bs=16913 skip=1 | xzcat | strings | grep "Linux version"
Linux version 5.10.0-12-amd64 ([email protected]) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.103-1 (2022-03-07)

Empty () suffix on PVE kernel

root@zapato:~$ dd if=/boot/vmlinuz-5.13.19-2-pve bs=17100 skip=1 | zstd -d | strings | grep "Linux version"
Linux version 5.13.19-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) ()

Assigned () suffix on Ubuntu kernel

It's (Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19), to be precise.

root@next ~$ dd if=/boot/vmlinuz-5.13.0-30-generic bs=17100 skip=1 | zstd -d | strings | grep "Linux version"
Linux version 5.13.0-30-generic (buildd@lcy02-amd64-003) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 (Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19)

Research

After researching the topic a bit, we discovered that it is apparently an Ubuntu-specific thing, triggered by the CONFIG_VERSION_SIGNATURE compile time option. Indeed, on those systems, there is a synthetic /proc/version_signature file containing this suffix, which does not seem to be present on systems running vanilla Debian.

root@next ~ # cat /proc/version_signature
Ubuntu 5.13.0-27.29~20.04.1-generic 5.13.19

Solution

This patch made things work for us in a quick manner before knowing any details about the background. It might want to be elaborated a bit further now.

Index: pkg-nagios-plugins-contrib/dsa/checks/dsa-check-running-kernel
===================================================================
--- dsa-check-running-kernel.dist	2022-03-12 21:36:28.000000000 +0100
+++ dsa-check-running-kernel	2022-03-12 21:36:32.000000000 +0100
@@ -226,6 +228,9 @@
 	exit $WARNING
 fi
 
+# Adjustment for PVE/Proxmox and Ubuntu kernels: Strip off the last fragment.
+on_disk_version=$(echo "$on_disk_version" | sed -E 's/(.*) \(.*\)$/\1/')
+
 if [ "$(uname -s)" = "Linux" ]; then
 	running_version="`cat /proc/version`"
 	if [ -z "$running_version" ] ; then

References

• https://ubuntu.com/kernel
• https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2FFAQ.2FGeneralVersionRunning.How_can_we_determine_the_version_of_the_running_kernel.3F
• https://stackoverflow.com/questions/70740713/heroku-understanding-what-version-of-linux-kernel-is-used
• https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/[email protected]/

OK: Running kernel matches on disk image: [Linux version 2.6.32-573.26.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Wed May 4 00:57:44 UTC 2016]

While a newer version was installed with yum update. After reboot newer kernel was present.

Dear Bernd and Jan,

at madrisan/nagios-plugins-linux#104, we shared some observations about the vendoring of the check_memory program by @madrisan with commits 44c2d26 and eadc785. This will essentially swap the program /usr/lib/nagios/plugins/check_memory from a Perl implementation to an implementation in C.

In general, this is a good thing. The problem is that the default mode of this program, with respect to evaluating the threshold values, is essentially inverted. @Flowdalic already reported that to the Debian bugtracker at #1005908. The behavior would have to be compensated by adding the --available option. However, there are other bits on the --warning|--critical option values which make existing installations incompatible.

@madrisan was very welcoming at madrisan/nagios-plugins-linux#104 (comment) and might add some bits to improve the situation.

With kind regards,
Andreas.

varnish/varnish-nagios#16 contains a PR which might work with recent varnish versions

Using the latest version from git on jessie results into the following (in debug log):

[1480888765.350174] [016.0] [pid=15037] Embedded Perl failed to compile /usr/lib/nagios/plugins/check_printer, compile error **ePN failed to compile /usr/lib/nagios/plugins/check_printer: "Variable "$plugin_module" will not stay shared at (eval 1) line 57," at /usr/lib/icinga/p1.pl line 248.

Running on console it works.

This seems to be related to Debian Bug 808722.

Hi,
/usr/lib64/nagios/plugins/pmp-check-aws-rds.py -l
List of all DB instances:
[]
that all i get, it's probably new aws cli

upstream calls it check_mongodb.py, not check_mongodb, so examples, docs and snippets found outside of debian will refert to that name. we should have that as a symlink at least.

And possibly other of those mail-checks:

Lines 155 and 391 should read something like this:
} elsif ((!length($quotaUsed)) || !(length($quotaLimit))) {

Hello,

regarding to this Makefile the value of #STATEFILES_DIR# will be replaced with /var/cache/nagios.

This is not going to work, if you are using Icinga instead of Nagios or a local check via NRPE.

Please make sure that the check is using an already existing directory or let the package create the directory during the installation.

Regards, Dennis

Now shipping an (maybe modified) embedded code copy of libmodule-install-perl.

perl module dependency changes:

• * Getopt::Long
• * Nagios::Plugin::Getopt
• * Number::Format