From noreply at sourceforge.net Thu Oct 1 04:20:37 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 1 Oct 2009 02:20:37 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1164331 ] IBM-AIX 5.1 :Link-Error "Undefined symbol: .libintl_gettext" Message-ID: Bugs item #1164331, was opened at 2005-03-16 09:53 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1164331&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Wilfried Brunken (df7be) Assigned to: Nobody/Anonymous (nobody) Summary: IBM-AIX 5.1 :Link-Error "Undefined symbol: .libintl_gettext" Initial Comment: not on AIX 4.3 ! Can configure find the Problem itself ? Workaround ./configure --disable-nls --with-included-gettext Solution found at this link: http://mail.gnome.org/archives/mc-devel/2002- September/msg00193.html ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-10-01 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2009-09-16 08:19 Message: There have been many changes around this area. Please try the snapshot at http://nagiosplugins.org/download Marked into pending, which will autoclose if no updates in 7 days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1164331&group_id=29880 From invitations at fedora-tn.ning.com Fri Oct 2 22:04:57 2009 From: invitations at fedora-tn.ning.com (dimmumeister) Date: Fri, 2 Oct 2009 20:04:57 +0000 (GMT) Subject: [Nagiosplug-devel] Come join me on Fedora in tunisia Message-ID: <31331739.63339231254513897339.JavaMail.xncore@omx> Fedora in tunisia: The Fedora community in Tunisia -------------------- I have just created this social network thanks to ning.com. Don't worry it's not a spam or a malicious activity. I'm hahmed as you know in fedora-tunisia group.THis is a real social network = facebook Click the link below to Join: http://fedora-tn.ning.com/?xgi=2VPgn8Wp0JHqoj If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser -------------------- About Fedora in tunisia This is the Fedora Tunisian users social network. Fedora in tunisia includes: Blogs Events Discussions Groups Music Photos Videos -------------------- To control which emails you receive on the corner, or to opt-out, go to: http://fedora-tn.ning.com/?xgo=jgx5UHux3qqdp6gUOm439kZSmJ8eqsIwUlPJnYLAy0UTUaU24dUCuVggNCGqOW9QKpgIADjErGkS2I-ELdKovw -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Sun Oct 4 04:21:11 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 4 Oct 2009 02:21:11 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2861789 ] memory leak Message-ID: Bugs item #2861789, was opened at 2009-09-18 22:21 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: v1.4.14 >Status: Closed Resolution: Later Priority: 5 Private: No Submitted By: Franck Bourdonnec (franck78) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: the check_smtp.c plugin have malloc() used (line 144) and no corresponding free() Should be converted into buffer allocated on stack. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-10-04 02:21 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-09-19 05:27 Message: If you start tracking every memory allocation leak in nagios plugins you'll find hundreds (or maybe even thousands) of them. The truth is that plugins runs for a very short time and it is much faster to let the OS reclaim the memory on process exit than reclaiming it with free(). OTOH I'm not against it; the difference is not very significant and it could be useful in the future. For example the plugins code could be loaded by a daemon instead of running in standalone plugins. It's not the case right now so this is not a priority. I'm marking this bug as Pending/Later for now. Feel free to comment if you think the memory leakage within a single run could be so significant this is problematic, of if you want to attach an acceptable fix for it. Otherwise it's just not a priority. Thanks for reporting bugs against the Nagios Plugins though, this is always appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2861789&group_id=29880 From noreply at sourceforge.net Mon Oct 5 10:44:20 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Oct 2009 08:44:20 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reports disk usage on bind mounted volumes Message-ID: Bugs item #2872843, was opened at 2009-10-05 08:44 Message generated for change (Tracker Item Submitted) made by troyjrose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Rose (troyjrose) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports disk usage on bind mounted volumes Initial Comment: The check disk usage reports disk usage on bind mounted filesystems when specifying local only filesystems. This in itself isn't a problem but the problem comes when the filesystem being bind mounted is not a local filesystem I'm using the latest version of the nagios plugins (1.14). I'm submitted a patch to check disk that allows excluding of partitions that match certain mount options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 From noreply at sourceforge.net Mon Oct 5 10:46:22 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Oct 2009 08:46:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reports disk usage on bind mounted volumes Message-ID: Bugs item #2872843, was opened at 2009-10-05 08:44 Message generated for change (Comment added) made by troyjrose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Rose (troyjrose) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports disk usage on bind mounted volumes Initial Comment: The check disk usage reports disk usage on bind mounted filesystems when specifying local only filesystems. This in itself isn't a problem but the problem comes when the filesystem being bind mounted is not a local filesystem I'm using the latest version of the nagios plugins (1.14). I'm submitted a patch to check disk that allows excluding of partitions that match certain mount options. ---------------------------------------------------------------------- >Comment By: Troy Rose (troyjrose) Date: 2009-10-05 08:46 Message: Oopps I meant I'm using the latest public release 1.4.14 of the nagios-plugins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 From John.Carroll at govdelivery.com Mon Oct 5 18:50:19 2009 From: John.Carroll at govdelivery.com (John Patrick Carroll) Date: Mon, 5 Oct 2009 11:50:19 -0500 Subject: [Nagiosplug-devel] Nagiosplug-devel Digest, Vol 41, Issue 1 In-Reply-To: References: Message-ID: <6E66FBDB43DE0F47A921161C395545B4362F4B1450@mail1.office.gdi> -----Original Message----- Date: Mon, 28 Sep 2009 21:03:59 -0400 From: Thomas Guyot-Sionnest Subject: Re: [Nagiosplug-devel] check_users Nagios plugin To: Nagios Plugin Development Mailing List Message-ID: <4AC15CFF.2030600 at aei.ca> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/09/09 06:43 PM, John Patrick Carroll wrote: > I am talking about specific information for performance data returned by the check_users plugin, not performance data in general. $./check_users Usage:check_users -w -c $ ./check_users -w 1 -c 2 USERS CRITICAL - 3 users currently logged in |users=3;1;2;0 Isn't that obvious? - -- Thomas ------------------------------ Somewhat, but it would be nice if the documentation was more robust, especially for a check that is included in the base set of checks for Nagios. I don't think defining and documenting what the performance data actually means is much of a request. Plus, in the performance data, what does the 0 at the end represent? I would assume (assume because no documentation states this is so) the 3 is the current number of users, the 1 is the warning level, the 2 is the critical level, but what is the 0? thanks, John John Patrick Carroll | Senior Systems Administrator GovDelivery, Inc. 408 St. Peter St, Ste 600 | St Paul, MN 55102-1147 651.757.4124 or 866.276.5583 ext. 124 Resources Website: www.govdelivery.com Blog: www.reachthepublic.com Twitter: www.twitter.com/govdelivery From dermoth at aei.ca Mon Oct 5 21:27:53 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 05 Oct 2009 15:27:53 -0400 Subject: [Nagiosplug-devel] Nagiosplug-devel Digest, Vol 41, Issue 1 In-Reply-To: <6E66FBDB43DE0F47A921161C395545B4362F4B1450@mail1.office.gdi> References: <6E66FBDB43DE0F47A921161C395545B4362F4B1450@mail1.office.gdi> Message-ID: <4ACA48B9.5020907@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Patrick Carroll wrote: >> On 28/09/09 06:43 PM, John Patrick Carroll wrote: >>> I am talking about specific information for performance data returned by the check_users plugin, not performance data in general. >> >> $./check_users >> >> >> Usage:check_users -w -c >> >> $ ./check_users -w 1 -c 2 >> USERS CRITICAL - 3 users currently logged in |users=3;1;2;0 >> >> Isn't that obvious? > > Somewhat, but it would be nice if the documentation was more robust, especially for a check that is included in the base set of checks for Nagios. I don't think defining and documenting what the performance data actually means is much of a request. > Plus, in the performance data, what does the 0 at the end represent? I would assume (assume because no documentation states this is so) the 3 is the current number of users, the 1 is the warning level, the 2 is the critical level, but what is the 0? Then this is my first answer, the developer guidelines state exactly what the performance string should looks like, and the label is usually self-descriptive. This string is meant to be machine-parsable and all the information you need relative to a check should be in the check output itself. The documentation is properly located considering that only people that develop applications using this information need to know about the details. There's no need for the users to know them beyond that it's made for being processed by other applications. If you believe that some checks are missing information then v3 output and the new plugin thresholds should be the solution for it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkrKSLkACgkQ6dZ+Kt5BchYMLwCYm3M4SdjCehsE5Gr4MCnEpY+o sQCdGPKTJCz2AxwnDNdYqfRJ+TEjnBI= =NW+J -----END PGP SIGNATURE----- From Gerhard.Lausser at consol.de Tue Oct 6 18:09:41 2009 From: Gerhard.Lausser at consol.de (Gerhard Lausser) Date: Tue, 6 Oct 2009 18:09:41 +0200 Subject: [Nagiosplug-devel] Nagios::Plugin add_message(UNKNOWN, ... Message-ID: <2E300793C7B34348A792FD09A6B5411E@int.consol.de> Hi, i'm just curious: why can't i buffer an error message with $plugin->add_message(UNKNOWN, "could not contact blabla..."); Is nagios_die the way to go? But what if there is some work left (cleaning up temp files, closing a database connection cleanly,...) which needs to be done no matter what the exit code of the plugin will be? I personally don't like to abort a plugin like this. Gerhard From noreply at sourceforge.net Wed Oct 7 09:56:21 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Oct 2009 07:56:21 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reports disk usage on bind mounted volumes Message-ID: Bugs item #2872843, was opened at 2009-10-05 08:44 Message generated for change (Comment added) made by troyjrose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Rose (troyjrose) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports disk usage on bind mounted volumes Initial Comment: The check disk usage reports disk usage on bind mounted filesystems when specifying local only filesystems. This in itself isn't a problem but the problem comes when the filesystem being bind mounted is not a local filesystem I'm using the latest version of the nagios plugins (1.14). I'm submitted a patch to check disk that allows excluding of partitions that match certain mount options. ---------------------------------------------------------------------- >Comment By: Troy Rose (troyjrose) Date: 2009-10-07 07:56 Message: Okay, I've gotten to the bottom of it. There is an almost unsed static variable in the check_disk plugin which is used to display or not display dummy filesystems (like proc etc). So, setting that to disabled, everything works as expected, and bind filesystesm (which show up as type "none") dont get displayed anymore. ---------------------------------------------------------------------- Comment By: Troy Rose (troyjrose) Date: 2009-10-05 08:46 Message: Oopps I meant I'm using the latest public release 1.4.14 of the nagios-plugins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 From noreply at sourceforge.net Wed Oct 7 10:01:44 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Oct 2009 08:01:44 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reports disk usage on bind mounted volumes Message-ID: Bugs item #2872843, was opened at 2009-10-05 08:44 Message generated for change (Settings changed) made by troyjrose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Rose (troyjrose) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports disk usage on bind mounted volumes Initial Comment: The check disk usage reports disk usage on bind mounted filesystems when specifying local only filesystems. This in itself isn't a problem but the problem comes when the filesystem being bind mounted is not a local filesystem I'm using the latest version of the nagios plugins (1.14). I'm submitted a patch to check disk that allows excluding of partitions that match certain mount options. ---------------------------------------------------------------------- Comment By: Troy Rose (troyjrose) Date: 2009-10-07 07:56 Message: Okay, I've gotten to the bottom of it. There is an almost unsed static variable in the check_disk plugin which is used to display or not display dummy filesystems (like proc etc). So, setting that to disabled, everything works as expected, and bind filesystesm (which show up as type "none") dont get displayed anymore. ---------------------------------------------------------------------- Comment By: Troy Rose (troyjrose) Date: 2009-10-05 08:46 Message: Oopps I meant I'm using the latest public release 1.4.14 of the nagios-plugins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 From noreply at sourceforge.net Wed Oct 7 11:14:47 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Oct 2009 09:14:47 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reports disk usage on bind mounted volumes Message-ID: Bugs item #2872843, was opened at 2009-10-05 08:44 Message generated for change (Comment added) made by troyjrose You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Troy Rose (troyjrose) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports disk usage on bind mounted volumes Initial Comment: The check disk usage reports disk usage on bind mounted filesystems when specifying local only filesystems. This in itself isn't a problem but the problem comes when the filesystem being bind mounted is not a local filesystem I'm using the latest version of the nagios plugins (1.14). I'm submitted a patch to check disk that allows excluding of partitions that match certain mount options. ---------------------------------------------------------------------- >Comment By: Troy Rose (troyjrose) Date: 2009-10-07 09:14 Message: I've noticed that on RHEL4 systems the bind mounts are not set as filesystem type "none", and are still displayed. So I've added in another macro to mountlist.c to fix this and check for a bind mounted option, and set it as a dummy filesystem. I've attached the patch. ---------------------------------------------------------------------- Comment By: Troy Rose (troyjrose) Date: 2009-10-07 07:56 Message: Okay, I've gotten to the bottom of it. There is an almost unsed static variable in the check_disk plugin which is used to display or not display dummy filesystems (like proc etc). So, setting that to disabled, everything works as expected, and bind filesystesm (which show up as type "none") dont get displayed anymore. ---------------------------------------------------------------------- Comment By: Troy Rose (troyjrose) Date: 2009-10-05 08:46 Message: Oopps I meant I'm using the latest public release 1.4.14 of the nagios-plugins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2872843&group_id=29880 From anish.patel at bt.com Wed Oct 7 15:10:29 2009 From: anish.patel at bt.com (anish.patel at bt.com) Date: Wed, 7 Oct 2009 14:10:29 +0100 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2872843 ] check_disk reportsdisk usage on bind mounted volumes In-Reply-To: Message-ID: Hi Does anyone know of a plugging that will check digital certificate expiry using a proxy, really need one. From noreply at sourceforge.net Thu Oct 8 10:51:07 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Oct 2009 08:51:07 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1490762 ] check_disk / not found on Solaris Message-ID: Bugs item #1490762, was opened at 2006-05-18 11:07 Message generated for change (Comment added) made by testtest5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1490762&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ton Voon (tonvoon) Summary: check_disk / not found on Solaris Initial Comment: Solaris 2.6, 8 and 9, seen on more than one server $ ./check_disk -e -w 10% -c 5% -p /opt/oracle -p /opt -p / DISK CRITICAL - free space: [/ not found]| /=781MB;846;893;91;940 /opt=427MB;846;893;99;940 /opt/oracle=1165MB;3630;3832;94;4034 Change the order of the partitions $ ./check_disk -e -w 10% -c 5% -p / -p /opt/oracle -p /opt DISK OK - free space:| /=781MB;846;893;91;940 /opt=427MB;846;893;99;940 /opt/oracle=1165MB;3630;3832;94;4034 This is the minimum case - other partitions can be defined (and reported upon correctly) and only / reports an error. Seems to be due to mount point being under a root directory, i.e. /opt /opt/app /opt /opt/oracle both "lose" / when its the last parameter checked. ---------------------------------------------------------------------- Comment By: test test (testtest5) Date: 2009-10-08 10:51 Message: This issue is still happening. It occurs when there's a file /etc/.mnttab.lock present on the host. (if this comment doesn't reopen this bug I'll open a new one) ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-03 04:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 01:09 Message: Logged In: YES user_id=664364 Hi Duncan! There have been major changes to check_disk. Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. Marking this call into PENDING. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1490762&group_id=29880 From noreply at sourceforge.net Thu Oct 8 10:56:50 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Oct 2009 08:56:50 +0000 Subject: [ nagiosplug-Bugs-2874581 ] check_disk shows “/ not found” on Solaris Message-ID: Bugs item #2874581, was opened at 2009-10-08 10:56 Message generated for change (Tracker Item Submitted) made by testtest5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2874581&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: test test (testtest5) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk shows ?/ not found? on Solaris Initial Comment: This issue occurs when the 0-byte regular file /etc/.mnttab.lock is present on the Solaris host being monitored. The workaround is to delete /etc/.mnttab.lock Is this fixable? (I think this is the same issue as #1490762 but I can't re-open that bug) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2874581&group_id=29880 From ton.voon at opsera.com Thu Oct 8 11:27:54 2009 From: ton.voon at opsera.com (Ton Voon) Date: Thu, 8 Oct 2009 10:27:54 +0100 Subject: [Nagiosplug-devel] Nagios::Plugin add_message(UNKNOWN, ... In-Reply-To: <2E300793C7B34348A792FD09A6B5411E@int.consol.de> References: <2E300793C7B34348A792FD09A6B5411E@int.consol.de> Message-ID: Hi Gerhard, On 6 Oct 2009, at 17:09, Gerhard Lausser wrote: > i'm just curious: why can't i buffer an error message with > $plugin->add_message(UNKNOWN, "could not contact blabla..."); Not sure what you mean... > > Is nagios_die the way to go? But what if there is some work left > (cleaning > up temp files, closing a database connection cleanly,...) which > needs to be > done no matter what the exit code of the plugin will be? I > personally don't > like to abort a plugin like this. Could you achieve this with an END { ... } block? Ton From Gerhard.Lausser at consol.de Fri Oct 9 16:17:39 2009 From: Gerhard.Lausser at consol.de (Gerhard Lausser) Date: Fri, 9 Oct 2009 16:17:39 +0200 Subject: [Nagiosplug-devel] Nagios::Plugin add_message(UNKNOWN, ... In-Reply-To: References: <2E300793C7B34348A792FD09A6B5411E@int.consol.de> Message-ID: <327A461A8A264B90A085470705A3C387@int.consol.de> > > i'm just curious: why can't i buffer an error message with > > $plugin->add_message(UNKNOWN, "could not contact blabla..."); > > Not sure what you mean... subroutine analyze_device { # do an inventory of the monitored device # collect information about all it's components # do a lot of things which require e.g. writing to temp files foreach (@components) { if (a certain problem found) { add_message(UNKNOWN, 'e.g. component xy could not be checked') # not good if the plugin is aborted here with nagios_exit } elsif (another problem found) { add_message(CRITICAL, 'component xy failed') } else { add_message(OK, 'component xy fine') } } # cleanup temp files, maybe close database connections } main: prepare_a_lot_of_things(); analyze_device(); cleanup_more(); my ($code, $message) = $plugin->check_messages(join_all => ', '); $plugin->nagios_exit($code, $message); My question was: why can i add messages with (OK, WARNING, CRITICAL) and save them for the final output with nagios_exit, but not messages with an UNKNOWN level? For simple plugins, it might be ok to abort the execution with nagios_die in case of an UNKNOWN situation. But if the plugin is a really big one, i would like to treat UNKNOWN like any other error. Gerhard From shadhin71 at gmail.com Mon Oct 12 15:58:25 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Mon, 12 Oct 2009 09:58:25 -0400 Subject: [Nagiosplug-devel] snmp calculation feature request Message-ID: <6db4a4200910120658l40b96296w8c49f7b435a1fd67@mail.gmail.com> All, check_snmp is a great plugin. However would it be possible to add calculating feature. Many snmp oid return values are not in exact numerical format. For example, liebert ups reurn some values as some data form which you have to multiply by .1 to get the exact data. Would it possible to add the calculation feature? Please advise on this. Thanks -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjones at pittstate.edu Mon Oct 12 20:59:30 2009 From: cjones at pittstate.edu (Chris Jones) Date: Mon, 12 Oct 2009 13:59:30 -0500 Subject: [Nagiosplug-devel] check_snmp AES Message-ID: <4AD37C92.4010101@pittstate.edu> Hello. Are there plans to include AES for the priv proto in SNMPv3? Thanks! - Chris -- Chris Jones CCIE# 25655 (R&S), JNCIA-M Senior Systems Manager Pittsburg State University E-mail: cjones at pittstate.edu Phone: 1.620.235.4158 -- "The production of too many useful things results in too many useless people." -Karl Marx From dermoth at aei.ca Tue Oct 13 08:35:13 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 13 Oct 2009 02:35:13 -0400 Subject: [Nagiosplug-devel] New threshold syntax - changes Message-ID: <4AD41FA1.5040202@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I talked about all these changes in the threads a while ago but I received no comments on them. If you have anything against them please speak now! 1. --th=metric={metric} instead of --{metric}: Ok, this makes it a bit longer, but I believe it's a much clearer separation between thresholds and other command-line arguments. Both "--threshold" and "--th" would be equally valid. The list of metrics could be printed in a table after the argument list, and could include dynamic metrics for some plugins (i.e. based on the data being checked) using a common prefix. Additionally it allow setting default parameters by omitting the metric. 2. Making the "end" optional in range? At one point it was suggested making the end parameter optional. The current spec says the range must have bots start and end, which means most threshold ranges will have to be like this (ex. for a 10 second delay warning/critical): 10..inf instead of just "10". 3. Clarification of the ok= level Is is unclear how levels interact regarding the OK level. Here's what I proposed (by "check" I mean to also return the value if within range): 1. Without OK range: a. check for critical range if specified b. check for warning range if specified c. return OK 2: With OK range: a. check for OK range b. check for critical range if specified c. check for warning range if specified d. return CRITICAL. 4. Separation of uom and prefix In the RFC the "uom" parameter specify both the unit and its prefix. This parameter has to be separated to prevent a parsing nightmare. Therefore there should be: a. unit: unit of the data, useful (and valid) only when the plugin doesn't knwo what is it (ex. check_snmp) b. prefix: this is the SI prefix for using the range values and usually printing on the normal output as well (performance data should be a double value and therefore shouldn't be affected by this as precision is retained anyway). Should be valid everywhere with a default value provided by the plugin where applicable. Ex.: M, K, m, KiB, etc.. Please let me know if you see any issue here... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFK1B+g6dZ+Kt5BchYRAtK5AJkBKhWWohyT7yc+Z+n910W39v8SvACg1D8r O5IQn1S2h14yHpCAAFPD994= =krRz -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Oct 13 10:24:11 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Oct 2009 08:24:11 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-2877719 ] Please, add "source address" parameter to check_ping plugin Message-ID: Feature Requests item #2877719, was opened at 2009-10-13 12:24 Message generated for change (Tracker Item Submitted) made by ssvictors You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2877719&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: ssvictors (ssvictors) Assigned to: Nobody/Anonymous (nobody) Summary: Please, add "source address" parameter to check_ping plugin Initial Comment: check_ping plugin has no ability to specify source address of packets. This ability will be useful on multi-ISP servers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2877719&group_id=29880 From rich at richhorner.com Tue Oct 13 18:31:02 2009 From: rich at richhorner.com (Richard Edward Horner) Date: Tue, 13 Oct 2009 16:31:02 +0000 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <4AD41FA1.5040202@aei.ca> References: <4AD41FA1.5040202@aei.ca> Message-ID: <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> I don't have any real concerns with 1, 2 or 4. I think 3 is an important clarification. One thing that has bugged me with thresholds is that the spec is only useful if it's followed but most plugins don't follow it and just implement what's quick. I'll give the pertinent example. On Sabyon 5 I type equo install nagios-plugins as root to pull 1.4.13-r4. I cd to /usr/lib64/nagios/plugins and do: ./check_users --help ./check_disk --help check_users says: -c, --critical=INTEGER Set CRITICAL status if more than INTEGER users are logged in check_disk says: -c, --critical=INTEGER Exit with CRITICAL status if less than INTEGER units of disk are free According to the spec, neither of these are correct. check_users behaves as the spec defines when you specify --critical=10 but with check_disk --critical=10 behaves like --critical=10: Really, they shouldn't have any qualifiers, they should say "this is where you specify the alert range" and there should be a --range_help option that prints something like: The format for ranges in Nagios can be confusing and it isn't always followed. [@]start[:[end]] Here are some example ranges: Range | Generate an alert if value is | In English --------+-----------------------------------+--------------------------------- 10 | outside the range of {0 .. 10} | Greater than 10 @10 | inside the range of {0 .. 10} | Less than or equal to 10 10: | outside {10 .. ?} | Greater than 10 ~:10 | outside the range of {-? .. 10} | Less than 10 including negative 10:20 | outside the range of {10 .. 20} | Between 10 and 20 @10:20 | inside the range of {10 .. 20} | Anything from 10 to 20 10 | outside the range of {0 .. 10} | Greater than 10 or less than 0 Formal Rules: 1. start ? end 2. start and ":" is not required if start=0 3. if range is of format "start:" and end is not specified, end is infinity 4. to specify negative infinity, use "~" 5. alert is raised if metric is outside start and end range (inclusive) 6. if range starts with "@", then alert if inside this range (inclusive) 10 < 0 or > 10, (outside the range of {0 .. 10}) 10: < 10, (outside {10 .. ?}) ~:10 > 10, (outside the range of {-? .. 10}) 10:20 < 10 or > 20, (outside the range of {10 .. 20}) @10:20 ? 10 and ? 20, (inside the range of {10 .. 20}) 10 < 0 or > 10, (outside the range of {0 .. 10}) More help at http://nagiosplug.sourceforge.net/developer-guidelines.html That's according to spec. Now, this begs the question though, is this what we really want? If developer patterns are to be believed, it would seem this is not the case. People just want what's easiest and most intuitive to use. I think if you're going to have a spec, it needs to be followed. If you have a spec and it's not followed, it's confusing and worse than a waste of time as it is probably costing ppl time. Perhaps the concept of thresholds in the developer guidelines should say something like, "left to the developer's discretion" but then there can be a subsection that explains how to accept ranges of values if you want to accept ranges. A lot of plugins don't need ranges and would only ever want to check whether some number is more than some other number which I realize can be represented as a range using infinity or negative infinity as one end but this is overkill and I've never seen a production system using this. So, yeah, I vote for being all UNIX-y and to KISS. Give guidelines for how to do ranges but make ranges optional and leave thresholds to "what makes sense". Afterall, it's opensource. If someone doesn't like it, they can change it but I think it's counterproductive to have a spec that appears to be meaningless because it's not followed. Thanks, Rich(ard) On Tue, Oct 13, 2009 at 6:35 AM, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I talked about all these changes in the threads a while ago but I > received no comments on them. If you have anything against them please > speak now! > > 1. --th=metric={metric} instead of --{metric}: > > Ok, this makes it a bit longer, but I believe it's a much clearer > separation between thresholds and other command-line arguments. Both > "--threshold" and "--th" would be equally valid. The list of metrics > could be printed in a table after the argument list, and could include > dynamic metrics for some plugins (i.e. based on the data being checked) > using a common prefix. Additionally it allow setting default parameters > by omitting the metric. > > 2. Making the "end" optional in range? > > At one point it was suggested making the end parameter optional. The > current spec says the range must have bots start and end, which means > most threshold ranges will have to be like this (ex. for a 10 second > delay warning/critical): > > 10..inf > > instead of just "10". > > > 3. Clarification of the ok= level > > Is is unclear how levels interact regarding the OK level. Here's what I > proposed (by "check" I mean to also return the value if within range): > > 1. Without OK range: > ?a. check for critical range if specified > ?b. check for warning range if specified > ?c. return OK > > 2: With OK range: > ?a. check for OK range > ?b. check for critical range if specified > ?c. check for warning range if specified > ?d. return CRITICAL. > > > > 4. Separation of uom and prefix > > In the RFC the "uom" parameter specify both the unit and its prefix. > This parameter has to be separated to prevent a parsing nightmare. > Therefore there should be: > > ?a. unit: unit of the data, useful (and valid) only when the plugin > doesn't knwo what is it (ex. check_snmp) > > ?b. prefix: this is the SI prefix for using the range values and > usually printing on the normal output as well (performance data should > be a double value and therefore shouldn't be affected by this as > precision is retained anyway). Should be valid everywhere with a default > value provided by the plugin where applicable. Ex.: M, K, m, KiB, etc.. > > > Please let me know if you see any issue here... > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFK1B+g6dZ+Kt5BchYRAtK5AJkBKhWWohyT7yc+Z+n910W39v8SvACg1D8r > O5IQn1S2h14yHpCAAFPD994= > =krRz > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso richhorner.com | rhosts.net | sabayonlinux.org From perldork at webwizarddesign.com Tue Oct 13 19:22:06 2009 From: perldork at webwizarddesign.com (Max) Date: Tue, 13 Oct 2009 13:22:06 -0400 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> Message-ID: After working with a living larger system with 10-12 Nagios configuration users / developers, I am coming around to Richard's view as well. We have made very memory efficient and process efficient APIs / frameworks to use with nagios for writing remote checks in perl using Net-SNMP or a custom perl agent I wrote, but in the end what our users want and use that most is what is 1) easy to use 2) quick to implement and 3) minimizes the amount of hard-coded configuration work in the shared nagios configuration tree. At our company, one of our teams' jobs is to make our nagios instance as self service as possible; many of our users are experienced SAs who have not used Nagios before, so we try to make our thresholds easy to read and use; I would not want them to have to use this very succinct but hard to remember notation. We have moved forward with a bash like notation: -w metric1,gt,10:metric1,lt,20:metric2,eq,14 we default to 'or' logic but would be easy enough to add and if it is requested .. has not been yet so i am not going to implement that until it is wanted. I know my notation was slammed on list for a number of reasons and that is fine :), I am not suggesting it as a Nagios standard, but it is easy for our users to pick up and remember, it is implemented in the module Nenm::Utils which is available online. So I am all for having guidelines but after working with a larger group of nagios users / developers I have changed my point of view .. easy to learn and remember and use with more typing is better than succinct and short to type as far as maintainability, accessibility, and wide acceptance. - Max From dermoth at aei.ca Tue Oct 13 19:37:35 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 13 Oct 2009 13:37:35 -0400 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> Message-ID: <4AD4BADF.70106@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Edward Horner wrote: > I don't have any real concerns with 1, 2 or 4. > > I think 3 is an important clarification. > > One thing that has bugged me with thresholds is that the spec is only > useful if it's followed but most plugins don't follow it and just > implement what's quick. I'll give the pertinent example. Not all plugins use the thresholds library. If the --help output doesn't say something like "--warning=THRESHOLD" with a comment in the notes pointing to the developer guidelines section explaining ranges, it's most likely not "real" thresholds. We have modified a few plugins to the real thresholds library in the last years but now the goal would be writing a new enhanced one and porting all plugins to it. Any plugin using this specification will have to go trough the library (it can't really be done otherwise, as it would require lot of code which should be already written!). The libnagiosplug project will also make this code usable easily by 3rd party plugins (and this will also be implemented in the Nagios::Plugin Perl module, obvisously... > I think if you're going to have a spec, it needs to be followed. If > you have a spec and it's not followed, it's confusing and worse than a > waste of time as it is probably costing ppl time. I should've sent it with the previous email. The new spec is here: http://nagiosplugins.org/rfc/new_threshold_syntax - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrUut8ACgkQ6dZ+Kt5BchZFoQCdEZKxuAgUt3ZuWEZVwNpC+el/ CgIAnjQcPlJ+mivscD8fIYQBq1WonPwo =nw67 -----END PGP SIGNATURE----- From dermoth at aei.ca Tue Oct 13 19:58:19 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 13 Oct 2009 13:58:19 -0400 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> Message-ID: <4AD4BFBB.7020607@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max wrote: > After working with a living larger system with 10-12 Nagios > configuration users / developers, I am coming around to Richard's view > as well. > > We have made very memory efficient and process efficient APIs / > frameworks to use with nagios for writing remote checks in perl using > Net-SNMP or a custom perl agent I wrote, but in the end what our users > want and use that most is what is 1) easy to use 2) quick to implement > and 3) minimizes the amount of hard-coded configuration work in the > shared nagios configuration tree. > > At our company, one of our teams' jobs is to make our nagios instance > as self service as possible; many of our users are experienced SAs who > have not used Nagios before, so we try to make our thresholds easy to > read and use; I would not want them to have to use this very succinct > but hard to remember notation. > > We have moved forward with a bash like notation: > > -w metric1,gt,10:metric1,lt,20:metric2,eq,14 > > we default to 'or' logic but would be easy enough to add and if it is > requested .. has not been yet so i am not going to implement that > until it is wanted. > > I know my notation was slammed on list for a number of reasons and > that is fine :), I am not suggesting it as a Nagios standard, but it > is easy for our users to pick up and remember, it is implemented in > the module Nenm::Utils which is available online. > > So I am all for having guidelines but after working with a larger > group of nagios users / developers I have changed my point of view .. > easy to learn and remember and use with more typing is better than > succinct and short to type as far as maintainability, accessibility, > and wide acceptance. I wouldn't mind allowing this kind of ranges definition (RPN-like syntax); it's very easy to add other range specifications using different label tags. You could have wrpn= and crpn= for example however in the current spec you can't bundle multiple metrics together like you did above. If people want bundling, we could allow something like this... I don't like that much though, and I don't believe it's really needed since in most case a single metric is sufficient (it's not like we'te really saving speed here - it takes much more time to get the thresholds right than to write them down anyway): - --th=metric=metric1;metric2;metric3,warn=range1;range2;range3,crit=... Don't forget getsubopt() don't allow equal signs and spaces so your RPN's will require a non-standard syntax That reminds me, I believe the spec talks about possibly using commas to specify multiple ranges. Besides the fact that it conflicts with getsubopt, I personally believe a much better approach is to allow repeated statements, i.e.: warn=3..3,warn=5..5 Would define values 3 and 5 as warning. Thanks for your feedback - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrUv7sACgkQ6dZ+Kt5BchapSwCfeHUJqJapICtoCoc3N2QgaZEb bWoAnRJpvBVjdQXdmr6pSpF49WVb/hEC =DXQb -----END PGP SIGNATURE----- From shadhin71 at gmail.com Tue Oct 13 20:01:46 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Tue, 13 Oct 2009 14:01:46 -0400 Subject: [Nagiosplug-devel] nagios plugin question Message-ID: <6db4a4200910131101x7e8397a7p3fcf97fc654918f@mail.gmail.com> All, I am trying to define an argument in plugin with default value. However whenever I give the argument a default value then it creates an array instead of scalar variable. can someone please tell me how to define a default value for an argument which can be accessed as a scalar? Thanks in advance. argument section $plugin->add_arg( spec => 'protocol|P=s', help => [ "snmp protocol", ], label => [ 'protocol'], default => [ '2c' ], required => 0, ); $plugin->getopts; my ( $opts ) =$plugin->opts; my $protocol=$opts->get('protocol'); Now $protocol contains a pointer to array. I want to $protocol to be just a sclar variable contain the string '2c' -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at richhorner.com Tue Oct 13 20:06:59 2009 From: rich at richhorner.com (Richard Edward Horner) Date: Tue, 13 Oct 2009 18:06:59 +0000 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <4AD4BADF.70106@aei.ca> References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> <4AD4BADF.70106@aei.ca> Message-ID: <7a65a83a0910131106y5f1f9a46me8e18082dab620f8@mail.gmail.com> OK, well, reading that page, I think it's an improvement over the current spec but I want to stress that ranges are not conceptually appropriate for a lot of situations and I doubt end users will want to think of their check_users call as either the OK range being 0 to 10 or the critical range being 11 to infinity. I think making the end of the range like you mentioned helps with this but you're still left with the problem of you can't do: check_users --critical=10 and check_disk --critical=10 and have them both behave as expected. One of them will require some "range" specific syntax when all I want to do is specify a level (and it's obvious which way it should go) and not a range. Even if the program itself is going to internally convert it into a range to do it's check, how the thing is programmed shouldn't dictate how the user has to interact with it. Thanks, Rich(ard) On Tue, Oct 13, 2009 at 5:37 PM, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Richard Edward Horner wrote: >> I don't have any real concerns with 1, 2 or 4. >> >> I think 3 is an important clarification. >> >> One thing that has bugged me with thresholds is that the spec is only >> useful if it's followed but most plugins don't follow it and just >> implement what's quick. I'll give the pertinent example. > > Not all plugins use the thresholds library. If the --help output doesn't > say something like "--warning=THRESHOLD" with a comment in the notes > pointing to the developer guidelines section explaining ranges, it's > most likely not "real" thresholds. We have modified a few plugins to the > real thresholds library in the last years but now the goal would be > writing a new enhanced one and porting all plugins to it. > > > Any plugin using this specification will have to go trough the library > (it can't really be done otherwise, as it would require lot of code > which should be already written!). The libnagiosplug project will also > make this code usable easily by 3rd party plugins (and this will also be > implemented in the Nagios::Plugin Perl module, obvisously... > >> I think if you're going to have a spec, it needs to be followed. If >> you have a spec and it's not followed, it's confusing and worse than a >> waste of time as it is probably costing ppl time. > > I should've sent it with the previous email. The new spec is here: > http://nagiosplugins.org/rfc/new_threshold_syntax > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrUut8ACgkQ6dZ+Kt5BchZFoQCdEZKxuAgUt3ZuWEZVwNpC+el/ > CgIAnjQcPlJ+mivscD8fIYQBq1WonPwo > =nw67 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso richhorner.com | rhosts.net | sabayonlinux.org From dermoth at aei.ca Tue Oct 13 21:54:59 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 13 Oct 2009 15:54:59 -0400 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <7a65a83a0910131106y5f1f9a46me8e18082dab620f8@mail.gmail.com> References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> <4AD4BADF.70106@aei.ca> <7a65a83a0910131106y5f1f9a46me8e18082dab620f8@mail.gmail.com> Message-ID: <4AD4DB13.3050707@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Edward Horner wrote: > OK, well, reading that page, I think it's an improvement over the > current spec but I want to stress that ranges are not conceptually > appropriate for a lot of situations and I doubt end users will want to > think of their check_users call as either the OK range being 0 to 10 > or the critical range being 11 to infinity. I think making the end of > the range like you mentioned helps with this but you're still left > with the problem of you can't do: I have to disagree with this. Most f the time we want to alert when the value is over or under a certain threshold these two ranges do exactly that: crit=10..inf crit=inf..10 Advanced range specifications can usw an "outside range", for example not in range 0..10: crit=!0..10 It's also possible to specify is the values should be inclusive or exclusive. > check_users --critical=10 > > and > > check_disk --critical=10 > > and have them both behave as expected. One of them will require some > "range" specific syntax when all I want to do is specify a level (and > it's obvious which way it should go) and not a range. Even if the > program itself is going to internally convert it into a range to do > it's check, how the thing is programmed shouldn't dictate how the user > has to interact with it. The current thresholds used to support only one of these cases, and is was confusing because users saw them as a "value" rather than a "range". In this proposal we want to force the use of range so it's much more intuitive to users. The first two examples above is all most users will have to understand to define simple thresholds on any plugin. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrU2xMACgkQ6dZ+Kt5BchbXzACfe+WEL+O2mEJK+46WaIYoUX2Z pJoAn1djVP586GdW4skPY8H/FyMl73iE =ghAN -----END PGP SIGNATURE----- From rich at richhorner.com Tue Oct 13 22:11:40 2009 From: rich at richhorner.com (Richard Edward Horner) Date: Tue, 13 Oct 2009 20:11:40 +0000 Subject: [Nagiosplug-devel] New threshold syntax - changes In-Reply-To: <4AD4DB13.3050707@aei.ca> References: <4AD41FA1.5040202@aei.ca> <7a65a83a0910130931l7d3772d4n5f1cac1a6ebd9df8@mail.gmail.com> <4AD4BADF.70106@aei.ca> <7a65a83a0910131106y5f1f9a46me8e18082dab620f8@mail.gmail.com> <4AD4DB13.3050707@aei.ca> Message-ID: <7a65a83a0910131311s5ec68352w9db1cf3d97d45d73@mail.gmail.com> I understand your point but I disagree. I don't think "force" and "intuitive" really go together. If I had written that sentence, I would've used "consistent" and while I value consistency very highly as a developer and systems administrator, the situation becomes less clear when the proposed solution is less intuitive (this is purely an opinion I realize) and users are already accustomed to the more intuitive manner. Maybe include a switch to use the old style? Rich(ard) On Tue, Oct 13, 2009 at 7:54 PM, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Richard Edward Horner wrote: >> OK, well, reading that page, I think it's an improvement over the >> current spec but I want to stress that ranges are not conceptually >> appropriate for a lot of situations and I doubt end users will want to >> think of their check_users call as either the OK range being 0 to 10 >> or the critical range being 11 to infinity. I think making the end of >> the range like you mentioned helps with this but you're still left >> with the problem of you can't do: > > I have to disagree with this. Most f the time we want to alert when the > value is over or under a certain threshold these two ranges do exactly that: > > crit=10..inf > crit=inf..10 > > Advanced range specifications can usw an "outside range", for example > not in range 0..10: > crit=!0..10 > > It's also possible to specify is the values should be inclusive or > exclusive. > >> check_users --critical=10 >> >> and >> >> check_disk --critical=10 >> >> and have them both behave as expected. One of them will require some >> "range" specific syntax when all I want to do is specify a level (and >> it's obvious which way it should go) and not a range. Even if the >> program itself is going to internally convert it into a range to do >> it's check, how the thing is programmed shouldn't dictate how the user >> has to interact with it. > > The current thresholds used to support only one of these cases, and is > was confusing because users saw them as a "value" rather than a "range". > In this proposal we want to force the use of range so it's much more > intuitive to users. The first two examples above is all most users will > have to understand to define simple thresholds on any plugin. > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrU2xMACgkQ6dZ+Kt5BchbXzACfe+WEL+O2mEJK+46WaIYoUX2Z > pJoAn1djVP586GdW4skPY8H/FyMl73iE > =ghAN > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso richhorner.com | rhosts.net | sabayonlinux.org From duncan.ferguson at opsera.com Wed Oct 14 10:18:28 2009 From: duncan.ferguson at opsera.com (Duncan Ferguson) Date: Wed, 14 Oct 2009 09:18:28 +0100 Subject: [Nagiosplug-devel] nagios plugin question In-Reply-To: <6db4a4200910131101x7e8397a7p3fcf97fc654918f@mail.gmail.com> References: <6db4a4200910131101x7e8397a7p3fcf97fc654918f@mail.gmail.com> Message-ID: On 13 Oct 2009, at 19:01, shadih rahman wrote: > All, > I am trying to define an argument in plugin with default value. > However whenever I give the argument a default value then it creates > an array instead of scalar variable. can someone please tell me how > to define a default value for an argument which can be accessed as a > scalar? Thanks in advance. > > > argument section > > $plugin->add_arg( > spec => 'protocol|P=s', > help => [ > "snmp protocol", > ], > label => [ 'protocol'], > default => [ '2c' ], > required => 0, > ); Remove the [ ]'s, i.e. $plugin->add_arg( spec => 'protocol|P=s', help => 'snmp protocol', label => 'protocol', default => '2c' , required => 0, ); Duncs -- Duncan Ferguson Senior Developer Opsera Limited | Unit 69 Suttons Business Park Reading | Berkshire | RG6 1AZ | UK Phone: +44 (0) 845 057 7887 Mobile: +44 (0) 7968 148 748 Skype: duncan_j_ferguson Email: duncan.ferguson at opsera.com www.opsera.com Opsera Limited is registered in the UK under Company Number 5396532. Our registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From dermoth at aei.ca Thu Oct 15 01:54:37 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 14 Oct 2009 19:54:37 -0400 Subject: [Nagiosplug-devel] [PATCH] Increment per-host sequence in check_icmp Message-ID: <1255564477-27243-1-git-send-email-dermoth@aei.ca> Hi, I patched check_icmp to increment the packet sequence number on each packet. This allow monitoring some devices that ignore duplicate ICMP sequences. The plugin is still able to differentiate between hosts by doing an integer division by the number of packet per host (the first sequence number is the host index * packets). Since I'm not very familiar with check_icmp, and considering that this plugin is setuid root, I'd love to get some peer reviews before I commit this patch. Regards, Thomas --- NEWS | 1 + plugins-root/check_icmp.c | 21 ++++++++++++++------- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/NEWS b/NEWS index 414ec67..a20dbbe 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ This file documents the major additions and syntax changes between releases. FIXES Fix check_ircd binding to wrong interface (#668778) Add proxy-authorization option to check_http (Marcel Kuiper - #1323230, Bryan Irvine - #2863925) + check_icmp now increment the sequence counter in each packet WARNINGS Updated developer documentation to say that performance labels should not have an equals sign or single quote in the label diff --git a/plugins-root/check_icmp.c b/plugins-root/check_icmp.c index cba7c44..e7d7825 100644 --- a/plugins-root/check_icmp.c +++ b/plugins-root/check_icmp.c @@ -333,14 +333,14 @@ handle_random_icmp(unsigned char *packet, struct sockaddr_in *addr) * to RFC 792). If it isn't, just ignore it */ memcpy(&sent_icmp, packet + 28, sizeof(sent_icmp)); if(sent_icmp.icmp_type != ICMP_ECHO || sent_icmp.icmp_id != pid || - sent_icmp.icmp_seq >= targets) + sent_icmp.icmp_seq >= targets*packets) { if(debug) printf("Packet is no response to a packet we sent\n"); return 0; } /* it is indeed a response for us */ - host = table[sent_icmp.icmp_seq]; + host = table[sent_icmp.icmp_seq/packets]; if(debug) { printf("Received \"%s\" from %s for ICMP ECHO sent to %s.\n", get_icmp_error_msg(p.icmp_type, p.icmp_code), @@ -624,7 +624,7 @@ main(int argc, char **argv) table = malloc(sizeof(struct rta_host **) * (argc - 1)); i = 0; while(host) { - host->id = i; + host->id = i*packets; table[i] = host; host = host->next; i++; @@ -768,16 +768,19 @@ wait_for_reply(int sock, u_int t) continue; } - if(icp.icmp_type != ICMP_ECHOREPLY || icp.icmp_seq >= targets) { - if(debug > 2) printf("not a proper ICMP_ECHOREPLY\n"); + if(icp.icmp_type != ICMP_ECHOREPLY || icp.icmp_seq >= targets*packets) { + if(debug > 2) printf("not a proper ICMP_ECHOREPLY %i:%i %i:%i\n", icp.icmp_type, ICMP_ECHOREPLY, icp.icmp_seq, targets*packets); handle_random_icmp(buf + hlen, &resp_addr); continue; } /* this is indeed a valid response */ memcpy(&data, icp.icmp_data, sizeof(data)); + if (debug >= 3) + printf("Received ICMP echo-reply of len %u, id %u, seq %u, cksum 0x%X from host %s\n", + sizeof(data), icp.icmp_id, icp.icmp_seq, icp.icmp_cksum, inet_ntoa(resp_addr.sin_addr)); - host = table[icp.icmp_seq]; + host = table[icp.icmp_seq/packets]; gettimeofday(&now, &tz); tdiff = get_timevaldiff(&data.stime, &now); @@ -848,9 +851,13 @@ send_icmp_ping(int sock, struct rta_host *host) packet.icp->icmp_code = 0; packet.icp->icmp_cksum = 0; packet.icp->icmp_id = pid; - packet.icp->icmp_seq = host->id; + packet.icp->icmp_seq = host->id++; packet.icp->icmp_cksum = icmp_checksum(packet.cksum_in, icmp_pkt_size); + if (debug >= 3) + printf("Sending ICMP echo-request of len %u, id %u, seq %u, cksum 0x%X to host %s\n", + sizeof(data), packet.icp->icmp_id, packet.icp->icmp_seq, packet.icp->icmp_cksum, host->name); + len = sendto(sock, packet.buf, icmp_pkt_size, 0, (struct sockaddr *)addr, sizeof(struct sockaddr)); -- 1.6.4.2 From shadhin71 at gmail.com Thu Oct 15 06:23:24 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Thu, 15 Oct 2009 04:23:24 +0000 Subject: [Nagiosplug-devel] nagios plugin question In-Reply-To: References: <6db4a4200910131101x7e8397a7p3fcf97fc654918f@mail.gmail.com> Message-ID: <6db4a4200910142123k4b8ea42bj89177115cf174ef5@mail.gmail.com> Thanks for your help. Just wanted to let you know Nagios::Object module has a bug regarding nagios version 3. It does not work with serviceescalation. If you are interested I can submit the patch. Thanks On Wed, Oct 14, 2009 at 8:18 AM, Duncan Ferguson wrote: > > On 13 Oct 2009, at 19:01, shadih rahman wrote: > > All, > I am trying to define an argument in plugin with default value. However > whenever I give the argument a default value then it creates an array > instead of scalar variable. can someone please tell me how to define a > default value for an argument which can be accessed as a scalar? Thanks in > advance. > > > argument section > > $plugin->add_arg( > spec => 'protocol|P=s', > help => [ > "snmp protocol", > ], > label => [ 'protocol'], > default => [ '2c' ], > required => 0, > ); > > > Remove the [ ]'s, i.e. > > $plugin->add_arg( > spec => 'protocol|P=s', > help => 'snmp protocol', > label => 'protocol', > default => '2c' , > required => 0, > ); > > Duncs > > -- > Duncan Ferguson > Senior Developer > > > > Opsera Limited | Unit 69 Suttons Business Park > Reading | Berkshire | RG6 1AZ | UK* > > Phone: *+44 (0) 845 057 7887 > *Mobile**: *+44 (0) 7968 148 748 > *Skype*: duncan_j_ferguson *Email:* *duncan.ferguson at opsera.com** > *www.opsera.com > > Opsera Limited is registered in the UK under Company Number 5396532. Our > registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From duncan.ferguson at opsera.com Thu Oct 15 09:32:06 2009 From: duncan.ferguson at opsera.com (Duncan Ferguson) Date: Thu, 15 Oct 2009 08:32:06 +0100 Subject: [Nagiosplug-devel] nagios plugin question In-Reply-To: <6db4a4200910142123k4b8ea42bj89177115cf174ef5@mail.gmail.com> References: <6db4a4200910131101x7e8397a7p3fcf97fc654918f@mail.gmail.com> <6db4a4200910142123k4b8ea42bj89177115cf174ef5@mail.gmail.com> Message-ID: <9822FDB3-D919-42B0-9953-F9B2A9E1CB7B@opsera.com> On 15 Oct 2009, at 05:23, shadih rahman wrote: > Thanks for your help. Just wanted to let you know Nagios::Object > module has a bug regarding nagios version 3. It does not work with > serviceescalation. If you are interested I can submit the patch. > Thanks Yup, interested - send me the patch with appropriate tests and I'll commit. Duncs -- Duncan Ferguson Senior Developer Opsera Limited | Unit 69 Suttons Business Park Reading | Berkshire | RG6 1AZ | UK Phone: +44 (0) 845 057 7887 Mobile: +44 (0) 7968 148 748 Skype: duncan_j_ferguson Email: duncan.ferguson at opsera.com www.opsera.com Opsera Limited is registered in the UK under Company Number 5396532. Our registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From noreply at sourceforge.net Sun Oct 18 22:32:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Oct 2009 20:32:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985317 ] check_ldap fails to report actual LDAP errors Message-ID: Bugs item #1985317, was opened at 2008-06-05 12:47 Message generated for change (Settings changed) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985317&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap fails to report actual LDAP errors Initial Comment: The following Bugreport we got against our debian package: The check_ldap plugin does this: % /usr/lib/nagios/plugins/check_ldap -H '' -b '' Could not bind to the ldap-server Whereas, tethereal reveals that the message received was: Lightweight Directory Access Protocol LDAP Message, Bind Result Message Id: 1 Message Type: Bind Result (0x01) Message Length: 64 Response To: 4 Time: 0.000067000 seconds Result Code: protocolError (0x02) Matched DN: (null) Error Message: historical protocol version requested, use LDAPv3 instead Now, why didn't check_ldap communicate that? Because it has this in the code (plugins/check_ldap.c): /* bind to the ldap server */ if (ldap_bind_s (ld, ld_binddn, ld_passwd, LDAP_AUTH_SIMPLE) != LDAP_SUCCESS) { /*ldap_perror(ld, "ldap_bind"); */ printf (_("Could not bind to the ldap-server\n")); return STATE_CRITICAL; } How hard was it to put that ldap_perror() string in the printf'ed error message? :( A quick grep for ldap_perror shows that there are other occurences of the same problem in the same file. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425137 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2009-10-18 22:32 Message: Fixed with 1.4.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985317&group_id=29880 From noreply at sourceforge.net Sun Oct 18 22:40:28 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Oct 2009 20:40:28 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2826570 ] check_http 1.4.13 does not work with some HTTPS servers Message-ID: Bugs item #2826570, was opened at 2009-07-24 15:37 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2826570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steffen (steffencl) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_http 1.4.13 does not work with some HTTPS servers Initial Comment: Hello, we recently made a nagios-plugin update which introduced check_http v1.4.13 (nagios-plugins 1.4.13) Since then checks of some HTTPS-servers faild with the error "HTTP CRITICAL - Error on receive" A detailed analysis and comparison with older version (1.4.12) revealed the following: For testing we used the plugin on the Linux shell (Debian sid) like this: /usr/lib/nagios/plugins/check_http -4 --ssl -v \ -H -I A tcp-connection from the nagios host to the webserver was opened with the normal TCP-handshakes. After that the nagios-plugin sends it's first SSL handshake packet ("Client Hello") to the webserver which is answered by a TCP-FIN packet to close the connection. The webserver logs a message indicating that the SSL compression method of the client is not supported. I analysed the SSL protocol and found that the old plugin does NOT include a compression method in it's "Client Hello" message while the new one does. The SSL Client Hello Packed decoded by whireshark of the NEW plugin looks like this: ---snip---- Secure Socket Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 109 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 105 Version: TLS 1.0 (0x0301) Random gmt_unix_time: Jul 24, 2009 13:42:28.000000000 random_bytes: 2930D11FA4... Session ID Length: 0 Cipher Suites Length: 38 Cipher Suites (19 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014) Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011) Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008) Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006) Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003) Compression Methods Length: 2 Compression Methods (2 methods) Compression Method: DEFLATE (1) Compression Method: null (0) Extensions Length: 25 Extension: server_name Type: server_name (0x0000) Length: 17 Data (17 bytes) Extension: SessionTicket TLS Type: SessionTicket TLS (0x0023) Length: 0 Data (0 bytes) ---snip---- While the SSL Client Hello Packed of an old plugin looks like this: ---snip---- Secure Socket Layer SSLv2 Record Layer: Client Hello Length: 116 Handshake Message Type: Client Hello (1) Version: TLS 1.0 (0x0301) Cipher Spec Length: 75 Session ID Length: 0 Challenge Length: 32 Cipher Specs (25 specs) Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014) Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011) Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Challenge ---snip---- As you see with no compression method field. We had no problems with version 1.4.12, but since 1.4.13 we have the described problems with some servers, primary with older servers and appliences useing HTTPS. There are no problems against apache servers. - Steffen ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-10-18 22:40 Message: Hi Steffen, could please let us know, against which device/Webserver you test the plugin? Noone of us is able to reproduce the problem. Thanks, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 16:36 Message: Steffen, please try tp reproduce this from the latest snapshot (you don't have to install it, just run check_http off the plugins/ directory). If you can reproduce it, then try applying the attached patch. If it still fails with the attached patch applied then please send debug output of check_http (add -vvv to the command line). The snapshots can be found here: http://nagiosplug.sourceforge.net/snapshot/ It turns out the version you are using is way past 1.4.13 and there are a few changes in the current tree that could change how check_http interacts with web servers. Thanks ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 15:20 Message: >From IRC: dermoth: stable: 0.9.8g-15+lenny3 and on unstable actually 0.9.8k-3 dermoth: you can also have a look at http://packages.debian.org/openssl ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-08-05 20:56 Message: > Obviously. As far as I can see it seems like a problem with the specific > OpenSSL package in debian, so unless you can come up with an openssl > version to test with I can't do much in term of debugging (I check many > SSL-enabled sites, and also have multiple succeeding tests on my tinderbox > and dev workstation). I rolled out the package recompiled against stable on our monitoring infrastructure. So fas we don't have any problems with our SSL-enabled sites there. But just out of kind, what maybe all apache webserver, which was stated as still working by the initial bug report. So we need to be supplied with a public available test sites, where we can reproduce the problem (by using the debian package from sid and maybe the lenny backported one and the one from stable). Steffen: please supply such a ssl-site if possible. > > > You shouldn't expect high stability out of debian Sid. > > > > Why not? Packages uploaded to sid (and migrating later to testing) are > > considered to be released in the next stable release. > > Then that is strange that Nagios-plugins has been updated to a git HEAD. > What makes matter worse is that uses often aren't well aware of development > process and in this case is was reported against 1.4.13. When I looked at > differences between 1.4.12 and 1.4.13 I was obviously missing a lot of > patches. Reasons was stated for example at http://blog.waja.info/2009/07/07/nagios-plugins-1413git200906171200-1-uploaded/ > > From Debian point of view, this is absolutely necessary to reproduce this > > bug (and maybe fixing, if needed). > > Could you at least check that latest sid is not affected on random SSL > sites. If it's only specific to certain setups and/or web servers then at > least it's not as critical. I've tested the following server on stable and sid: Server: Microsoft-IIS/7.0 Server: lighttpd/1.4.19 Server: nginx/0.7.60 Server: Apache No problem so far. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 15:15 Message: > > Well, then first of all you should have reported this against debian's > bug > > database (if you already did please link the bug #). It could be a > > debian-specific bug. > > Maybe and maybe not. :) Obviously. As far as I can see it seems like a problem with the specific OpenSSL package in debian, so unless you can come up with an openssl version to test with I can't do much in term of debugging (I check many SSL-enabled sites, and also have multiple succeeding tests on my tinderbox and dev workstation). > > It also looks like your package is based on a development version with > > known bugs. > > You was discussing to release months ago. So did guess that it would be > released "soon" (and is some kind of stable). A bunch of things went in since then... And we could have sent a release with the last blocker bug before I discovered it (check_snmp regression) but I'm sure it would have been discovered very quickly and we'd have to make a 2nd release to fix it. > > You shouldn't expect high stability out of debian Sid. > > Why not? Packages uploaded to sid (and migrating later to testing) are > considered to be released in the next stable release. Then that is strange that Nagios-plugins has been updated to a git HEAD. What makes matter worse is that uses often aren't well aware of development process and in this case is was reported against 1.4.13. When I looked at differences between 1.4.12 and 1.4.13 I was obviously missing a lot of patches. > > Finally it would be *very* helpful if you can reproduce this on an > > external http web site so I can test as well. > > From Debian point of view, this is absolutely necessary to reproduce this > bug (and maybe fixing, if needed). Could you at least check that latest sid is not affected on random SSL sites. If it's only specific to certain setups and/or web servers then at least it's not as critical. Thanks ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-08-05 11:31 Message: > Well, then first of all you should have reported this against debian's bug > database (if you already did please link the bug #). It could be a > debian-specific bug. Maybe and maybe not. :) > It also looks like your package is based on a development version with > known bugs. You was discussing to release months ago. So did guess that it would be released "soon" (and is some kind of stable). > You shouldn't expect high stability out of debian Sid. Why not? Packages uploaded to sid (and migrating later to testing) are considered to be released in the next stable release. > Finally it would be *very* helpful if you can reproduce this on an > external http web site so I can test as well. >From Debian point of view, this is absolutely necessary to reproduce this bug (and maybe fixing, if needed). With kind regards, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 06:42 Message: Well, then first of all you should have reported this against debian's bug database (if you already did please link the bug #). It could be a debian-specific bug. It also looks like your package is based on a development version with known bugs. You shouldn't expect high stability out of debian Sid. Finally it would be *very* helpful if you can reproduce this on an external http web site so I can test as well. Thanks ---------------------------------------------------------------------- Comment By: Steffen (steffencl) Date: 2009-07-27 20:58 Message: We use Debian "sid". OpenSSL was before the update and still is verion 0.9.8k 25 Mar 2009 According to Debian's update log the following has changed: [UPGRADE] nagios-nrpe-plugin 2.12-3 -> 2.12-3.1 [UPGRADE] nagios-plugins 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios-plugins-basic 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios-plugins-standard 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios3 3.0.6-4 -> 3.0.6-5 [UPGRADE] nagios3-common 3.0.6-4 -> 3.0.6-5 [UPGRADE] nagios3-doc 3.0.6-4 -> 3.0.6-5 Since we use packages of provided by or for the used distribution, we do not compile but use the packagetmanager of the distribution (here Debian sid). - Steffen ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-07-25 03:51 Message: Hi, and thanks for your report. I checked the change logs between these two release and there's absolutely no difference between 1.4.12 and 1.4.13 that could explain this (the only change that affects what check_http sends is that is doesn't send the defaut port anymore on the Host: line - RFC 2616). My best guess would be a change in your OpenSSL installation. Can you try recompiling 1.4.12 from scratch (don't re-use your previous compile tree)? It would also be nice to know: - Your configure parameters - Your OpenSSL version - An externally accessible server to test with, if possible. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2826570&group_id=29880 From holger at CIS.FU-Berlin.DE Sat Oct 24 22:50:32 2009 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 24 Oct 2009 22:50:32 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> Message-ID: <20091024205032.GB72531946@Waran.CIS.FU-Berlin.DE> * Ton Voon [2009-05-22 10:27]: > I would personally prefer one email per commit as it is easier to?? > glance at what is happening and just read the subject to get an idea?? > of the changes and the importance. The 5 minute delay is not a big deal. >? > A quick look at the nagiosplug-checkins list (which has 181 members)?? > shows out of 38 members, 4 wanted a digest. So 90% of the members to?? > this list prefer individual emails. If git sends out individual?? > emails, then the list digest would act as the summary view. >? > However, I'd cede to the majority if a summarised view is preferred. That doesn't seem to be the case. Therefore, I now grabbed (and modified) a copy of the git-notify script (maintained by the Wine people), which generates one e-mail per commit *see tools/git-notify in our repository). Our version of the script will also send notifications if tags or branch heads are created or deleted, or if the history is rewritten. The generated e-mails look somewhat similar to the Subversion commit notifications we currently get. See, for example: ftp://ftp.in-berlin.de/pub/users/weiss/nagios/plugins/commit-mails/example-2.txt If nobody objects, I'll switch our setup over to the new script sometime next week. Holger From dermoth at aei.ca Sun Oct 25 22:41:39 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 25 Oct 2009 17:41:39 -0400 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <20091024205032.GB72531946@Waran.CIS.FU-Berlin.DE> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <20091024205032.GB72531946@Waran.CIS.FU-Berlin.DE> Message-ID: <4AE4C613.7020707@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/10/09 04:50 PM, Holger Wei? wrote: > > The generated e-mails look somewhat similar to the Subversion commit > notifications we currently get. See, for example: > > ftp://ftp.in-berlin.de/pub/users/weiss/nagios/plugins/commit-mails/example-2.txt > > If nobody objects, I'll switch our setup over to the new script sometime > next week. When you do that you can comment-out the cron jobs on the team server. If the new email script works well we'll be able to use the new snapshot scripts (I'll push Ton to make the switch - which is quite easy - when I see him in a few days) and we'll be good to decommission the subversion repository. Thanks for all your great work on this Holger! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFK5MYS6dZ+Kt5BchYRAtzEAKCG7SAMj3qX57t4pm3FhbqMeMHU0ACeK08A NwI1I3j/ZO1iRocwTYJ5n2o= =uqH+ -----END PGP SIGNATURE-----