From notifications at github.com Sat Feb 1 17:32:17 2014 From: notifications at github.com (waja) Date: Sat, 01 Feb 2014 08:32:17 -0800 Subject: check_ldap [-4|-6] without functionality (#1229) Message-ID: While evaluating the implementation of the [-4|-6] options I stumbled upon that this is not working for check_ldap. f813c747a264906c066d85d220e7b0f4aab3e046 is placebo for check_ldap so far. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1229 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Feb 1 17:43:16 2014 From: notifications at github.com (waja) Date: Sat, 01 Feb 2014 08:43:16 -0800 Subject: check_pgsql/check_mysql: Not supporting [-4|-6] (#1230) Message-ID: check_pgsql and check_mysql does not support an option to force IPv4/IPv6 connects via [-4|-6]. It would be very useful if this would be possible. At least Ubuntu has for check_pgsql a wishlist bug pending: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1061154 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1230 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 2 13:12:01 2014 From: notifications at github.com (waja) Date: Sun, 02 Feb 2014 04:12:01 -0800 Subject: check_radius: please support FreeRADIUS client library (#1231) Message-ID: Please add support for the FreeRADIUS client library[1]. In Debian the radiusclient-ng package will be removed[2] soon and super-seeded by freeradius-client, so this will be a problem. Asterisk has a ticket[3] for a migration and also a patch[4] available for this. They describe the problem: "The API is 99% compatible but: * the header name has changed * the library name has changed * the configuration file location has changed" The bug against the Debian package: http://bugs.debian.org/721621 [1] http://freeradius.org/freeradius-client/ [2] http://bugs.debian.org/721419 [3] https://issues.asterisk.org/jira/browse/ASTERISK-22980 [4] https://issues.asterisk.org/jira/secure/attachment/48948/freeradius-client.patch -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1231 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at zedat.fu-berlin.de Sun Feb 2 14:20:17 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sun, 2 Feb 2014 14:20:17 +0100 Subject: GitHub notifications In-Reply-To: <52EBB7F0.10009@LINworks.de> References: <20140130215818.GA344156@zedat.fu-berlin.de> <52EBB7F0.10009@LINworks.de> Message-ID: <20140202132017.GM654350@zedat.fu-berlin.de> * Jochen Bern [2014-01-31 15:49]: > On 30.01.2014 22:58, Holger Wei? wrote: > > [ 1/2 ] Please continue to forward all notifications to this list. > > [ 1/2 ] Please filter out status changes, but forward actual comments. > > [ ] Please don't forward any GitHub notifications! > > [ ] I don't care. > > I'm a bit torn on the issue. In the best possible world, there should be > a "devel" list for everyone having an interest in where development of > the plugin goes (which would ask for publication of at least *some* of > the comments), while the actual guardians of the official > versions/commits would have a "maintainers" list for themselves. But > that latter isn't (yet?) in existence for the monitoring-plugins > project, is it? True, but it could be created if it made sense, of course. However, if this was about the maintainers, they could subscribe to the GitHub notifications individually and be done with it.? The question is really just whether the discussions (and status changes) on GitHub are also interesting to others besides the actual maintainers. If so, we'd like to involve those people; and for them, it might be a feature having just a single place for (un)subscribing, a single filter rule to maintain, and so on. At least that's how I'd feel when subscribing to other project's development lists. Holger ? I'll do just that if we switch to filtering out status changes. From dermoth at aei.ca Sun Feb 2 21:37:25 2014 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 02 Feb 2014 15:37:25 -0500 Subject: GitHub notifications In-Reply-To: <20140202132017.GM654350@zedat.fu-berlin.de> References: <20140130215818.GA344156@zedat.fu-berlin.de> <52EBB7F0.10009@LINworks.de> <20140202132017.GM654350@zedat.fu-berlin.de> Message-ID: <52EEAC85.8070703@aei.ca> On 02/02/14 08:20 AM, Holger Wei? wrote: > * Jochen Bern [2014-01-31 15:49]: >> On 30.01.2014 22:58, Holger Wei? wrote: >>> [ 1/2 ] Please continue to forward all notifications to this >>> list. [ 1/2 ] Please filter out status changes, but forward >>> actual comments. [ ] Please don't forward any GitHub >>> notifications! [ ] I don't care. >> >> I'm a bit torn on the issue. In the best possible world, there >> should be a "devel" list for everyone having an interest in where >> development of the plugin goes (which would ask for publication of >> at least *some* of the comments), while the actual guardians of the >> official versions/commits would have a "maintainers" list for >> themselves. But that latter isn't (yet?) in existence for the >> monitoring-plugins project, is it? > > True, but it could be created if it made sense, of course. However, > if this was about the maintainers, they could subscribe to the > GitHub notifications individually and be done with it.? The question > is really just whether the discussions (and status changes) on GitHub > are also interesting to others besides the actual maintainers. If > so, we'd like to involve those people; and for them, it might be a > feature having just a single place for (un)subscribing, a single > filter rule to maintain, and so on. At least that's how I'd feel > when subscribing to other project's development lists. Hi Holger, Initially I was on the side of having all or most github notifications sent to the ML, but there's the issue of replies being sent without any author information. I'l also getting the notifications twice, once on the ML and once on my personal subscription. I don't really want to filter out the ML emails as I want to see whatever is being sent there, at the same time I'd like to reply to my own subscription emails so it's clean who is commenting. So although it's more work on the user's side, I'm wondering if we could drop these notifications and instead subscribe on our own to what we'd like. What I'm still wondering though is: 1. Can we create a "watcher" team on GH that sets the notifications by default, where users can join and leave on their own (will default notification settings be part of the team? if not then that is pointless...) 2. Let's say I want to bring up a bug to the attention of the devel list, what are the impact of cc'ing the list? will replies show up on the ticket and how? Regards, -- Thomas From holger at zedat.fu-berlin.de Mon Feb 3 10:12:44 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Mon, 3 Feb 2014 10:12:44 +0100 Subject: GitHub notifications In-Reply-To: <52EEAC85.8070703@aei.ca> References: <20140130215818.GA344156@zedat.fu-berlin.de> <52EBB7F0.10009@LINworks.de> <20140202132017.GM654350@zedat.fu-berlin.de> <52EEAC85.8070703@aei.ca> Message-ID: <20140203091244.GN654350@zedat.fu-berlin.de> * Thomas Guyot-Sionnest [2014-02-02 15:37]: > Initially I was on the side of having all or most github notifications > sent to the ML, but there's the issue of replies being sent without any > author information. Right, that's odd. In the meantime, I had written a script for filtering the notifications?, as the feedback so far looked like most subscribers wanted them.? That script also removes the "Reply-To:" header which allowed for replying without author information. The notifications now just include an HTTP URL that says "if you wanna reply, do it here". That's not optimal, but personally I'd still prefer that solution over not having the comments on our mailing list (archives) at all. > I don't really want to filter out the ML emails as I want to see > whatever is being sent there, at the same time I'd like to reply to my > own subscription emails so it's clean who is commenting. I didn't quite get this part. Personally I'd subscribe on GitHub and filter out the GitHub notifications that went to the list. > 1. Can we create a "watcher" team on GH that sets the notifications by > default, where users can join and leave on their own (will default > notification settings be part of the team? if not then that is pointless...) I don't think that's possible. > 2. Let's say I want to bring up a bug to the attention of the devel > list, what are the impact of cc'ing the list? will replies show up on > the ticket and how? You won't be able to setup a "Reply-To:" address that allows for also replying on the ticket. Holger ? https://www.monitoring-plugins.org/repositories/site/tree/libexec/filter-github-emails Right now this script still accepts all notifications, but it already adds a header line that depends on the content: - X-MP-Content: GitHub status change - X-MP-Content: GitHub comment ? Feedback so far: Option | Votes | Percent | Remarks -----------------------------------+-------+---------+-------- (A) forward all notifications | 8.5 | 39 | (B) forward only comments | 6.5 | 30 | 1 of them also fine with (A) (C) don't forward any notifications| 6 | 27 | 1 of them doesn't really care (D) don't care | 1 | 5 | From notifications at github.com Mon Feb 3 17:08:52 2014 From: notifications at github.com (Matthieu Kermagoret) Date: Mon, 03 Feb 2014 08:08:52 -0800 Subject: check_icmp: use packet reception time to compute rtt (#1232) Message-ID: Currently, check_icmp uses processing time to compute rtt. This can lead to invalid values when the machine is heavily loaded. The patch I propose uses the SO_TIMESTAMP feature of setsockopt to use the kernel reception time instead. You can merge this Pull Request by running: git pull https://github.com/ganoze/monitoring-plugins master Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1232 -- Commit Summary -- * Use kernel reception time on ICMP packets to compute rtt. * Restore check_icmp header style (spaces at EOL). -- File Changes -- M plugins-root/check_icmp.c (55) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1232.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1232.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1232 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:46:00 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:46:00 -0800 Subject: sslutils expire time in US format [sf#2424575] (#840) In-Reply-To: References: Message-ID: n-p has it over there https://github.com/nagios-plugins/nagios-plugins/issues/20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/840#issuecomment-34229553 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:50:10 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:50:10 -0800 Subject: time in rtc 822 (#1161) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1161#issuecomment-34230020 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:50:19 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:50:19 -0800 Subject: sslutils expire time in US format [sf#2424575] (#840) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/840#issuecomment-34230047 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:50:31 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:50:31 -0800 Subject: check_http -C produces confusing date [sf#3142101] (#977) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/977#issuecomment-34230079 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:50:37 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:50:37 -0800 Subject: check_http: clarify timestamp format for SSL cert expiry [sf#3140046] (#976) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/976#issuecomment-34230099 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:50:47 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:50:47 -0800 Subject: time in rtc 822 (#1161) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1161#issuecomment-34230115 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 20:53:58 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 11:53:58 -0800 Subject: check_http certificate date format i18n [sf#1096452] (#382) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/382#issuecomment-34230423 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 5 21:04:32 2014 From: notifications at github.com (waja) Date: Wed, 05 Feb 2014 12:04:32 -0800 Subject: print time in rfc 822 format [sf#3123940] (#975) In-Reply-To: References: Message-ID: n-p has it over there nagios-plugins/nagios-plugins#20 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/975#issuecomment-34231581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 6 19:59:11 2014 From: notifications at github.com (waja) Date: Thu, 06 Feb 2014 10:59:11 -0800 Subject: Fix PATH_TO_QMAIL_QSTAT in configure (#1208) In-Reply-To: References: Message-ID: included by https://github.com/nagios-plugins/nagios-plugins/commit/4b9ed14a99dd3d10cf6b2e46d75d8dab18eba045 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1208#issuecomment-34357409 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 6 20:05:20 2014 From: notifications at github.com (waja) Date: Thu, 06 Feb 2014 11:05:20 -0800 Subject: check_ntp_time: adding offset option (#1184) In-Reply-To: References: Message-ID: Fixed in n-p by applying: https://github.com/nagios-plugins/nagios-plugins/commit/973c4060e549abb78d6a806a09f14559a63ea55b https://github.com/nagios-plugins/nagios-plugins/commit/028cd0742548499927603097feef34f77568c09e -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1184#issuecomment-34358088 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 6 20:08:05 2014 From: notifications at github.com (waja) Date: Thu, 06 Feb 2014 11:08:05 -0800 Subject: check_ssh protocol check [sf#1899981] (#780) In-Reply-To: References: Message-ID: This is fixed in n-p by applying: https://github.com/nagios-plugins/nagios-plugins/commit/a1da849de150440600e122dd5380c23e2622f6c1 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/780#issuecomment-34358390 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 6 20:08:25 2014 From: notifications at github.com (waja) Date: Thu, 06 Feb 2014 11:08:25 -0800 Subject: check_ssh: check protocol (#1190) In-Reply-To: References: Message-ID: This is fixed in n-p by applying: https://github.com/nagios-plugins/nagios-plugins/commit/a1da849de150440600e122dd5380c23e2622f6c1 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1190#issuecomment-34358425 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 7 12:46:46 2014 From: notifications at github.com (stirnim) Date: Fri, 07 Feb 2014 03:46:46 -0800 Subject: check_dig is case sensitive (#1233) Message-ID: check_dig is case sensitive about the query answer which leads to a warning: Server not found in ANSWER SECTION. See verbose output: /usr/lib/nagios/plugins/check_dig -H dns-cache2.switch.ch -vvvv -l 6to4-relay.switch.ch /usr/bin/dig @dns-cache2.switch.ch -p 53 6to4-relay.switch.ch -t A Looking for: '6to4-relay.switch.ch' ;; ANSWER SECTION: 6TO4-RELAY.switch.ch. 81981 IN A 130.59.31.253 ;; AUTHORITY SECTION: switch.ch. 2221 IN NS ns2.switch.ch. switch.ch. 2221 IN NS scsnms.switch.ch. ;; ADDITIONAL SECTION: ns2.switch.ch. 160647 IN A 130.59.138.49 ns2.switch.ch. 160647 IN AAAA 2001:620:0:1b:5054:ff:fe74:8780 scsnms.switch.ch. 160647 IN A 130.59.1.30 scsnms.switch.ch. 160647 IN A 130.59.10.30 scsnms.switch.ch. 160647 IN AAAA 2001:620::1 ;; Query time: 12 msec ;; SERVER: 2001:620:0:ff::3#53(2001:620:0:ff::3) ;; WHEN: Fri Feb 7 12:42:51 2014 ;; MSG SIZE rcvd: 208 DNS WARNING - 0.033 seconds response time (Server not found in ANSWER SECTION)|time=0.033127s;;;0.000000 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1233 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 7 13:54:08 2014 From: notifications at github.com (Sam Kottler) Date: Fri, 07 Feb 2014 04:54:08 -0800 Subject: Remove unnecessary whitespace in Makefile.am (#1234) Message-ID: You can merge this Pull Request by running: git pull https://github.com/skottler/monitoring-plugins plugin_makefile_whitespace Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1234 -- Commit Summary -- * Remove unnecessary whitespace in Makefile.am -- File Changes -- M plugins/Makefile.am (5) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1234.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1234.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 7 15:18:08 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Fri, 07 Feb 2014 06:18:08 -0800 Subject: Remove unnecessary whitespace in Makefile.am (#1234) In-Reply-To: References: Message-ID: Merged #1234. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 7 20:29:10 2014 From: notifications at github.com (stirnim) Date: Fri, 07 Feb 2014 11:29:10 -0800 Subject: check_dig is case sensitive (#1233) In-Reply-To: References: Message-ID: This bug is related to a change in the response behavior of BIND 9.9.5. See https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.html The problem is not in BIND 9.9.5 but that check_dig is case-sensitive in what it accepts! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1233#issuecomment-34491074 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Feb 10 12:47:09 2014 From: notifications at github.com (stirnim) Date: Mon, 10 Feb 2014 03:47:09 -0800 Subject: check_dig is case sensitive (#1233) In-Reply-To: References: Message-ID: A simple replace of strstr with strcasestr should fix it I guess --- a/plugins/check_dig.c +++ b/plugins/check_dig.c @@ -125,7 +125,7 @@ main (int argc, char **argv) if (verbose) printf ("%s\n", chld_out.line[i]); - if (strstr (chld_out.line[i], (expected_address == NULL ? query_address : expected_address)) != NULL) { + if (strcasestr (chld_out.line[i], (expected_address == NULL ? query_address : expected_address)) != NULL) { msg = chld_out.line[i]; result = STATE_OK; -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1233#issuecomment-34623003 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 11 07:50:39 2014 From: notifications at github.com (waja) Date: Mon, 10 Feb 2014 22:50:39 -0800 Subject: check_ide_smart: fix smart attribute comparison [sf#3428117] (#1040) In-Reply-To: References: Message-ID: This is even referenced at http://bugs.debian.org/738042 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1040#issuecomment-34730237 -------------- next part -------------- An HTML attachment was scrubbed... URL: From plugins at monitoring-plugins.org Thu Feb 6 20:04:54 2014 From: plugins at monitoring-plugins.org (Monitoring Plugins) Date: Thu, 6 Feb 2014 20:04:54 +0100 (CET) Subject: No subject Message-ID: <20140206190454.A8051200193C@orwell.monitoring-plugins.org> From bounces+848413-276d-plugins+github=monitoring-plugins.org at sgmail.github.com Thu Feb 6 20: 04:54 2014 Return-Path: X-Original-To: plugins+github at monitoring-plugins.org Delivered-To: plugins+github at monitoring-plugins.org Received: from o4.sgmail.github.com (o4.sgmail.github.com [192.254.112.99]) by orwell.monitoring-plugins.org (Postfix) with SMTP id A51A62001934 for ; Thu, 6 Feb 2014 20:04:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sgmail.github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=smtpapi; bh=RErJ3nTeg7y3ZkjJ/pGO+4QP194=; b=Z4NSLqvJfFtyMfsfG3 FZqf2orUgdrsyGDFbDDUlYb4MtjsiL1r5yYTyvjndaOrWSdlU97lzdSPcxLnx+99 ujF4Oesi0TZFFNySQvrmwsGJHHJ1vVWeVV1YrPm2+C+yNUyrAMKuyoc0ZGZ5OUtk /HdXGn34o0mgd6+RH5wIPKFCI= Received: by mf277.sendgrid.net with SMTP id mf277.11566.52F3DCD42 Thu, 06 Feb 2014 19:04:52 +0000 (UTC) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd-013 (SG) with ESMTP id 14408969c3d.7e7f.12d8d for ; Thu, 06 Feb 2014 19:04:52 +0000 (GMT) Received: from github-lowworker5-pe1-prd.aws.github.net (github-lowworker5-pe1-prd.aws.github.net [172.19.13.193]) by github-smtp2b-ext-cp1-prd.iad.github.net (Postfix) with ESMTP id 00072E675B for ; Thu, 6 Feb 2014 11:04:51 -0800 (PST) Date: Thu, 06 Feb 2014 11:04:51 -0800 From: waja To: Monitoring Plugins Development Cc: Monitoring Plugins Development Message-ID: In-Reply-To: References: Subject: Re: NTP Time Offset [sf#2864922] (#907) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_52f3dcd3e2c47_3d83f871a92f2a810488f"; charset="UTF-8" Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Recipient: monitoring-user X-GitHub-Reason: author List-ID: monitoring-plugins/monitoring-plugins List-Archive: https://github.com/monitoring-plugins/monitoring-plugins List-Post: List-Unsubscribe: , X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: plugins+github at monitoring-plugins.org X-SG-EID: 9g85I98B45owfP+p5gQnAu2U9KJoEjKej8w6VGaUYDkg5Bf+bkW+y/yibIu73T8SLfOgao9ZxpeM1x1wF17HexZkMe6Mvr/uKi+DAL/4mdWP3Ms9JGsJo+ZSciL1r4t43zg4rWYM+t353q9TCYfmSybximI/JVIgT0qgLcqCmDfZ2mDhz34dXYdYrD7Ws2T6 X-Loop: plugins at monitoring-plugins.org X-Original-From: bounces+848413-276d-plugins+github=monitoring-plugins.org at sgmail.github.com X-MP-Filter: filter-github-emails X-MP-Content: GitHub comment ----==_mimepart_52f3dcd3e2c47_3d83f871a92f2a810488f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Fixed in n-p by applying: https://github.com/nagios-plugins/nagios-plugins/commit/973c4060e549abb78d6a806a09f14559a63ea55b https://github.com/nagios-plugins/nagios-plugins/commit/028cd0742548499927603097feef34f77568c09e -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/907#issuecomment-34358033 ----==_mimepart_52f3dcd3e2c47_3d83f871a92f2a810488f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Fixed in n-p by applying:

nagios-plugins/nagios-plugins@973c406
nagios-plugins/nagios-plugins@028cd07


Reply to this email on GitHub.

----==_mimepart_52f3dcd3e2c47_3d83f871a92f2a810488f-- From notifications at github.com Tue Feb 11 18:18:40 2014 From: notifications at github.com (seemuellera) Date: Tue, 11 Feb 2014 09:18:40 -0800 Subject: Added warning and critical thresholds to the performance data of check_snmp (#1235) Message-ID: Dear monitoring-plugins developer team, Thank you very much on your great work on the plugins. Attached I've added a small patch to check_snmp to include the warning and critical thresholds in the performance data to allow better graphing of the monitored values. You can merge this Pull Request by running: git pull https://github.com/seemuellera/monitoring-plugins master Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1235 -- Commit Summary -- * warning and critical thresholds are now also displayed as performance data. * Added output of warning and critical thresholds to the performance data -- File Changes -- M plugins/check_snmp.c (14) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1235.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1235.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1235 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 11 21:39:55 2014 From: notifications at github.com (Wil Cooley) Date: Tue, 11 Feb 2014 12:39:55 -0800 Subject: check_ntp_peer result message is unclear about reason for failure (#1236) Message-ID: `check_ntp_peer` has 4 different thresholds that it checks but one cannot tell from the result message which of the thresholds has been exceeded. This makes it a lot harder to assess where the problem lies or how quickly the alert needs to be responded to, particularly at 04:00 on your cell phone. I would like the result message to make it clear which of the 4 thresholds have been passed, either by somehow emphasizing the ones in error or only including those in error. (Values for the other thresholds are already captured by performance data, so I don't think there would be any loss from leaving them out.) Ideally human-readable threshold ranges could also be included in the message, but given the complexity of threshold specification I can understand leaving this out. Currently output looks like this: ``` NTP WARNING: Offset -0.021909 secs, jitter=15.843000, stratum=1, truechimers=15 ``` or this: ``` NTP WARNING: Offset -0.002291 secs, jitter=0.659000, stratum=3, truechimers=5 ``` Without consulting my perfdata or configuration, can you tell which threshold is being exceeded? Ideally, the output would be something like this: ``` NTP WARNING: Offset -0.021909 secs, expect 0.010000 > |offset| > 0.100000 ``` and this: ``` NTP WARNING: Stratum 3, expect stratum < 2 ``` -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1236 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 11:00:02 2014 From: notifications at github.com (=?UTF-8?B?QWRyacOhbg==?=) Date: Wed, 12 Feb 2014 02:00:02 -0800 Subject: Show error if parameter incorrectly setted (percentage symbol) (#1237) Message-ID: If check_disk warning threshold is set incorrectly, "%20", check won't work, but doesn't output any error: Incorrectly behaviour: ``` /usr/lib64/nagios/plugins/check_disk -w %80 -c %10 / DISK OK - free space: / 4482 MB (71% inode=86%);| /=1743MB;6559;6559;0;6559 ``` Expected some error. Correctly ``` /usr/lib64/nagios/plugins/check_disk -w 80% -c 10% / DISK WARNING - free space: / 4482 MB (71% inode=86%);| /=1743MB;1311;5903;0;6559 ``` -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1237 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 12:26:16 2014 From: notifications at github.com (waja) Date: Wed, 12 Feb 2014 03:26:16 -0800 Subject: Show error if parameter incorrectly setted (percentage symbol) (#1237) In-Reply-To: References: Message-ID: This works as expected. From the help output: -w, --warning=INTEGER Exit with WARNING status if less than INTEGER units of disk are free -w, --warning=PERCENT% Exit with WARNING status if less than PERCENT of disk space is free -c, --critical=INTEGER Exit with CRITICAL status if less than INTEGER units of disk are free -c, --critical=PERCENT% Exit with CRITICAL status if less than PERCENT of disk space is free If you want to specify inode limits, you need to specify: -W, --iwarning=PERCENT% Exit with WARNING status if less than PERCENT of inode space is free -K, --icritical=PERCENT% Exit with CRITICAL status if less than PERCENT of inode space is free Cheers, Jan. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1237#issuecomment-34860005 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 12:26:17 2014 From: notifications at github.com (waja) Date: Wed, 12 Feb 2014 03:26:17 -0800 Subject: Show error if parameter incorrectly setted (percentage symbol) (#1237) In-Reply-To: References: Message-ID: Closed #1237. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1237 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 12:42:30 2014 From: notifications at github.com (waja) Date: Wed, 12 Feb 2014 03:42:30 -0800 Subject: Show error if parameter incorrectly setted (percentage symbol) (#1237) In-Reply-To: References: Message-ID: Reopened #1237. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1237 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 14:04:06 2014 From: notifications at github.com (=?UTF-8?B?QWRyacOhbg==?=) Date: Wed, 12 Feb 2014 05:04:06 -0800 Subject: Show error if parameter incorrectly setted (percentage symbol) (#1237) In-Reply-To: References: Message-ID: Yes, I know I set wrong the parameters, but maybe the check could give an error. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1237#issuecomment-34866488 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 12 15:20:11 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 12 Feb 2014 06:20:11 -0800 Subject: check_dig is case sensitive (#1233) In-Reply-To: References: Message-ID: Yes, we should add Gnulib's [`strcasestr`][1] module and apply that change, then. [1]: https://www.gnu.org/software/gnulib/manual/html_node/strcasestr.html -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1233#issuecomment-34872523 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 14 22:33:24 2014 From: notifications at github.com (awiddersheim) Date: Fri, 14 Feb 2014 13:33:24 -0800 Subject: Update check_icmp to use op5 version (#1238) Message-ID: Looks like check_icmp has been enhanced by the op5 team but those enhancements haven't made it back into the plugins project. http://git.op5.org/git/?p=nagios/op5plugins/check_icmp.git;a=blob;f=check_icmp.c;h=f559ea29c1991050519ab7093c3a7e1fe6606508;hb=HEAD Just briefly looking at the op5 version it has much better help output and when trying it the intervals work as one would expect. Perhaps it might be a good idea to pull in their version. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 16 21:44:32 2014 From: notifications at github.com (waja) Date: Sun, 16 Feb 2014 12:44:32 -0800 Subject: check_mysql: ignore authentication failure (#1178) In-Reply-To: References: Message-ID: Commited over there in n-p https://github.com/nagios-plugins/nagios-plugins/commit/7d04fc14ab66b86cac17c43c740e109474fa23e5 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1178#issuecomment-35211708 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 16 21:44:52 2014 From: notifications at github.com (waja) Date: Sun, 16 Feb 2014 12:44:52 -0800 Subject: check_mysql: ignore authentication failure [sf#3408602] (#1020) In-Reply-To: References: Message-ID: Commited over there in n-p https://github.com/nagios-plugins/nagios-plugins/commit/7d04fc14ab66b86cac17c43c740e109474fa23e5 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1020#issuecomment-35211717 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 16 22:11:43 2014 From: notifications at github.com (waja) Date: Sun, 16 Feb 2014 13:11:43 -0800 Subject: check_ntp_peer - Added specific state output for each metric. It now sho... (#1239) Message-ID: ...uld be easy to see which check caused the alert. Right from n-p there! You can merge this Pull Request by running: git pull https://github.com/waja/monitoring-plugins check_ntp_peer_metric Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1239 -- Commit Summary -- * check_ntp_peer - Added specific state output for each metric. It now should be easy to see which check caused the alert. -- File Changes -- M plugins/check_ntp_peer.c (49) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1239.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1239.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1239 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Feb 16 22:34:30 2014 From: notifications at github.com (waja) Date: Sun, 16 Feb 2014 13:34:30 -0800 Subject: check_ntp_peer - Added specific state output for each metric. It now sho... (#1239) In-Reply-To: References: Message-ID: Still lacking adjusted test cases... -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1239#issuecomment-35214380 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 18 15:17:23 2014 From: notifications at github.com (Seegras) Date: Tue, 18 Feb 2014 06:17:23 -0800 Subject: Make it possible for check_tcp to inhibit "TCP " in output (#1240) Message-ID: We've got the issue of having to check something from a remote server; which can easily be done like this in /etc/snmp/snmpd.conf extend connection /usr/lib/nagios/plugins/check_tcp -H -p 8080 And checking for check_snmp_extend!connection in icinga/nagios. Which would work but for TCP OK - 0.002 second response time on port 8080|time=0.002008s;;;0.000000;10.000000 That "TCP " in front of the OK. I loathe to make my own package; so I'd appreciate it if you just could add a flag to it to inhibit this. I can make a patch if you want one, but it's fairly trivial. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1240 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 18 19:57:22 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Tue, 18 Feb 2014 10:57:22 -0800 Subject: Make it possible for check_tcp to inhibit "TCP " in output (#1240) In-Reply-To: References: Message-ID: Wouldn't `sed(1)` do the trick? That is, a command line such as the following? command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 8080 | sed 's/^TCP //' -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1240#issuecomment-35419631 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattias.ryrlen at op5.com Tue Feb 18 20:50:12 2014 From: mattias.ryrlen at op5.com (=?ISO-8859-1?Q?Mattias_Ryrl=E9n?=) Date: Tue, 18 Feb 2014 20:50:12 +0100 Subject: Make it possible for check_tcp to inhibit "TCP " in output (#1240) In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 7:57 PM, Holger Wei? wrote: > Wouldn't sed(1) do the trick? That is, a command line such as the > following? > > command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 8080 | sed 's/^TCP //' > > then you need to track the original check_tcp exit code since the sed command would exit 0 or fail and that will be the status instead. > -- > Reply to this email on GitHub > . > -- V?nliga h?lsningar / Best Regards Mattias Ryrl?n __________________________ op5 AB F?rsta L?nggatan 19 SE-413 27 G?teborg Mobil: +46 735-17 70 99 Support: +46 31-774 09 24 www.op5.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 18 20:56:59 2014 From: notifications at github.com (Pall Sigurdsson) Date: Tue, 18 Feb 2014 11:56:59 -0800 Subject: Make it possible for check_tcp to inhibit "TCP " in output (#1240) In-Reply-To: References: Message-ID: > Wouldn't sed(1) do the trick? It would, but be carefully with the pipes, the exit code of the command, will be the exit code from the last command in the pipe :) -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1240#issuecomment-35426226 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Feb 18 21:02:54 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Tue, 18 Feb 2014 12:02:54 -0800 Subject: Make it possible for check_tcp to inhibit "TCP " in output (#1240) In-Reply-To: References: Message-ID: > It would, but be carefully with the pipes, the exit code of the command, > will be the exit code from the last command in the pipe :) Er, indeed. So you'd need a little wrapper script. Oh well, I'm not against such an option. (I'd really prefer to get rid of this first output field [in other plugins as well][1], but I guess that's somewhat unrelated.) [1]: http://thread.gmane.org/gmane.network.nagios.plugins.devel/5155 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1240#issuecomment-35426841 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 19 14:06:09 2014 From: notifications at github.com (=?UTF-8?B?QW50b24gTMO2ZmdyZW4=?=) Date: Wed, 19 Feb 2014 05:06:09 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: If @weiss or someone else from the monitoring-plugins team could have a look at our fork and make a statement on what (if not everything) would be a good idea to upstream - I'd be happy to do the legwork of constructing the necessary PR's. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35496810 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 19 14:46:42 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 19 Feb 2014 05:46:42 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: Ah sorry, I had only commented on IRC. Thanks a lot for your offer! >From what I saw, Andreas imported some version of `check_icmp` into the op5 repository early in 2007. Comparing that to our version from that time resulted in a >1000 line diff. Since then, 11 commits were applied to the op5 version, and something like 35 to ours, IIRC. So, comparing our versions doesn't seem totally trivial. I was going to take a closer look, at least at those 11 commits, but didn't get to it yet. I'm happy about any concrete suggestions as to what we should pull, of course! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35499831 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 19 15:18:05 2014 From: notifications at github.com (=?UTF-8?B?QW50b24gTMO2ZmdyZW4=?=) Date: Wed, 19 Feb 2014 06:18:05 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: I agree, it's definitely not trivial and, even though I'm not clear as to why, I think it's unfortunate that they've diverged. How about you have a look at ours and see if there's something you definitiely do not want and vice versa? For an obvious example, I guess you don't care much about redirecting users to the op5-users mailing list for support. Hopefully, we'll be able to reach some sort of consensus on what we want the final result (or at least a good approximation of it) to look like and I'll do my best to patch up the history from both repos. In the best of worlds, that'd allow us to kill off our fork entirely and just ship the upstream version to the benefit of everyone involved. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35502617 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 19 15:39:04 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 19 Feb 2014 06:39:04 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: > How about you have a look at ours and see if there's something you > definitiely do not want and vice versa? Sounds like a plan. Basically, I think we want everything that looks like it makes the world a better place :-) We obviously don't want to loose previous fixes of ours; `cd plugins-root; perl t/check_icmp.t` shouldn't break; and for extra happiness, new stuff should come with new test cases where it makes sense. I went through your commit messages (and some of the commit diffs) and they all look good to me (except for the obvious contact information changes you mentioned). I didn't look through the initial diff yet ... -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35504658 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 19 17:34:37 2014 From: notifications at github.com (awiddersheim) Date: Wed, 19 Feb 2014 08:34:37 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: I mentioned to @weiss on IRC a few days ago when I initially created this issue that I was willing to help on making this better but @catharsis is probably much more qualified to do this than I am. Either way the offer still stands if you want to throw some work my way. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35518138 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 20 14:24:16 2014 From: notifications at github.com (=?UTF-8?B?QW50b24gTMO2ZmdyZW4=?=) Date: Thu, 20 Feb 2014 05:24:16 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: Sounds like I should join that channel. :-) @awiddersheim Awesome! I'll give a shout if something comes up. Though I'm guessing it'll mostly be grunt work related to figuring out who did what when, and why and somehow putting the pieces together in a way that makes everyone happy. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-35620445 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 26 08:22:19 2014 From: notifications at github.com (Evgeni Golov) Date: Tue, 25 Feb 2014 23:22:19 -0800 Subject: use FindBin instead of awk to find the path to utils.pm (#1241) Message-ID: 'use lib utils.pm' is not valid Perl syntax: Bareword "utils" not allowed while "strict subs" in use at plugins-scripts/check_ircd.pl line 52. Bareword "pm" not allowed while "strict subs" in use at plugins-scripts/check_ircd.pl line 52. This makes it impossible to use the plugins directly from the git tree, e.g. while hacking on them. Using `FindBin::Bin` as the library path allows that, while preserving the original behaviour of adding the `libexec` path when the plugin is properly installed. You can merge this Pull Request by running: git pull https://github.com/evgeni/monitoring-plugins findbin Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1241 -- Commit Summary -- * use FindBin instead of awk to find the path to utils.pm -- File Changes -- M plugins-scripts/check_breeze.pl (3) M plugins-scripts/check_disk_smb.pl (3) M plugins-scripts/check_flexlm.pl (3) M plugins-scripts/check_ifoperstatus.pl (3) M plugins-scripts/check_ifstatus.pl (3) M plugins-scripts/check_ircd.pl (3) M plugins-scripts/check_mailq.pl (3) M plugins-scripts/check_netdns.pl (3) M plugins-scripts/check_rpc.pl (3) M plugins-scripts/check_wave.pl (3) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1241.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1241.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1241 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Feb 26 08:25:50 2014 From: notifications at github.com (Evgeni Golov) Date: Tue, 25 Feb 2014 23:25:50 -0800 Subject: use FindBin instead of awk to find the path to utils.pm (#1241) In-Reply-To: References: Message-ID: Thinking further, the following can now be removed from `subst.in`: # add to libexecdir to INC for perl utils.pm /^use/ { if (/lib/) { if (/utils.pm|"."/ ) {sub(/utils.pm|"."/,led() )} } } Removing this would stop new contributions from accidentally using it again. The whole `led()` function could be then removed too. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1241#issuecomment-36098237 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 20:05:31 2014 From: notifications at github.com (Evgeni Golov) Date: Thu, 27 Feb 2014 11:05:31 -0800 Subject: automatic mta detection (#1242) Message-ID: Try to autodetect which mailq implementation we are using 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. You can merge this Pull Request by running: git pull https://github.com/evgeni/monitoring-plugins automatic_mta Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242 -- Commit Summary -- * try to autodetect which mailq implementation we are using * document autodetection in the usage output * add $mailq to check output, so it is easily visible what was autodetected -- File Changes -- M plugins-scripts/check_mailq.pl (63) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1242.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1242.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 20:55:22 2014 From: notifications at github.com (waja) Date: Thu, 27 Feb 2014 11:55:22 -0800 Subject: automatic mta detection (#1242) In-Reply-To: References: Message-ID: Closed #1242. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 20:59:56 2014 From: notifications at github.com (waja) Date: Thu, 27 Feb 2014 11:59:56 -0800 Subject: use FindBin instead of awk to find the path to utils.pm (#1241) In-Reply-To: References: Message-ID: Closed #1241 via 2d49468a2533c4623d4121ee0e12260bcba78905. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1241 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 21:43:46 2014 From: notifications at github.com (waja) Date: Thu, 27 Feb 2014 12:43:46 -0800 Subject: automatic mta detection (#1242) In-Reply-To: References: Message-ID: Compiling with mawk 'make install' failes with: NP_VERSION=1.5.110.g2d494 mawk -f ./subst check_mailq.pl > check_mailq mawk: run time error: regular expression compile failed (missing operand) /var/lib/postfix' || -d '/var/local/lib/postfix FILENAME="check_mailq.pl" FNR=614 NR=614 make[1]: *** [check_mailq] Error 2 make[1]: Leaving directory `/home/holger/src/monitoring-plugins/plugins-scripts' make: *** [install-recursive] Error 1 The problem seems: https://github.com/monitoring-plugins/monitoring-plugins/blob/2d49468a2533c4623d4121ee0e12260bcba78905/plugins-scripts/subst.in#L43 -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242#issuecomment-36288975 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 21:43:46 2014 From: notifications at github.com (waja) Date: Thu, 27 Feb 2014 12:43:46 -0800 Subject: automatic mta detection (#1242) In-Reply-To: References: Message-ID: Reopened #1242. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Feb 27 21:44:43 2014 From: notifications at github.com (Evgeni Golov) Date: Thu, 27 Feb 2014 12:44:43 -0800 Subject: use 'or' instead of '||' as operator (#1243) Message-ID: this fixes a stupid FTBFS with mawk which thinks our file contains regex: NP_VERSION=1.5.110.g2d494 mawk -f ./subst check_mailq.pl > check_mailq mawk: run time error: regular expression compile failed (missing operand) /var/lib/postfix' || -d '/var/local/lib/postfix FILENAME="check_mailq.pl" FNR=614 NR=614 make[2]: *** [check_mailq] Error 2 You can merge this Pull Request by running: git pull https://github.com/evgeni/monitoring-plugins stupid-mawk Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1243 -- Commit Summary -- * use 'or' instead of '||' as operator -- File Changes -- M plugins-scripts/check_mailq.pl (14) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1243.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1243.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 28 09:12:27 2014 From: notifications at github.com (Evgeni Golov) Date: Fri, 28 Feb 2014 00:12:27 -0800 Subject: use 'or' instead of '||' as operator (#1243) In-Reply-To: References: Message-ID: that one is wrong, ignore it please. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1243#issuecomment-36329641 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 28 09:12:27 2014 From: notifications at github.com (Evgeni Golov) Date: Fri, 28 Feb 2014 00:12:27 -0800 Subject: use 'or' instead of '||' as operator (#1243) In-Reply-To: References: Message-ID: Closed #1243. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 28 13:29:51 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Fri, 28 Feb 2014 04:29:51 -0800 Subject: Fix trusted path (#1212) In-Reply-To: References: Message-ID: Closed #1212 via e260efb25690b13002a0bf432507f66bdad90f02. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1212 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Feb 28 13:29:51 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Fri, 28 Feb 2014 04:29:51 -0800 Subject: automatic mta detection (#1242) In-Reply-To: References: Message-ID: Closed #1242 via c08d6a429ba0e0cd3642ba2c2fe85687472ee22f. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1242 -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.januschka at krone.at Fri Feb 28 19:51:53 2014 From: h.januschka at krone.at (Helmut W. Januschka) Date: Fri, 28 Feb 2014 19:51:53 +0100 Subject: Fix trusted path (#1212) In-Reply-To: References: Message-ID: unsubscribe