From notifications at github.com Wed Feb 3 12:51:51 2016 From: notifications at github.com (Shlomi Fish) Date: Wed, 03 Feb 2016 03:51:51 -0800 Subject: [monitoring-plugin-perl] Convert to Dist-Zilla. (#7) Message-ID: This is done as part of the pull-request challenge. Module-Install is undermaintained and unloved. You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugin-perl/pull/7 -- Commit Summary -- * Convert to Dist-Zilla. -- File Changes -- M .gitignore (8) D MANIFEST (73) D META.yml (36) D Makefile.PL (21) A dist.ini (26) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugin-perl/pull/7.patch https://github.com/monitoring-plugins/monitoring-plugin-perl/pull/7.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugin-perl/pull/7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 15 09:34:27 2016 From: notifications at github.com (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 15 Feb 2016 00:34:27 -0800 Subject: check_mailq.pl has a typo (#1403) In-Reply-To: References: Message-ID: you lack version information! and as this particular bug never existed in monitoring-plugins so likely you also confused the repository, monitoring-plugins has this bug. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1403#issuecomment-184110869 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 15 17:12:45 2016 From: notifications at github.com (waja) Date: Mon, 15 Feb 2016 08:12:45 -0800 Subject: check_mailq.pl has a typo (#1403) In-Reply-To: References: Message-ID: As pointed out by @glensc, monitoring-plugins is not affected by this. We introduced a not affected version of this by https://github.com/monitoring-plugins/monitoring-plugins/commit/8235fd0aef2945e0d638fba3493134588d085d5a -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1403#issuecomment-184275986 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 15 17:19:52 2016 From: notifications at github.com (waja) Date: Mon, 15 Feb 2016 08:19:52 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: Speaking as Debian Maintainer, this is something that needs to be handled by packaging system and dependencies/breaks. I see no problem (read: compared to downsides of detecting it at runtime) with specifying a path at compile time at all. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-184278507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 15 19:35:58 2016 From: notifications at github.com (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 15 Feb 2016 10:35:58 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: i can second @waja, can be handled distribution side (versions are artificial): - nagios-plugins 2.4-1 conflicts procps < 3.1.10) - where procps 3.1.10 introduced path change. probably harder to achieve in gentoo like systems, and such distros can just keep legacy symlink to minimize the breakage. and distro should use hardcoded path from compile time to ensure idempotence https://github.com/pld-linux/nagios-plugins/blob/auto/th/nagios-plugins-2.1.1-5/nagios-plugins.spec#L574 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-184340326 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 16 09:48:24 2016 From: notifications at github.com (=?UTF-8?B?VG9tw6HFoSBNw7N6ZXM=?=) Date: Tue, 16 Feb 2016 00:48:24 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: @waja, what are the downsides of using execvp/execlp instead of hardcoding paths during build? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-184580245 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 16 12:44:05 2016 From: notifications at github.com (waja) Date: Tue, 16 Feb 2016 03:44:05 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: @hydrapolic as being in up- and downstream of monitoring-plugins, in either way I want to ensure I define and detect the capabilities of external tools on compile time and have a defined environment on runtime. When using external tools that might change (in behaviour, location, what else), that can cause troubles. When using the first binary found in path, that can be cause more trouble more easier. All this stuff should be handled by distribution toolstack. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-184649354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Feb 20 01:05:31 2016 From: notifications at github.com (Michael Orlitzky) Date: Fri, 19 Feb 2016 16:05:31 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: @glensc The problem was with a new version of procps that became available to users who already had monitoring-plugins installed. When they upgraded procps (to a version that didn't exist when we packaged the plugins), the plugins broke and there was nothing we could do about it. The plugin maintainers don't also maintain procps, samba, SSH, etc. so we won't get any warning before paths change. We can fix it in the future with "blocker" deps but it's sort of pointless. If we're going to force users to reinstall a new version of the plugins that blocks some procps -- well, the reinstall itself fixes the problem, because the plugins get rebuilt and find the correct executable paths! @waja I can imagine a scenario where runtime detection could do something wrong, but right now, the "build-time detection" is just runtime detection... at build-time. When users install the plugins, the `./configure` picks up whatever path happens to work at the time and then hard-codes that. So if mischief can occur with the paths it could still affect a compiled-in path. We may just have to force users to reinstall the plugins frequently (or do nothing and ignore the problem =) I see a few other hard-coded paths for nslookup, ssh, rpcinfo, mailq, smbclient,... Monitoring-plugins would need to be recompiled every time one of those packages is updated, so it comes down to what would be most annoying in the long run. I'm leaning slightly towards "do nothing" as that is my default mode. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-186461049 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 22 10:30:25 2016 From: notifications at github.com (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 22 Feb 2016 01:30:25 -0800 Subject: check_load hardcodes path to 'uptime' (#1394) In-Reply-To: References: Message-ID: @orlitzky i understand the problem you had, in my distro it can be fixed with marking procps 3.3.10 to conflict with monitoring-plugins < 2.1.1-2, where monitoring-plugins == 2.1.1-2 is the "new" version that uses paths from 3.3.10, so users are forced to upgrade both or neither. as for looking up programs from `PATH` security concern, there already exists `--with-trusted-path=PATH` configure option, so it should be "secure" to search them from there runtime. and i think it would also simplify whole `configure.ac` and probably cruft needed to add support for new program for use of plugin. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-187091979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 22 17:18:34 2016 From: notifications at github.com (Sven Geggus) Date: Mon, 22 Feb 2016 08:18:34 -0800 Subject: DNS is case insensitive! (#1404) Message-ID: Thus recent Versions of bind will no longer change .IN-ADDR.ARPA to lowercase as the uppercase version is also valid. To have check_dns.c consider this fact change strstr to strcasestr You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1404 -- Commit Summary -- * DNS is case insensitive! -- File Changes -- M plugins/check_dns.c (2) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1404.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1404.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 22 21:54:14 2016 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 22 Feb 2016 12:54:14 -0800 Subject: DNS is case insensitive! (#1404) In-Reply-To: References: Message-ID: Merged #1404. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1404#event-560378125 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 22 22:55:08 2016 From: notifications at github.com (Oliver Skibbe) Date: Mon, 22 Feb 2016 13:55:08 -0800 Subject: check_dig: expected answer is now incasesensitive (#1386) In-Reply-To: References: Message-ID: With the newly added gnulib, I think that the merge is now okay. What do you think? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1386#issuecomment-187403936 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 22 23:11:23 2016 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Mon, 22 Feb 2016 14:11:23 -0800 Subject: check_dig is case sensitive (#1233) In-Reply-To: References: Message-ID: Closed #1233 via #1386. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1233#event-560509299 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 25 13:40:38 2016 From: notifications at github.com (Jens Hyllegaard) Date: Thu, 25 Feb 2016 04:40:38 -0800 Subject: Error in performance data in check_mrtgtraf (#1405) Message-ID: Hi. I just noticed that the returned warning/critical values do not change depending on the unit of measure used. As the plugin changes the UOM reported depending on the value, this unfortunately also affects the way for instance pnp4gnagios depicts the values: So when I set a warning value of e.g 400mbit or 50000000 bytes then that value should be changed in the reported performance data, otherwise pnp4nagios would take the value of 50000000 as KB whenever that is the UOM stated in the returned value. Here are some examples: in=483.012695KB/s;50000000.000000;90000000.000000;0.000000 out=951.377930KB/s;50000000.000000;90000000.000000;0.000000 in=707.000000B/s;50000000.000000;90000000.000000;0.000000 out=1.786133KB/s;50000000.000000;90000000.000000;0.000000 In the plugin guidelines: https://www.monitoring-plugins.org/doc/guidelines.html#AEN201 point 9 states that "warn and crit are in the range format (see Section 2.5). Must be the same UOM" Unfortunately I am not proficient in C, so I can't create a patch. Regards Jens Hyllegaard -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1405 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 25 14:59:58 2016 From: notifications at github.com (Christian Hesse) Date: Thu, 25 Feb 2016 05:59:58 -0800 Subject: check for ping -{4,6} from new upstream iputils (#1406) Message-ID: You can view, comment on, or merge this pull request online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1406 -- Commit Summary -- * check for ping -{4,6} from new upstream iputils -- File Changes -- M configure.ac (18) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1406.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1406.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1406 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 25 15:02:06 2016 From: notifications at github.com (Christian Hesse) Date: Thu, 25 Feb 2016 06:02:06 -0800 Subject: check for ping -{4,6} from new upstream iputils (#1406) In-Reply-To: References: Message-ID: This is the downstream report from Arch Linux bug tracker: https://bugs.archlinux.org/task/48338 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1406#issuecomment-188795239 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 29 20:52:54 2016 From: notifications at github.com (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 29 Feb 2016 11:52:54 -0800 Subject: [monitoring-plugin-perl] [doc] missing documentation (#8) Message-ID: http://search.cpan.org/~nierlein/Monitoring-Plugin-0.39/lib/Monitoring/Plugin.pm#CONSTRUCTOR there's no documentation for `version`, `blurb`, `license`, `extra`, `plugin`, `timeout` parameters as for example i was looking where to put information about homepage and where to report bugs and copyright years and author. --- for homepage and bugs url, i just appended to `blurb`: https://github.com/glensc/nagios-plugin-check_raid/commit/cd178206287fc2e75d463823618d8e8402215a7b for license and copyright did not find good solution: i do not want to replace `license` key, i like that default GPLv2 is printed. here's example how my plugin worked before starting to use perl-Monitoring-Plugin, and after ``` ? ./check_raid-3.2.5.pl --help | head -n10 check_raid, v3.2.5 Copyright (c) 2004-2006 Steve Shipway, Copyright (c) 2009-2015, Elan Ruusam?e This plugin reports the current server's RAID status https://github.com/glensc/nagios-plugin-check_raid Usage: check_raid [-h] [-V] [-S] [list of devices to ignore] ``` ``` ? ./check_raid-4.0.1.pl --help | head -n10 check_raid 4.0.1 This nagios plugin is free software, and comes with ABSOLUTELY NO WARRANTY. It may be used, redistributed and/or modified under the terms of the GNU General Public Licence (see http://www.fsf.org/licensing/licenses/gpl.txt). This plugin checks all RAID volumes (hardware and software) that can be identified. Usage: check_raid [-h] [-V] [-S] [list of devices to ignore] ``` --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugin-perl/issues/8 -------------- next part -------------- An HTML attachment was scrubbed... URL: