From notifications at github.com Sun Mar 2 00:45:50 2014 From: notifications at github.com (Lars Vogdt) Date: Sat, 01 Mar 2014 15:45:50 -0800 Subject: Rewrite of check_ircd (#1244) Message-ID: Hi I did a rewrite of the check_ircd.pl script to allow SSL connections and provide some perfdata. Please review and tell me what you think... With kind regards, Lars You can merge this Pull Request by running: git pull https://github.com/lrupp/monitoring-plugins maint Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244 -- Commit Summary -- * fix outdated Free Software Foundation address * Rewrite of check_ircd.pl -- File Changes -- M plugins-scripts/check_file_age.pl (2) M plugins-scripts/check_ifoperstatus.pl (3) M plugins-scripts/check_ifstatus.pl (2) M plugins-scripts/check_ircd.pl (355) M plugins-scripts/check_mailq.pl (4) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1244.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1244.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Mar 2 03:19:01 2014 From: notifications at github.com (Sam Kottler) Date: Sat, 01 Mar 2014 18:19:01 -0800 Subject: Rewrite of check_ircd (#1244) In-Reply-To: References: Message-ID: @lrupp would you mind moving the FSF address changes to a separate PR? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244#issuecomment-36443775 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Mar 2 04:51:48 2014 From: notifications at github.com (Lars Vogdt) Date: Sat, 01 Mar 2014 19:51:48 -0800 Subject: Rewrite of check_ircd (#1244) In-Reply-To: References: Message-ID: Oh, no problem, sorry. That was old work.... -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244#issuecomment-36445277 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Mar 2 10:34:46 2014 From: notifications at github.com (waja) Date: Sun, 02 Mar 2014 01:34:46 -0800 Subject: Rewrite of check_ircd (#1244) In-Reply-To: References: Message-ID: Oh ... I just can merge 66c666420d119f24273e295600edab1cd13a0b76! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244#issuecomment-36450038 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Mar 2 10:45:44 2014 From: notifications at github.com (waja) Date: Sun, 02 Mar 2014 01:45:44 -0800 Subject: Rewrite of check_ircd (#1244) In-Reply-To: References: Message-ID: This 66c666420d119f24273e295600edab1cd13a0b76 is already merged with 42e77f9f51fe1665236cd3c750eec7e86c8650eb! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1244#issuecomment-36450199 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 6 15:54:40 2014 From: notifications at github.com (=?UTF-8?B?QW50b24gTMO2ZmdyZW4=?=) Date: Thu, 06 Mar 2014 06:54:40 -0800 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: I took a look at this today. It seems there's a whole lot of history missing, unfortunately. And I'm unable to find anything close to a common point in history for the two repositories. I've asked Andreas about it, and he figures it might be the case that he had the missing history locally on a laptop at some point in time. In other words, I think we have to consider the chances of getting a clean history pretty slim. I would suggest simply extracting and applying the desirable changes by hand. Though this of course requires a more thorough examination of what changes are desirable. I'm not familiar enough with the plugin to make any suggestions on this myself, but maybe @awiddersheim is (seeing as how he opened the issue with specific suggestions in the first place)? Still, I'd be happy to help out in the "porting" part, or general discussion, if needed. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-36895048 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Mar 11 11:38:14 2014 From: notifications at github.com (=?UTF-8?B?QW50b24gTMO2ZmdyZW4=?=) Date: Tue, 11 Mar 2014 03:38:14 -0700 Subject: check_snmp: Handle SNMPv3 noAuthNoPriv properly (#1245) Message-ID: The SNMPv3 noAuthNoPriv security level, somewhat unintuitively, requires a security name to be passed along together with the request. Check_snmp previously did not do this, causing snmpget to throw an error: "External command error: No log handling enabled - turning on stderr logging snmpget: No securityName specified" This patch fixes the issue by always providing the security name when noAuthNoPriv is specified. See also: https:://bugs.op5.com/view.php?id=8385. Signed-off-by: Anton Lofgren <alofgren at op5.com> You can merge this Pull Request by running: git pull https://github.com/catharsis/nagios-plugins check-snmp-noauthnopriv Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1245 -- Commit Summary -- * check_snmp: Handle SNMPv3 noAuthNoPriv properly -- File Changes -- M plugins/check_snmp.c (10) M plugins/t/check_snmp.t (11) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1245.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1245.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1245 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Mar 12 03:53:54 2014 From: notifications at github.com (awiddersheim) Date: Tue, 11 Mar 2014 19:53:54 -0700 Subject: Update check_icmp to use op5 version (#1238) In-Reply-To: References: Message-ID: @catharsis sorry for the late response. Been quite busy as of late. Thanks for starting to look at this. I originally had issues with the intervals using the monitoring-plugins version and the help that it gives isn't actually very helpful when it comes to explaining what the intervals do. If you download the two and run it with various `i` and `I` options and look at the help output you'll see what I'm talking about. That was the main factor that drove me to find that the op5 version was different/better in that area. Again, I haven't looked at the plugin or code very closely outside of those two things but I'd imagine there are probably other bugs that would be worth fixing and having in the monitoring-plugins version. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1238#issuecomment-37370747 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 13 14:40:33 2014 From: notifications at github.com (langemeijer) Date: Thu, 13 Mar 2014 06:40:33 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) Message-ID: Connection timeout will result in warning status instead of critical I want to compare my servers to a time server not in my control. When for an unknown reason the time server is not responding for me that is not actionable. You can merge this Pull Request by running: git pull https://github.com/langemeijer/monitoring-plugins master Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246 -- Commit Summary -- * Add commandline -T switch to check_time and check_ntp_time -- File Changes -- M plugins/check_ntp_time.c (10) M plugins/check_time.c (11) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1246.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1246.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 09:27:41 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 20 Mar 2014 01:27:41 -0700 Subject: Update the last remaining instance of the old FSF address (#1247) Message-ID: You can merge this Pull Request by running: git pull https://github.com/skottler/monitoring-plugins mssql_fsf_address Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1247 -- Commit Summary -- * Update the last remaining instance of the old FSF address -- File Changes -- M plugins-scripts/check_mssql.pl (2) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1247.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1247.diff -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 10:03:58 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Thu, 20 Mar 2014 02:03:58 -0700 Subject: Update the last remaining instance of the old FSF address (#1247) In-Reply-To: References: Message-ID: Thanks! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1247#issuecomment-38146303 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 10:04:02 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Thu, 20 Mar 2014 02:04:02 -0700 Subject: Update the last remaining instance of the old FSF address (#1247) In-Reply-To: References: Message-ID: Closed #1247. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1247 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 10:07:33 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 20 Mar 2014 02:07:33 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: :+1: works well for me. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38146535 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 10:11:02 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 20 Mar 2014 02:11:02 -0700 Subject: Warning fixes (#1227) In-Reply-To: References: Message-ID: Any update on this @ricardomaraschini? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1227#issuecomment-38146753 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 10:13:35 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 20 Mar 2014 02:13:35 -0700 Subject: Add support for drill tool to check_dig (#1218) In-Reply-To: References: Message-ID: @abgandar I think it makes sense for monitoring-plugins to include the patch. Do you want to submit a pull request with it or should I do that? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1218#issuecomment-38146936 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 11:42:31 2014 From: notifications at github.com (waja) Date: Thu, 20 Mar 2014 03:42:31 -0700 Subject: fix the path names (s/nagios/monitoring/) (#1248) Message-ID: -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1248 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 20 11:49:37 2014 From: notifications at github.com (waja) Date: Thu, 20 Mar 2014 03:49:37 -0700 Subject: potential issues related to Extra-Opts, and to State Retention (#1249) Message-ID: maybe revert 49ae05ff1ce so that --extra-opts won't be enabled by default yet In Debian for example we ship with '--enable-extra-opts'. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1249 -------------- next part -------------- An HTML attachment was scrubbed... URL: From waja at cyconet.org Thu Mar 20 12:38:32 2014 From: waja at cyconet.org (Jan Wagner) Date: Thu, 20 Mar 2014 12:38:32 +0100 Subject: Propose of new version scheme Message-ID: <532AD338.8090509@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi there, you may have noticed, nagios-plugins released a new version, which has a tag of a new major release (2.0). This looks like they are trying to start a version number competition. I`m proposing a new version scheme which could look like: .[.bugfixrelease] If you think this looks very familiar ... yes it`s used by ubuntu and may others. What maybe the benefits of a complete different release scheme: * there will probably no version number races between existing forks (which is totally nonsense) * we can better identify, if a plugin is from our fork or no - this might help when we get bugreports/complaints, especially when forks are more diversing on code base Just my 2 euro cents. Have a nice day, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTKtM4AAoJEAxwVXtaBlE+7R8P/iXnVQARQFI7Si5Nm/Cv+l3a vXDdIR7VBdTow+nFQ5rlPOmoE555q+atqr0fljRGanFdNsMwaNo5PWsmQDT/5cNp Uq+59jVkZHtJ5KvUtwrO9Mhsiry0AmHDGvlV4UfLg0n/wqe3ef7xBwi7JsjaR3ln qbPFTCN9Rod7Y88Ro6NLfRfX//cUWVES+v2nqjT7B6luL+TR/Oyq5CAzRtcga/FU vOJNx/+P3efW2nfYYG+Vh3YJzCE/KR2UOi5QAx2Oiii8q08Gu5IcrVywO8emV0en hecM/wdUkCrfou1v1EkHX5IzZyPYaSLrJqmupXT2WEVrLMv2MnD0dmnHkijoOThB QkuDLXyw27n/TP27g4TUER8reeNXyKMSZJbCLNFTewa9R3Xt/03y8DjB9JR8VRoW wmMs0m9OC5wBy/KokMfLXI7s2b7o4MKSeH2I6c4U98TFQwLtUKZFlK/a0Rouxa+q OCjZI8N1Rx6hagTfJyyMl3bIXu81XEPqCkJtT5aMeioZJE5aAc2BGc9RtS1fj+8A kgALdaYeCqqVhHYNlthUiGNMc6K+Fgcoi1mHxCHTSczOZ4HJsjTZ4o4Kw8xiqlQs zJs/vmSFatLgjslcxtyd6zVt1JEgE+tUaWR5z0PT/AJLCdM0OhZevBT/OKRVmuDS f3psjsaE5yt0AwlkVRK9 =15kD -----END PGP SIGNATURE----- From holger at zedat.fu-berlin.de Thu Mar 20 12:49:50 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 20 Mar 2014 12:49:50 +0100 Subject: Propose of new version scheme In-Reply-To: <532AD338.8090509@cyconet.org> References: <532AD338.8090509@cyconet.org> Message-ID: <20140320114950.GF140760@zedat.fu-berlin.de> * Jan Wagner [2014-03-20 12:38]: > I`m proposing a new version scheme which could look like: > > .[.bugfixrelease] > > If you think this looks very familiar ... yes it`s used by ubuntu and > may others. > > What maybe the benefits of a complete different release scheme: > > * there will probably no version number races between existing forks > (which is totally nonsense) > * we can better identify, if a plugin is from our fork or no > - this might help when we get bugreports/complaints, especially when > forks are more diversing on code base As you know, we currently have X.Y.Z, where Z is incremented for bug fix releases, Y for backwards-compatible feature releases, and X for backwards-incompatible releases.? The new scheme wouldn't allow for distinguishing the latter two, but I could live with that. I'm fine with either scheme. Holger ? https://www.monitoring-plugins.org/archive/devel/2013-August/008932.html From waja at cyconet.org Thu Mar 20 13:02:06 2014 From: waja at cyconet.org (Jan Wagner) Date: Thu, 20 Mar 2014 13:02:06 +0100 Subject: Propose of new version scheme In-Reply-To: <20140320114950.GF140760@zedat.fu-berlin.de> References: <532AD338.8090509@cyconet.org> <20140320114950.GF140760@zedat.fu-berlin.de> Message-ID: <532AD8BE.6060204@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 20.03.14 12:49, schrieb Holger Wei?: > * Jan Wagner [2014-03-20 12:38]: >> I`m proposing a new version scheme which could look like: >> >> .[.bugfixrelease] >> >> If you think this looks very familiar ... yes it`s used by ubuntu >> and may others. >> >> What maybe the benefits of a complete different release scheme: >> >> * there will probably no version number races between existing >> forks (which is totally nonsense) * we can better identify, if a >> plugin is from our fork or no - this might help when we get >> bugreports/complaints, especially when forks are more diversing >> on code base > > As you know, we currently have X.Y.Z, where Z is incremented for > bug fix releases, Y for backwards-compatible feature releases, and > X for backwards-incompatible releases.? The new scheme wouldn't > allow for distinguishing the latter two, but I could live with > that. I'm fine with either scheme. In Debian they are using an epoch. We chould implement that with: X..[.bugfixrelease] Where X stands for incompatible releases. No? :) - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTKti+AAoJEAxwVXtaBlE+a/MP/j5VX0/NxqQkT+vj91ru6n3X BovSfH+/pwbO/ezxu5OT6plxT8PH+4Hm3TvwtDzZQLjmoL4ZpVqueb1wtkEzOBlz VWzmEpfaiCif1HppFe2Ykwasn6pCphD/IErKneFS/e5J2tt/DzRgLhmxaa6n7aAP N9qyReaQTb3GR7SrblXQyBw01ROeKGQ8BCqAeU/GRMj1S6aeX1unK8NApcNDLs2U BrlAxN5rgUwpHkVJBZYBi/COD0LHaB/0XxVRh8DySCQs4SkezNX9t7yvsr3YPQgH kk5L03CBHyEVqoRnmqgQeWrM2OQZbfQOeWEs9QA8TCqink8GPhmZ2Tmg+c1H4OF6 ggfTgeDlD696Mc/7qObXUPPJlO1iixlEbvvvXdP0zx9F7gb7dgz0y8k2G6eCBuN/ EkbL9/4f03H4McH5/8KbDE3bdWgL8ce9Ft4fByvcQhqW19bTjhwcR3R9Sn2MxVVS q9z1ktB7RXR5cqkfnqmXmgqlOaa2gvv+DA2fq8SGRnSEIFgla7/lbUx2674l8AaO SySuuJXNUuQ9u7f4Ub/zXUUaEZmsiwsBCkXmsid0RwTV3JY0VRMZzlLVR7pFod3T T2+IYni8D2bix0KjN2jWaFibUHYDfaUFDzuEnvzgwbnU4KAGZbHtuFKa8fke7RT5 uA9Ahctbc2mcNVX4ftYH =zAw1 -----END PGP SIGNATURE----- From gynter at kits.ee Thu Mar 20 13:25:29 2014 From: gynter at kits.ee (=?ISO-8859-1?Q?G=FCnter_Kits?=) Date: Thu, 20 Mar 2014 14:25:29 +0200 Subject: Propose of new version scheme In-Reply-To: <532AD8BE.6060204@cyconet.org> References: <532AD338.8090509@cyconet.org> <20140320114950.GF140760@zedat.fu-berlin.de> <532AD8BE.6060204@cyconet.org> Message-ID: <532ADE39.4020001@kits.ee> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tere! IMHO versioning like Ubuntu has breaks everything what versioning stands for and I personally despise it. Versions are ment to be incremental, eg one does not simply go from 10.2 to 10.9. It think that You should continue with [Semantic Versioning][1] like the most of software development world does. [1]:http://semver.org/ - -- K?ike head soovides G?nter Kits On 20.03.2014 14:02, Jan Wagner wrote: > Am 20.03.14 12:49, schrieb Holger Wei?: >> * Jan Wagner [2014-03-20 12:38]: >>> I`m proposing a new version scheme which could look like: >>> >>> .[.bugfixrelease] >>> >>> If you think this looks very familiar ... yes it`s used by >>> ubuntu and may others. >>> >>> What maybe the benefits of a complete different release >>> scheme: >>> >>> * there will probably no version number races between existing >>> forks (which is totally nonsense) * we can better identify, if >>> a plugin is from our fork or no - this might help when we get >>> bugreports/complaints, especially when forks are more >>> diversing on code base > >> As you know, we currently have X.Y.Z, where Z is incremented for >> bug fix releases, Y for backwards-compatible feature releases, >> and X for backwards-incompatible releases.? The new scheme >> wouldn't allow for distinguishing the latter two, but I could >> live with that. I'm fine with either scheme. > > In Debian they are using an epoch. > > We chould implement that with: > > X..[.bugfixrelease] > > Where X stands for incompatible releases. > > No? :) > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTKt45AAoJEFnfbS9fXrweGNUQAMDvmECCkbV404vHZlM6OJf+ hGaEvXzXo8+FzUcmEG0oFI7xVrcr9hRrB7jSgV9fynJ/7cELpiBg0msLpdnvxIci qVwT3VZwy8T2urt+0W+AGW+4CKHey7pUOOAif1ykemXcKf6SSnPG1VCfwxP3ETbB qm1Ne7mwFLV1quYuaFEjexHARcpnmOicMV2jajqtIhvtuw5St/dPKggsaYP7/oMX Ts5ZD0Yf/s0D0ZZ6AtPVSr9EOeDFM58nwp7Cavfctd8jmyLdw7ZKqBCrMC2rQ9L4 x8fZBwq83E3s4NRaUMCXtwFYFOBm/f3zUrAIS3tV16kpmq768bkeO16iIEmFZMWR WC3z8gUkwWTKDySXd/iibTPcewq6h8IlVlCRTVOncs+AbhC0U3CegOxwl2isyuPq PIzHXYZi7XB5He08J99tdgP/6UkctXJsRsYca+bj9loh16IaAYP9DLOn3hBGEDYL oVWUGLpViV3TUSIRQQpDnbne11NYMkWOm2hKLflMQ99xxkEDsJneFYzamQ6wdW1G wMrwic1VXJ9PuE46ASoSFc1O/D/3p4j908VvwnyfvDz9CPQdcgSzeeVmPhT4kkui 8UVf+PxtX7dNQYpSrQdhVPyk0gfdQeWJIudzvCXCsNF8G8aUj5ZjnI6NLPXdFvbT Opq5jTwLcC5j/vhwdlo0 =4Sq5 -----END PGP SIGNATURE----- From michael.friedrich at gmail.com Thu Mar 20 14:03:02 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Thu, 20 Mar 2014 14:03:02 +0100 Subject: Propose of new version scheme In-Reply-To: <532AD338.8090509@cyconet.org> References: <532AD338.8090509@cyconet.org> Message-ID: <532AE706.2010309@gmail.com> On 20.03.2014 12:38, Jan Wagner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi there, > > you may have noticed, nagios-plugins released a new version, which has > a tag of a new major release (2.0). This looks like they are trying to > start a version number competition. > > I`m proposing a new version scheme which could look like: > > .[.bugfixrelease] > > If you think this looks very familiar ... yes it`s used by ubuntu and > may others. > > What maybe the benefits of a complete different release scheme: > > * there will probably no version number races between existing forks > (which is totally nonsense) > * we can better identify, if a plugin is from our fork or no > - this might help when we get bugreports/complaints, especially when > forks are more diversing on code base Please please please don't change the version schema! Users won't recognize the new schema, and you will have to explain it every time they install it (not everyone uses packages these days). And if it's not you, everyone doing community support with nagios/icinga/shinken/naemon will have to. Furthermore all existing scripts/documentation/howtos/{puppet,chef,ansible,...}modules will require additional changes. Make it 1.6.x and focus on a quality release. Bumping something to 2.0 just because it was forked and being an attention whore (pardon) is imho the wrong way. kind regards, Michael PS: Ubuntu is imho a bad example. -- DI (FH) Michael Friedrich michael.friedrich at gmail.com || icinga open source monitoring https://twitter.com/dnsmichi || lead core developer dnsmichi at jabber.ccc.de || https://www.icinga.org/team irc.freenode.net/icinga || dnsmichi From waja at cyconet.org Thu Mar 20 14:16:43 2014 From: waja at cyconet.org (Jan Wagner) Date: Thu, 20 Mar 2014 14:16:43 +0100 Subject: Propose of new version scheme In-Reply-To: <532AE706.2010309@gmail.com> References: <532AD338.8090509@cyconet.org> <532AE706.2010309@gmail.com> Message-ID: <532AEA3B.4010700@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Michael, Am 20.03.14 14:03, schrieb Michael Friedrich: > Bumping something to 2.0 just because it was forked and being an > attention whore (pardon) is imho the wrong way. my focus is more on the "he .. I have here a check_tcp version 2.1 which acts badly" and when we anytime will have a 2.1 release (any maybe forks too). this will lead into confusion as this check_tcp is completly different between the forks. Anyways .. I`m not stuck to this year.month thing, but I would prefer a diverting scheme. Cheers, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTKuo6AAoJEAxwVXtaBlE+DE4P/1LMJr9oWewirq+Qj/zns4xU IjfMa8je+keRFqMlHPTtHOfKxLsTTJPCrlwIN9jWrxlgRm3HgfBfZnVMcDqC8awd 6daUPc6QJrMAAuePd902S2A71CkNfR5kWNPhFiGqcD6PLUajbo2KoFx0aeW4Cd8J d/7DpTCAOKlD3onorw6bKmpPnCbabZvwwNF8QXRDCgi38OCh1AP9yHemD0ud/fKm kZqEEzXHKOQuJBQPOr+DvLywSngPKt1znSunOK6GqecKh04ZL2AhgHG8Rqj1QtT8 IEisanNMHD42MqFbAsJTyRRKumXGA9PPamBX9xte9h0eBICQw+9wOMvp9iyjcxnc kKpT8H71d5XcapVfOj3FLxyX/czJPJyONu4/zLRMCuhyunp2Lna8S+5PCwbQTUyw gm2e+CA4enQMzkvlQhoKIFx+Ej+DtLqLajln3ZRltLCDKjMebzVLBsbZNHMNtXdz wm55k4C2TnxwUOTvcocecMtK/Varg+BcZGwh1iEK8qM+JN36n61liY4VfceMQs47 WXyfwLWu6mVkuN9TZTW/3RHXnoHgw1i+uIImXGaLdWpmS4FWYkN8vY5syEAjYdyA bUo0i8Fn3H09zhRsYIKQ8sD88ow+8ceH1RC+StjTa/chAdwSaNJD1+48NKF8ppfd by3+vw0jiiNNvLz+lBRf =Xt6O -----END PGP SIGNATURE----- From Jochen.Bern at LINworks.de Thu Mar 20 16:04:02 2014 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Thu, 20 Mar 2014 16:04:02 +0100 Subject: Propose of new version scheme In-Reply-To: <532AEA3B.4010700@cyconet.org> References: <532AD338.8090509@cyconet.org> <532AE706.2010309@gmail.com> <532AEA3B.4010700@cyconet.org> Message-ID: <532B0362.2050403@LINworks.de> On 20.03.2014 14:16, Jan Wagner wrote: > Anyways .. I`m not stuck to this year.month thing, but I would prefer > a diverting scheme. Changing the major "number" to letters in alphabetical order or codenames beginning with them, then? Or are there package management tools which can't work with that? 1.5 -> Aluminum.5 2.0 -> Boron.0 3.1.41 -> Chrome.1.41 4.7.11 -> Darmstadtium.7.11 etc. etc.. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From notifications at github.com Thu Mar 20 16:20:52 2014 From: notifications at github.com (langemeijer) Date: Thu, 20 Mar 2014 08:20:52 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: My usage is /path/to/check_time -H ntp.xs4all.nl --warning-variance=2 --critical-variance=60 --timeout-warning > 60 seconds time diff: CRITICAL > 2 seconds time diff: WARNING server ntp.xs4all.nl unavailable: WARNING (not critical) Will your negate command have the same behaviour? isn't it negating the result? OK<->CRITICAL? Even if it works, I'm not sure if I like your solution. It's not very obvious what is does, my solution seems more self-documenting. As for the generic solution: The time server being used, is NOT the time server being watched. There are not many tests where a host is used that is not the primary target for the test. check_http tests a http server and it's response. A timeout on this test is an issue that can be dealt with. I doubt a --timeout-warning commandline switch would be useful on other tests. In fact: I had the code for it in other checks, thought about it, and removed it for this pull request. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38179972 -------------- next part -------------- An HTML attachment was scrubbed... URL: From smutel at monitoring-fr.org Thu Mar 20 17:26:58 2014 From: smutel at monitoring-fr.org (Samuel Mutel) Date: Thu, 20 Mar 2014 17:26:58 +0100 (CET) Subject: Timeout bug with check_snmp In-Reply-To: <3a07b0cc-28de-4ef0-aa7b-8af7ab772c94@mail> Message-ID: <224ab4b3-324d-46f6-8cb1-b78232d90034@mail> Hello, I currently use nagios plugin version 1.4.16. Do you know if the bug below is already corrected in your release ? The timeout parameter is not correctly used by plugin check_snmp. Below the timeout is set to 30 seconds. The time command returns 3 minutes. time ./check_snmp -H X.X.X.X -o .1.3.6.1.4.1.9.2.1.58.0 -t 30 -w 100 -c 100 -l value External command error: Timeout: No Response from 10.82.0.49:161. real 3m0.010s user 0m0.003s sys 0m0.002s Regards, Samuel Mutel. From gynter at kits.ee Thu Mar 20 16:06:17 2014 From: gynter at kits.ee (=?ISO-8859-15?Q?G=FCnter_Kits?=) Date: Thu, 20 Mar 2014 17:06:17 +0200 Subject: Propose of new version scheme In-Reply-To: <532B0362.2050403@LINworks.de> References: <532AD338.8090509@cyconet.org> <532AE706.2010309@gmail.com> <532AEA3B.4010700@cyconet.org> <532B0362.2050403@LINworks.de> Message-ID: <532B03E9.3060102@kits.ee> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, This would be extremely pain in the ass for scripts to do automatical version comparison. - -- Best regards, G?nter Kits On 20.03.2014 17:04, Jochen Bern wrote: > On 20.03.2014 14:16, Jan Wagner wrote: >> Anyways .. I`m not stuck to this year.month thing, but I would >> prefer a diverting scheme. > > Changing the major "number" to letters in alphabetical order or > codenames beginning with them, then? Or are there package > management tools which can't work with that? > > 1.5 -> Aluminum.5 2.0 -> Boron.0 3.1.41 -> Chrome.1.41 4.7.11 > -> Darmstadtium.7.11 > > etc. etc.. > > Regards, J. Bern > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTKwPpAAoJEFnfbS9fXrwearYQAL1Cgk6GsQAgo7vpHz21JCF6 5GMBgJ36j7LW7mKs23aHVMpSFF87ywKHg1k3q+N9jb7/LAZ1f9+uyX/Yy40ej7in tgqjqRB+98UKbSoV+nQ/B1pRy8/JpjznZZ1wgnqaQALcGdbCEUiGNP2k4lxT8EBQ nQzOb1diL5fhiAqsjHJk0XftfBkWvoKkaLVvhE0Fj6z/t3PDn0Lz7nrKlLZWbxvo 3WcHe6t3aCt5yYS7ZaT6d6NoNbzBnhtmaXTUg0zQEUoaKsIRIhuKmBCptJsARC4N 4M87uWIe4cv5BthcSAUKBDDjjS2ZoI95HpXVBi9gTMuL8mTsWZKFJs7k8tfmxUAO wsON+StFFw8hZO1hn2h7Kc3xWEjqcP7zktZjDRtUv6xuaxZfUxZDWanhoQFimEWQ V8ZtzYtZxPE/NBXxDm9VWB6Wp4uNHUIEqdZpI9YYDfsA+E++faFFJul9AEOgR8hj xdvxh8QsLJpNySHOPeK5xLHkGjQ4/gRBZqjq/eUzPVPS2Ep1hjnlDdzNied0MjxT OGskaz7zGHhqrzoPjdfOEhAwWA6ZDpD25xUnO8vy5uWKBrxHnH4ZytVkttbKRPSW 9BSmvG4JmuS0U2poKupalcMhHFf99kfUOuifz7CFA6mphmpgYTUDVIdciyQ0+QXQ hW1K21A5IKTvfEJmX6aA =bNmB -----END PGP SIGNATURE----- From Jochen.Bern at LINworks.de Thu Mar 20 23:32:15 2014 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Thu, 20 Mar 2014 23:32:15 +0100 Subject: Propose of new version scheme In-Reply-To: <532B03E9.3060102@kits.ee> References: <532AD338.8090509@cyconet.org> <532AE706.2010309@gmail.com> <532AEA3B.4010700@cyconet.org> <532B0362.2050403@LINworks.de> <532B03E9.3060102@kits.ee> Message-ID: <532B6C6F.1090200@LINworks.de> On 20.03.2014 16:06, G?nter Kits wrote: > This would be extremely pain in the ass for scripts to do automatical > version comparison. > > On 20.03.2014 17:04, Jochen Bern wrote: >> > Changing the major "number" to letters in alphabetical order or >> > codenames beginning with them, then? Or are there package >> > management tools which can't work with that? >> > >> > 1.5 -> Aluminum.5 >> > 2.0 -> Boron.0 >> > 3.1.41 -> Chrome.1.41 >> > 4.7.11 -> Darmstadtium.7.11 >> > etc. etc.. As painful as normalizing the leading A..Z back to a number before doing comparisons, but OK. So we're stuck with '^[0-9][0-9]*\.[0-9][0-9]*(|\.[0-9][0-9]*)$' and only increasing every number unless reset? Increasing by *one*, specifically? Forbid leading zeros, just in case someone's doing the traditional octal notation recognition? Still no prob. Pick one of the mandatory numeral parts and decree that it shall count from 100 or 1000 up, rather than from 0 or 1. (Make it 100, rather than 1000, if you think you might still run into machines with single-byte integers. ;-) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From notifications at github.com Thu Mar 20 23:57:42 2014 From: notifications at github.com (Alexander Wittig) Date: Thu, 20 Mar 2014 15:57:42 -0700 Subject: Add support for drill tool to check_dig (#1218) In-Reply-To: References: Message-ID: @skottler I thought I already submitted this as a pull request 3 months ago, but the montitoring-plugins guys didn't like it. I'm not very familiar with git and github, so if I did it wrong please feel free to submit it properly so it can be included upstream (which was my main intent in the first place, patching it in the FreeBSD ports is not the right way to fix this) -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1218#issuecomment-38231224 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Mar 21 10:51:23 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Fri, 21 Mar 2014 02:51:23 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: > My usage is [...]. Will your negate command have the same behaviour? Yes. > isn't it negating the result? OK<->CRITICAL? That's what `negate` does by default, but not when using the command line options I suggested. > The time server being used, is NOT the time server being watched. There > are not many tests where a host is used that is not the primary target for > the test. Ah, good point. With this reasoning, I guess the correct™ exit code would be `UNKNOWN`. Maybe these plugins should've returned that in the first place. However, it might now be better to make this configurable indeed. So, I'm fine with merging your change. We should just add a test case. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38261367 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Mar 21 10:56:08 2014 From: notifications at github.com (langemeijer) Date: Fri, 21 Mar 2014 02:56:08 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: If UNKNOWN would be the correct state, how about a parameter that accepts an exit state? The same way -T WARNING works for negate, and defaults to UNKNOWN? I'm happy to do the work. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38261698 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Mar 21 10:58:31 2014 From: notifications at github.com (langemeijer) Date: Fri, 21 Mar 2014 02:58:31 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: I'm happy to contribute a test too. I'm assuming there are some other test that can guide me in the right direction. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38261876 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Mar 21 11:03:26 2014 From: notifications at github.com (langemeijer) Date: Fri, 21 Mar 2014 03:03:26 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: I'm watching about 50 servers. When ntp.xs4all.nl was unreachable I got 50 text messages. I can't really imagine someone using check_time or check_ntp_time and ever want a CRITICAL when a time server is unavailable. But I guess changing the default behaviour is too much. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38262217 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Mar 21 11:05:02 2014 From: notifications at github.com (langemeijer) Date: Fri, 21 Mar 2014 03:05:02 -0700 Subject: Add commandline -T switch to check_time and check_ntp_time (#1246) In-Reply-To: References: Message-ID: Let me have a stab at it. I'll make some time next week. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1246#issuecomment-38262342 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 12:27:24 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 04:27:24 -0700 Subject: check_oracle: --tns bad string matching (#1191) In-Reply-To: References: Message-ID: Looks good. :+1: -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1191#issuecomment-38791903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 12:33:43 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 04:33:43 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: @awiddersheim sorry it took so long for this to get reviewed. Doesn't this patch prevent `~/.my.cnf` from getting loaded if the items in `/etc/` don't exist? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38792355 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 13:56:58 2014 From: notifications at github.com (awiddersheim) Date: Thu, 27 Mar 2014 05:56:58 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: Hrm, it has been so long I don't really remember. I don't remember it ever trying to get data from `~/.my.cnf`. My initial comment doesn't seem to suggest that it tried to get data from there either before or after looking at the strace output. What makes you think that? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38798848 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:01:49 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 06:01:49 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: @awiddersheim your strace output actually exposes another bug, but I'll file an issue for that. Here's the problem I see right now: ``` stat("/root/..cnf", 0x7fff7c4e6620) = -1 ENOENT (No such file or directory) ``` That should be `/.root/.my.cnf`, but that's the aforementioned bug. This patch causes the cycle of checking which `my.cnf` to ignore the one that may exist in a user's homedir. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38799282 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:10:45 2014 From: notifications at github.com (awiddersheim) Date: Thu, 27 Mar 2014 06:10:45 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: Oh, I think your initial sentence should have read like this: Doesn't this patch prevent `~/.my.cnf` from getting loaded if the items in /etc **DO** exist? So with this fix the order in which things get searched seems to be as follows: `/etc/mysql/.cnf` `/etc/my.cnf` `/root/mysql.cnf` So in my initial comment it seems to have found `/etc/my.cnf` and maybe stopped checking for `/root/mysql.cnf` existence. I could have just not posted that part of the strace output though after the first `my.cnf` was found. Does that make sense? -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38800041 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:11:15 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 06:11:15 -0700 Subject: check_ssh: check protocol (#1190) In-Reply-To: References: Message-ID: A nice addition, sane code, and works fine for me locally. :+1: -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1190#issuecomment-38800077 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:16:13 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 06:16:13 -0700 Subject: check_nwstat: adds percentage used space (#1183) In-Reply-To: References: Message-ID: I haven't actually tested this, but there are some code style things that I'd like to see fixed up before merge: 1. There should always be spaces before and after operators (e.g. `result = send_tcp_request` not `result=send_tcp_request`). This applies for mathematic stuff like addition, too (e.g. `1 + 4`, not `1+4`). 2. Mixing of tabs and spaces or some other kind of indentation problem. Things are inconsistent. Once those two things are fixed I can do a full code review. Thanks a bunch! -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1183#issuecomment-38800565 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:23:39 2014 From: notifications at github.com (Sam Kottler) Date: Thu, 27 Mar 2014 06:23:39 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: Yeah sorry, I clearly am dense because your output is just truncated. This change is ready for merge. Thanks for tolerating me @awiddersheim :-) -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38801323 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Mar 27 14:27:13 2014 From: notifications at github.com (awiddersheim) Date: Thu, 27 Mar 2014 06:27:13 -0700 Subject: Fix check_mysql.c client options from file (#1199) In-Reply-To: References: Message-ID: No problem. Probably should have included all the output so my bad. Thanks for looking. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1199#issuecomment-38801735 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Mar 31 14:21:47 2014 From: notifications at github.com (paianoa) Date: Mon, 31 Mar 2014 05:21:47 -0700 Subject: check_disk accepts -w and -c parameters without forcing user to provide threshold values. (#1251) Message-ID: It seems a command-line parsing bug. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1251 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Mar 31 20:03:38 2014 From: notifications at github.com (abrist) Date: Mon, 31 Mar 2014 11:03:38 -0700 Subject: check_disk accepts -w and -c parameters without forcing user to provide threshold values. (#1251) In-Reply-To: References: Message-ID: Isn't this WAI, but maybe not as expected to those unfamiliar with unix getopt conventions? I bet if you just specify just one of the options, you will get a usage error: [root at localhost nagios-plugins]# ./plugins/check_procs -w ./plugins/check_procs: option requires an argument -- 'w' If you specify both, if will take the next parameter as the optarg value: [root at localhost nagios-plugins]# ./plugins/check_procs -w -c PROCS WARNING: 81 processes | procs=81;-c;;0; Notice the perfdata setting "-c" as the warning threshold. I guess some extra validation could be added to all of the relevant case statements for the optargs (using some yet to be created functions in utils), but given the amount of special cases, it will still add a number of lines to every plugin. -- Reply to this email on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1251#issuecomment-39120691 -------------- next part -------------- An HTML attachment was scrubbed... URL: