From dermoth at aei.ca Sat Aug 1 01:35:11 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 31 Jul 2009 19:35:11 -0400 Subject: [Nagiosplug-devel] check_snmp: Anyone ever used per-oid labels? Message-ID: <4A737FAF.4060709@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Seems like that highly undocumented and unintuitive feature actually exists. I was trying to decipher the code parsing the label string (which at first glance seems to be overcomplicated). I'm still unsure how it was meant to work, but here's my findings so far (given a command with 3 oids and 3 thresholds): - --label "foo,bar,baz,bad" Sets only the first label to "foo", the rest is ignored. Seems like commas could be used to specify multiple labels - --label "'foo bar baz bad'" - --label "'foo' bar baz bad" A string starting with a single quote sets the label to an empty string, no matter what follow. If the first character is not a single quote any quote that follow is printed in the label. - --label "foo" --label "bar" --label "baz" --label "bad" The first label is "bad" (always the last one), then each oid result is prefixed by the labels in order. ex: bad OK - foo 2.6 bar 4 baz 6371090 - --label "foo" --label "bar" Since there's less labels than the number of OIDs, no oid is prefixed and the front label is "bar". My thoughts: 1. The single quote thing is nonsense 2. The front label should be the first passed label, not the last one 3. Any subsequent labels should be used for prefixing the OIDs 4. Labels should be used even if there more OIDs than labels 5. Commas should be another way of passing multiple labels 6. The whole thing should be documented! 2 and 3 would break backwards compatibility, but I doubt there are many users that figured out yet without any doc, and IMHO it would be much more intuitive. Any thoughts? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKc3+v6dZ+Kt5BchYRApj/AKDa6oGfOdB/1GsQKc/bybXEFD3p0gCfVM4a msHjNWTVKAJ2XCD8GQI0cAs= =E+Ng -----END PGP SIGNATURE----- From ewelch at nvidia.com Sun Aug 2 16:43:00 2009 From: ewelch at nvidia.com (Erik Welch) Date: Sun, 2 Aug 2009 07:43:00 -0700 Subject: [Nagiosplug-devel] max clients on nagios host In-Reply-To: <4D65ACEF6EFDFB48A8F9B57B7D17B9BF05DEEF2D@tfusnjpscmbx03.ERF.THOMSON.COM> References: <4D65ACEF6EFDFB48A8F9B57B7D17B9BF05DEEF2D@tfusnjpscmbx03.ERF.THOMSON.COM> Message-ID: <18A1316EEEE31E46AC536571A107579B15750875D1@HQMAIL01.nvidia.com> On one of our nagios servers that deals with a compute farm, it checks almost 40K services across over 5000 hosts. The issue you are describing sounds a lot like you have multiple instances of nagios running. I've seen this with using the 'restart' option to the init script. I would recommend either a reload, or a full 'stop' and then manual kill of any running daemons before the start. erik ________________________________ From: eva.keane at tradeweb.com [mailto:eva.keane at tradeweb.com] Sent: Thursday, July 30, 2009 5:34 AM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] max clients on nagios host Hello, I have added 210 clients for a nagios host to monitor.... I am wondering what the maximum for a host to monitor. I am experience that if I added more hosts; I am experience strange behavior in that I have to refresh to see the new clients services, and if I refresh again... the services disappear...the clients doesn't appear as client unless I search for it... etc.... -Eva ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From liulantao at gmail.com Mon Aug 3 04:50:59 2009 From: liulantao at gmail.com (Liu Lantao) Date: Mon, 3 Aug 2009 10:50:59 +0800 Subject: [Nagiosplug-devel] How to use my shell script in Nagios In-Reply-To: <607405810.6061249074824571.JavaMail.root@mbr24.indiatimes.com> References: <607405810.6061249074824571.JavaMail.root@mbr24.indiatimes.com> Message-ID: Hi, You should place your monitor.sh into /usr/local/nagios/libexec/ first, then define the command in the config file, /usr/local/nagios/etc/object/commands.cfg for example. then you can define your services using this command. the command may like this: define command{ command_name check-my-monitor command_line $USER1$/monitor.sh $ARG1$ } and your service may like this: define service{ use local-service host_name localhost service_description My-Monitor check_command check-my-monitor } On Sat, Aug 1, 2009 at 5:13 AM, sunil naik wrote: > Dear team > > > Please let us know how i Use my monitor.sh scripts in Nagios plugin > > > > > Regards > Sunil Naikwadi > > > -- > Click for exclusive coverage on the New Bajaj Pulsar 220 the fastest Indian > bike > > http://www.zigwheels.com/Features/Bajaj-Pulsar-220-DTSi-Special-Coverage/Pulsar_20090623-1-1 > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________________ > 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 > -- Liu Lantao College of Information Science and Technology, Beijing Normal University EMAIL: liulantao ( at ) gmail ( dot ) com ; WEBSITE: http://www.liulantao.com/ . ------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunilnaikwadi04 at indiatimes.com Tue Aug 4 11:42:10 2009 From: sunilnaikwadi04 at indiatimes.com (sunil naik) Date: Tue, 4 Aug 2009 15:12:10 +0530 (IST) Subject: [Nagiosplug-devel] How to use my shell script in Nagios In-Reply-To: Message-ID: <1222616333.23911249378930455.JavaMail.root@mbr24.indiatimes.com> Hi As per the instruction we did the same and my scripts working fine in nagios Regards Sunil Naikwadi ----- Original Message ----- From: Liu Lantao To: sunilnaikwadi04 at indiatimes.com Cc: Nagios Plugin Development Mailing List Sent: Mon, 3 Aug 2009 08:20:59 +0530 (IST) Subject: Re: [Nagiosplug-devel] How to use my shell script in Nagios Hi, You should place your monitor.sh into /usr/local/nagios/libexec/ first, then define the command in the config file, /usr/local/nagios/etc/object/commands.cfg for example. then you can define your services using this command. the command may like this: define command{ command_name check-my-monitor command_line $USER1$/monitor.sh $ARG1$ } and your service may like this: define service{ use local-service host_name localhost service_description My-Monitor check_command check-my-monitor } On Sat, Aug 1, 2009 at 5:13 AM, sunil naik wrote: Dear team Please let us know how i Use my monitor.sh scripts in Nagios plugin Regards Sunil Naikwadi -- Click for exclusive coverage on the New Bajaj Pulsar 220 the fastest Indian bike http://www.zigwheels.com/Features/Bajaj-Pulsar-220-DTSi-Special-Coverage/Pulsar_20090623-1-1 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________________ 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 -- Liu Lantao College of Information Science and Technology, Beijing Normal University EMAIL: liulantao ( at ) gmail ( dot ) com ; WEBSITE: http://www.liulantao.com/ . ------ -- Click for exclusive coverage on the New Bajaj Pulsar 220 the fastest Indian bike http://www.zigwheels.com/Features/Bajaj-Pulsar-220-DTSi-Special-Coverage/Pulsar_20090623-1-1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Aug 5 06:42:49 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 04:42:49 +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 09:37 Message generated for change (Comment added) made by dermoth 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: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 00: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 14: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-24 21: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 noreply at sourceforge.net Wed Aug 5 06:51:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 04:51:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2832451 ] check_snmp regression - parsing multi-line snmpget responses Message-ID: Bugs item #2832451, was opened at 2009-08-05 00:51 Message generated for change (Tracker Item Submitted) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832451&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: 8 Private: No Submitted By: Thomas Guyot-Sionnest (dermoth) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_snmp regression - parsing multi-line snmpget responses Initial Comment: Bug #1985230 removed some badly written (though seemingly working) code that enabled parsing multi-line STRING responses from snmpget, causing it to segfault. The segfault has been fixed already (sort of - plugins doesn't return OK yet), and a test case has been added to tests/check_snmp.t. Since I haven't had time to fix it yet I'm opening this bug to ease tracking this regression. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832451&group_id=29880 From noreply at sourceforge.net Wed Aug 5 09:05:34 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 07:05:34 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2632995 ] check_procs fails on Solaris Message-ID: Bugs item #2632995, was opened at 2009-02-24 04:08 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2632995&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: Werner (forsbring) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_procs fails on Solaris Initial Comment: Hi, check_procs v2019 (nagios-plugins 1.4.13) exits with "Unable to read output" on most of our Solaris8 and Solaris 10 servers (I do not have access to any Solaris9 servers). 1.4.11 works just fine. I've attached the truss output. - Werner ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 03:05 Message: Please try the attached patch. If you don't have the required tools to run tools/setup (can be done from another machine; it doesn't have to be solaris) let me know and I'll make you a snapshot. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-17 03:42 Message: Sorry for the late reply... According pst3 header comment (I have no idea how it compares to "ps" though): * This executable works by reading process address structures, so needs * to be executed as root Regarding 64bits, I might be wrong but IIRC that's needed to get data about 64bit processes. Maybe that's somehow related to the root requisite as well, since it's probably a different way than "ps". I will have to look for a way to support cleanly both compilers, probably using autoconf. I'll look further into this when I can. Thanks ---------------------------------------------------------------------- Comment By: Werner (forsbring) Date: 2009-03-12 09:23 Message: Nope, not trying to run from source repository. But after looking into the buildlogs I guess I found the problem. You assume we use gcc, and the compiler option -m64 is used for pst3, which is not working with cc from older SunStudio. Why do pst3 have to be setuid root when /usr/bin/ps and /usr/ucp/ps don't? And regarding the 64-bit requirement, why? Almost no other binaries on Solaris is 64-bit. The pst3-thing seems like a ugly hack to me, sorry. :) - Werner ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-24 04:29 Message: Thanks for the debug output. Nagios-plugins now use pst3 to get the process list and this program needs to be installed and setuid root (I think old versions of nagios-plugins used it too, so you may have it already on some servers). It looks like you're trying to run from the source repository. Be sure to install the plugins, or at least hand-install pst3 (in plugins-root/ directory, don't forget to setuit root). If you still have issues I'll be able to help you is you can send the truss output again with the option to follow forks (-f). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2632995&group_id=29880 From noreply at sourceforge.net Wed Aug 5 11:31:17 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 09:31:17 +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-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 noreply at sourceforge.net Wed Aug 5 15:15:36 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 13:15:36 +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 09:37 Message generated for change (Comment added) made by dermoth 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: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 09: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 05: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 00: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 14: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-24 21: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 noreply at sourceforge.net Wed Aug 5 20:56:26 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 18:56:26 +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-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 noreply at sourceforge.net Wed Aug 5 22:15:37 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 20:15:37 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2832817 ] check_ping ignores -4 option Message-ID: Bugs item #2832817, was opened at 2009-08-05 16:15 Message generated for change (Tracker Item Submitted) made by phalenor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832817&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: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Cobaugh (phalenor) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping ignores -4 option Initial Comment: check_ping v1991 (nagios-plugins 1.4.13) Solaris 10u5 sparc check_ping ignores -4 option when the host passed with -H is a hostname which has both A and AAAA records associated with it. Expected behavior is that -4 forces check_ping to use an IPv4 address returned from an A record lookup of the host if a hostname is provided. This is the behavior seen with other plugins such as check_ssh, which correctly query over only IPv4 or IPv6 with -4 or -6 are passed, respectively. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832817&group_id=29880 From noreply at sourceforge.net Thu Aug 6 00:48:41 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 22:48:41 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2832884 ] translation of --help broken Message-ID: Bugs item #2832884, was opened at 2009-08-06 00:48 Message generated for change (Tracker Item Submitted) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832884&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: Interface (example) Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: translation of --help broken Initial Comment: Hi there, looks like the translation of the help is somewhat broken in general. At least for LANG=de_DE.UTF-8, LANG=fr_FR.UTF-8 and check_dhcp, check_disk, where I can confirm the problem. The following Bugreport we got against our debian package: On my french system : ====================================== [root at kayak]:~ # /usr/lib/nagios/plugins/check_dhcp --help check_dhcp v1991 (nagios-plugins 1.4.12) Copyright (c) 2001-2004 Ethan Galstad (nagios at nagios.org) Copyright (c) 2001-2007 Nagios Plugin Development Team Ce plugin teste la disponibilit? de serveurs DHCP dans un r?seau. Utilisation: check_dhcp [-v] [-u] [-s serverip] [-r requestedip] [-t timeout] [-i interface] [-m mac] Options: -h, --help Print detailed help screen -V, --version Print version information Project-Id-Version: fr Report-Msgid-Bugs-To: nagiosplug-devel at lists.sourceforge.net POT-Creation-Date: 2008-05-27 23:06+0100 PO-Revision-Date: 2007-12-10 02:10-0500 Last-Translator: Thomas Guyot-Sionnest Language-Team: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=(n != 1); X-Generator: KBabel 1.11.4 -v, --verbose Show details for command-line debugging (Nagios may truncate output) -s, --serverip=IPADDRESS IP address of DHCP server that we must hear from -r, --requestedip=IPADDRESS IP address that should be offered by at least one DHCP server -t, --timeout=INTEGER Seconds to wait for DHCPOFFER before timeout occurs -i, --interface=STRING Interface to to use for listening (i.e. eth0) -m, --mac=STRING MAC address to use in the DHCP request -u, --unicast Unicast testing: mimic a DHCP relay, requires -s Send email to nagios-users at lists.sourceforge.net if you have questions regarding use of this software. To submit patches or suggest improvements, send email to nagiosplug-devel at lists.sourceforge.net ======================================= There is the translator info into the translation... You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522631 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2832884&group_id=29880 From noreply at sourceforge.net Thu Aug 6 00:59:41 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Aug 2009 22:59:41 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2812592 ] check_linux_raid returns UNKNOWN for md10 and above Message-ID: Bugs item #2812592, was opened at 2009-06-26 08:53 Message generated for change (Settings changed) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2812592&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: Release (specify) Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_linux_raid returns UNKNOWN for md10 and above Initial Comment: The following Bugreport we got against our debian package (1.4.12): check_linux_raid malfunctions if system has software RAID devices with two or more digits. For example, for system having /dev/md10, /dev/md11 etc, the plugin returns 'UNKNOWN' in automatic mode (if RAID devices are manually specified it works). Also, if system has both one-digit, and two-digit RAID devices, the two-digit devices are silently ignored in checks, which is even more problematic. Problem is that plugin checks only for 'md[0-9]' devices in /proc/mdstat. Trivial patch which fixes that by looking for 'md[0-9]+' instead is attached. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534604 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2812592&group_id=29880 From hir3npatel at gmail.com Fri Aug 7 17:19:58 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Fri, 07 Aug 2009 17:19:58 +0200 Subject: [Nagiosplug-devel] NRPE Protocol In-Reply-To: <4A422DDD.6080504@wyraz.de> References: <4A422DDD.6080504@wyraz.de> Message-ID: <4A7C461E.2070103@gmail.com> Michael Wyraz wrote: > If there's interest I'd like to discuss how the protocol could be > improved. My suggestions are: > - document it somewhere ;-) > - change the structure to make it more flexible: 2 byte version, 2 byte > packed, 2 byte response code, 2 byte payload length, the payload with a > variable length instead of null-terminated > - move the checksum to the end. this makes the implementation in other > languages more easy since it's not necessary to add a placeholder while > constructing the message or calculating the checksum. > - use a HMAC checksum based on a shared secret. This seems to be the > easiest way to add secure authentication to the protocol. When using a > "default secret" it has the same functionality as a normal checksum > - add some "nonce" to the protocol to prevent reply attacks. This adds > more security even if ssl is not used: client connects, server sends a > random sequence, this sequence is included on the client side to > calculate the checksum. The client adds his own "nonce" to the response > so it can check that the server's answer is not a replay. A disadvantage > is that this requires 1 more step in the communication but when the > initial nonce is set to a fixed length, it's really easy to implement. > > Please tell me if you have feedback to this suggestions or to the > protocol description (I'll add this description to one of the wikis > these days). > I have no experience with the protocol, but what you're saying sounds interesting. I'd say make the changes and submit the patches, if the changes do improve the protocol and work better, I don't see why it would not be accepted. many nagios users use nrpe, if these improve it in ways, I don't see why a new major release with the protocol redo (if it's not backward compatible) would not be considered. From lists at wyraz.de Mon Aug 10 11:03:27 2009 From: lists at wyraz.de (Michael Wyraz) Date: Mon, 10 Aug 2009 11:03:27 +0200 Subject: [Nagiosplug-devel] NRPE Protocol In-Reply-To: <4A7C461E.2070103@gmail.com> References: <4A422DDD.6080504@wyraz.de> <4A7C461E.2070103@gmail.com> Message-ID: <4A7FE25F.40808@wyraz.de> When deploying nagios to our servers (using nrpe) I found that the current implementation using ssl with anonymous dh has some disadvantages in security (missing authentication) so that extra setup it required (e.d. stunnel or ssh) which makes deployment to clients more complex. Since the manual says "there's ssl", most users would not even notice that there might be a problem. Later when I developed my own server implementation to connect Nagios to one of our applications, I found that it's really hard to find a documentation of the protocol (in fact there's only the source code) and that the protocol is very simple, restricted and tied to the c language. These where the reasons for me to start this discussion ;-) Meanwhile I discovered one interesting thing that made me re-thing my suggestion to the protocol: http://hessian.caucho.com/ - this is a more or less standardized binary protocol that is simple, efficient, well-documented (http://hessian.caucho.com/doc/hessian-serialization.html) and availiable for most languages. So I would recommend to use this as base for the new protocol. To the plain protocol different levels of encryption and/or signing could be added. This could either be done using a shared secret (simples way) or by using certificates (IMO the best way; but has the disadvantage that for each node a certificate must be created). Another interesting approach it to use a splitted shared secret that consists of one part that is put to the command definition (or to an external file to prevent that it's read via web interface) plus an second part that is defined in the host configuration. Both together would build the really used shared secret. This would it allow to use different shared secrets for each host while keeping the setup simple and without exposing the secrets to the Nagios web interface. If you have more suggestions to this, let it discuss here. If there are some crypto experts in this list, please take in the discussion how the nrpe communication can be secured while keeping things easy. Unfortunately I'm not a C programmer, so I cannot do these changes on Nagios in a good quality. But if we reach a final "spec", I can document it somewhere and I could provide a reference implementation in Java. Regards, Michael. Hiren Patel wrote: > Michael Wyraz wrote: > > >> If there's interest I'd like to discuss how the protocol could be >> improved. My suggestions are: >> - document it somewhere ;-) >> - change the structure to make it more flexible: 2 byte version, 2 byte >> packed, 2 byte response code, 2 byte payload length, the payload with a >> variable length instead of null-terminated >> - move the checksum to the end. this makes the implementation in other >> languages more easy since it's not necessary to add a placeholder while >> constructing the message or calculating the checksum. >> - use a HMAC checksum based on a shared secret. This seems to be the >> easiest way to add secure authentication to the protocol. When using a >> "default secret" it has the same functionality as a normal checksum >> - add some "nonce" to the protocol to prevent reply attacks. This adds >> more security even if ssl is not used: client connects, server sends a >> random sequence, this sequence is included on the client side to >> calculate the checksum. The client adds his own "nonce" to the response >> so it can check that the server's answer is not a replay. A disadvantage >> is that this requires 1 more step in the communication but when the >> initial nonce is set to a fixed length, it's really easy to implement. >> >> Please tell me if you have feedback to this suggestions or to the >> protocol description (I'll add this description to one of the wikis >> these days). >> >> > > I have no experience with the protocol, but what you're saying sounds > interesting. I'd say make the changes and submit the patches, if the > changes do improve the protocol and work better, I don't see why it > would not be accepted. > many nagios users use nrpe, if these improve it in ways, I don't see why > a new major release with the protocol redo (if it's not backward > compatible) would not be considered. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hir3npatel at gmail.com Mon Aug 10 11:37:07 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Mon, 10 Aug 2009 11:37:07 +0200 Subject: [Nagiosplug-devel] NRPE Protocol In-Reply-To: <4A7FE25F.40808@wyraz.de> References: <4A422DDD.6080504@wyraz.de> <4A7C461E.2070103@gmail.com> <4A7FE25F.40808@wyraz.de> Message-ID: <4A7FEA43.5030205@gmail.com> Michael Wyraz wrote: > Meanwhile I discovered one interesting thing that made me re-thing my > suggestion to the protocol: http://hessian.caucho.com/ - this is a more > or less standardized binary protocol that is simple, efficient, > well-documented > (http://hessian.caucho.com/doc/hessian-serialization.html) and > availiable for most languages. So I would recommend to use this as base > for the new protocol. > > To the plain protocol different levels of encryption and/or signing > could be added. This could either be done using a shared secret (simples > way) or by using certificates (IMO the best way; but has the > disadvantage that for each node a certificate must be created). > Another interesting approach it to use a splitted shared secret that > consists of one part that is put to the command definition (or to an > external file to prevent that it's read via web interface) plus an > second part that is defined in the host configuration. Both together > would build the really used shared secret. This would it allow to use > different shared secrets for each host while keeping the setup simple > and without exposing the secrets to the Nagios web interface. > > > If you have more suggestions to this, let it discuss here. If there are > some crypto experts in this list, please take in the discussion how the > nrpe communication can be secured while keeping things easy. > to me, two things stand out to convince the developers to change the protocol: the security advantage is needed and useful, and that a redo would be better and more efficient. if most people are using nrpe on a trusted network, I don't see the developers being overly convinced to make the change, and if the new implementation isn't better in some way, likewise. not many of the users have asked for better security from nrpe as far as I know, I'd be interested to hear what the developers think of a protocol redo. From noreply at sourceforge.net Tue Aug 11 15:20:14 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Aug 2009 13:20:14 +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 09:37 Message generated for change (Comment added) made by dermoth 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: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 09: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 14: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 09: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 05: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 00: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 14: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-24 21: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 noreply at sourceforge.net Tue Aug 11 16:36:32 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Aug 2009 14:36:32 +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 09:37 Message generated for change (Comment added) made by dermoth 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: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 10: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 09: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 14: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 09: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 05: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 00: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 14: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-24 21: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 dermoth at aei.ca Wed Aug 12 04:11:14 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 11 Aug 2009 22:11:14 -0400 Subject: [Nagiosplug-devel] NRPE Protocol In-Reply-To: <4A7FEA43.5030205@gmail.com> References: <4A422DDD.6080504@wyraz.de> <4A7C461E.2070103@gmail.com> <4A7FE25F.40808@wyraz.de> <4A7FEA43.5030205@gmail.com> Message-ID: <4A8224C2.3020603@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/08/09 05:37 AM, Hiren Patel wrote: > Michael Wyraz wrote: >> Meanwhile I discovered one interesting thing that made me re-thing my >> suggestion to the protocol: http://hessian.caucho.com/ - this is a more >> or less standardized binary protocol that is simple, efficient, >> well-documented >> (http://hessian.caucho.com/doc/hessian-serialization.html) and >> availiable for most languages. So I would recommend to use this as base >> for the new protocol. >> >> To the plain protocol different levels of encryption and/or signing >> could be added. This could either be done using a shared secret (simples >> way) or by using certificates (IMO the best way; but has the >> disadvantage that for each node a certificate must be created). >> Another interesting approach it to use a splitted shared secret that >> consists of one part that is put to the command definition (or to an >> external file to prevent that it's read via web interface) plus an >> second part that is defined in the host configuration. Both together >> would build the really used shared secret. This would it allow to use >> different shared secrets for each host while keeping the setup simple >> and without exposing the secrets to the Nagios web interface. >> >> >> If you have more suggestions to this, let it discuss here. If there are >> some crypto experts in this list, please take in the discussion how the >> nrpe communication can be secured while keeping things easy. >> > > to me, two things stand out to convince the developers to change the > protocol: the security advantage is needed and useful, and that a redo > would be better and more efficient. > if most people are using nrpe on a trusted network, I don't see the > developers being overly convinced to make the change, and if the new > implementation isn't better in some way, likewise. > not many of the users have asked for better security from nrpe as far as > I know, I'd be interested to hear what the developers think of a > protocol redo. > - From my point of view NRPE definitely need some enhancements. Given the same functionality, such enhancements should allow: 1. Extensibility (security, encryption, supporting current and future plugin formats) 2. Backward-compatibility (allowing older client and servers to communicate, using a version field to guarantee future version compatibility). If anyone can come up with a well designed protocol it will likely get adopted for future versions of NRPE. The best would probably be starting a design on a Wiki and looking for input from the rest of the community. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKgiTC6dZ+Kt5BchYRAttXAJ9A7ANFsi0UGZekA7d9ZrepaBAZ6gCglbbI bNA1aZpAXdQAVdnfxhEnUG4= =EH6Q -----END PGP SIGNATURE----- From noreply at sourceforge.net Thu Aug 13 10:39:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Aug 2009 08:39:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2836780 ] check_ntp_xxx ntpd failure handling Message-ID: Bugs item #2836780, was opened at 2009-08-13 08:39 Message generated for change (Tracker Item Submitted) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_xxx ntpd failure handling Initial Comment: check_ntp and check_ntp_time have both been returning errors recently - compiled up new binaries from nagios-plugins-trunk-200908120000.tar.gz and they show the same behaviour, returning occasional "Offset unknown" messages. This has been traced back to ntpd occasionally unselecting all ntp servers so the plugin doesn't know which server to refer against, returning the error. The plugin should return a more meaningful error about no selected ntp server This was seen on Ubuntu Hardy 8.04 on both 32 and 64 bit servers compiled with gcc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&group_id=29880 From basti at 2-die-4.tk Thu Aug 13 16:58:20 2009 From: basti at 2-die-4.tk (Basti Schubert) Date: Thu, 13 Aug 2009 16:58:20 +0200 Subject: [Nagiosplug-devel] check_nt segfaulting when trying to query hdd usage for non existent drive Message-ID: <4A842A0C.9040903@2-die-4.tk> hi there, the check_nt plugin spews on the client output someone already did a patch (http://www.freebsd.org/cgi/query-pr.cgi?pr=128220) but it was not yet accepted or whatever. i fixed the patch so it'll apply to the current version of the plugins (1.4.13) cheers basti -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_nt.patch URL: From noreply at sourceforge.net Fri Aug 14 01:10:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Aug 2009 23:10:30 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2836780 ] check_ntp_xxx ntpd failure handling Message-ID: Bugs item #2836780, was opened at 2009-08-13 04:39 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ntp_xxx ntpd failure handling Initial Comment: check_ntp and check_ntp_time have both been returning errors recently - compiled up new binaries from nagios-plugins-trunk-200908120000.tar.gz and they show the same behaviour, returning occasional "Offset unknown" messages. This has been traced back to ntpd occasionally unselecting all ntp servers so the plugin doesn't know which server to refer against, returning the error. The plugin should return a more meaningful error about no selected ntp server This was seen on Ubuntu Hardy 8.04 on both 32 and 64 bit servers compiled with gcc ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-13 19:10 Message: Sure we can change the text; I'm curious though what you think of when you say "a more meaningful error". A more descriptive one could be "No suitable peer for time synchronization" but I don't see how this could be more "meaningful" for an end user :) Any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&group_id=29880 From noreply at sourceforge.net Fri Aug 14 10:25:37 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Aug 2009 08:25:37 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2836780 ] check_ntp_xxx ntpd failure handling Message-ID: Bugs item #2836780, was opened at 2009-08-13 08:39 Message generated for change (Comment added) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ntp_xxx ntpd failure handling Initial Comment: check_ntp and check_ntp_time have both been returning errors recently - compiled up new binaries from nagios-plugins-trunk-200908120000.tar.gz and they show the same behaviour, returning occasional "Offset unknown" messages. This has been traced back to ntpd occasionally unselecting all ntp servers so the plugin doesn't know which server to refer against, returning the error. The plugin should return a more meaningful error about no selected ntp server This was seen on Ubuntu Hardy 8.04 on both 32 and 64 bit servers compiled with gcc ---------------------------------------------------------------------- >Comment By: Duncan Ferguson (duncan_ferguson) Date: 2009-08-14 08:25 Message: "No suitable peer for time synchronization" is a lot more meaningful for this problem than just "Offset known" as at least it gives a clue where the error might be for further investigation by them ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-13 23:10 Message: Sure we can change the text; I'm curious though what you think of when you say "a more meaningful error". A more descriptive one could be "No suitable peer for time synchronization" but I don't see how this could be more "meaningful" for an end user :) Any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2836780&group_id=29880 From sp at tdchosting.dk Fri Aug 14 11:26:19 2009 From: sp at tdchosting.dk (Steffen Poulsen) Date: Fri, 14 Aug 2009 11:26:19 +0200 Subject: [Nagiosplug-devel] FW: [Nagiosplug-help] check_http - how to output failing url + failing regexp? Message-ID: <995380CA30455549A6B8C57CE5A47AE54C1C9D1EF9@TDCHEXBE01.int.tdch.dk> Hi, Sent this to the -help list a few days ago with no reply, so I'll try my luck here also. Anyone with a comment? Steffen From: Steffen Poulsen [mailto:sp at tdchosting.dk] Sent: 11. august 2009 11:24 To: Nagios Plugin Help List Subject: [Nagiosplug-help] check_http - how to output failing url + failing regexp? Hi all, When a check_http check fails, it looks like there is currently no information in the nagios console, regarding on _what_ condition the check failed exactly. We were wondering if there was a reason this information is not reported already? It would indeed be very helpful to those working with the alerts to see i.e. what url and what string/regex failed exactly. A couple of examples on current output: Current output, OK: ./check_http -H fqdn -u /self_check.php -p 80 -w 5 -c 10 -t 60 -e "200" -s "EVERYTHING_IS_OK" HTTP OK HTTP/1.1 200 OK - 0.328 second response time |time=0.327952s;5.000000;10.000000;0.000000 size=815B;;;0 Current output, string not found: ./check_http -H fqdn -u /self_check.php -p 80 -w 5 -c 10 -t 60 -e "200" -s "EVERYTHING_IS_OK" CRITICAL - string not found|time=0.025742s;5.000000;10.000000;0.000000 size=815B;;;0 Current output, unexpected response code: ./check_http -H fqdn -u /self_check.php -p 80 -w 5 -c 10 -t 60 -e "200" -s "EVERYTHING_IS_OK" Invalid HTTP response received from host The output for the OK scenario is OK, I believe, but we would like to decorate the output for the other scenarios, perhaps along this line: Improved output, string not found: ./check_http -H fqdn -u /self_check.php -p 80 -w 5 -c 10 -t 60 -e "200" -s "EVERYTHING_IS_OK" CRITICAL: http:// fqdn/self_check.php - String not found: EVERYTHING_IS_OK|time=0.025742s;5.000000;10.000000;0.000000 size=815B;;;0 Improved output, unexpected response code: ./check_http -H fqdn -u /self_check.php -p 80 -w 5 -c 10 -t 60 -e "200" -s "EVERYTHING_IS_OK" CRITICAL: http:// fqdn/self_check.php - Header content not found: 200|time=0.025742s;5.000000;10.000000;0.000000 size=815B;;;0 We looked around for other check_http plugins that might be more "human-oriented" in their output, but found none - so we believe our best bet is to try to decorate this one, unless there's a good reason not to. Steffen -- Venlig hilsen / Best regards Steffen Poulsen UNIX System Administrator TDC Hosting A/S Phone: +45 70 26 25 27 E-mail: sp at tdchosting.dk Web: www.tdchosting.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Aug 17 02:54:53 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Aug 2009 00:54:53 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2838697 ] check_procs: Behave properly on OpenVZ hardware nodes Message-ID: Patches item #2838697, was opened at 2009-08-17 02:54 Message generated for change (Tracker Item Submitted) made by lfittl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2838697&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: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Fittl (lfittl) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs: Behave properly on OpenVZ hardware nodes Initial Comment: In an OpenVZ virtual environment: If you run "check_procs" on the hardware node, it returns information about all process on the hardware node + all virtual containers. It should of course ignore the virtual containers, as you would have a seperate NRPE server running in these. The attached patch solves this problem, by checking in /proc/PID/status if the process runs on the hardware node, or in one of the containers. This new codepath simply does nothing on non-OpenVZ/non-Linux systems. Patch against current master (check_procs v1.4.13.163.gb8a6.dirty) Tested on Debian Linux 5.0 "lenny", running in 64-bit mode. Thanks, Lukas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2838697&group_id=29880 From lukas at fittl.com Mon Aug 17 03:03:36 2009 From: lukas at fittl.com (Lukas Fittl) Date: Mon, 17 Aug 2009 03:03:36 +0200 Subject: [Nagiosplug-devel] [Patch] check_procs: Behave properly on OpenVZ hardware nodes Message-ID: <2606e6d00908161803v53836185g6ac3fe3922ea2758@mail.gmail.com> Hi everyone, check_procs has an issue where it would count all processes of all containers in an OpenVZ virtual environment [0], if run on the hardware node. This is due to "ps" exposing all processes, instead of just the processes of the hardware node. The following patch against the current HEAD fixes this problem: https://sourceforge.net/tracker/?func=detail&aid=2838697&group_id=29880&atid=397599 [0] http://wiki.openvz.org/Main_Page Thanks, Lukas -- Lukas Fittl Co-Founder, Soup.io http://fittl.com/ AT: +4369912770651 US: +15039290082 From noreply at sourceforge.net Wed Aug 19 14:35:37 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Aug 2009 12:35:37 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2075933 ] check_disk segfault on freebsd 7 if using -p option Message-ID: Bugs item #2075933, was opened at 2008-08-26 09:47 Message generated for change (Comment added) made by paulolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&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: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Coletta (creatore) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk segfault on freebsd 7 if using -p option Initial Comment: By using check_disk plugin on FreeBSD 7 with -p option it causes a segfault. The latest head CVS does not fix the problem. [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382811, available_to_root=1503833, used=8942, fsp.fsu_files=400382, fsp.fsu_ffree=398157 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Segmentation fault: 11 (core dumped) I've found that the segfault happens at this line on t he check_disk.c: 359: temp_result = get_status(dfree_inodes_percent, path->freeinodes_percent); [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -V check_disk v1991 (nagios-plugins 1.4.12) [root at server /]# uname -a FreeBSD server.***.** 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root at server /]# gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ---------------------------------------------------------------------- Comment By: Paulo Lange (paulolange) Date: 2009-08-19 08:35 Message: Hi. I have the same problem. # ./check_disk -w 20% -c 10% -vvv -p /var calling stat on /var calling stat on /var For /, total=75431085, available=62550318, available_to_root=68584804, used=6846281, fsp.fsu_files=19501054, fsp.fsu_ffree=18963514 For /, used_pct=10 free_pct=90 used_units=13371 free_units=122168 total_units=147326 used_inodes_pct=3 free_inodes_pct=97 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Segmentation fault ---------------------------------------------------------------------- Comment By: Stefano Coletta (creatore) Date: 2008-08-27 05:00 Message: Logged In: YES user_id=327996 Originator: YES rtp# gdb plugins/check_disk GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run -w 20% -c 10% -vvv -p /var Starting program: /usr/home/*******/nagios-plugins-1.4.12/plugins/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382783, available_to_root=1503805, used=8970, fsp.fsu_files=400382, fsp.fsu_ffree=398149 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Program received signal SIGSEGV, Segmentation fault. check_range (value=99, my_range=0x424d) at utils_base.c:168 168 if (my_range->alert_on == INSIDE) { (gdb) bt #0 check_range (value=99, my_range=0x424d) at utils_base.c:168 #1 0x0804cf83 in get_status (value=99, my_thresholds=0x2820b0ac) at utils_base.c:201 #2 0x0804b405 in main (argc=Error accessing memory address 0x0: Bad address. ) at check_disk.c:359 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2008-08-26 21:31 Message: Logged In: YES user_id=375623 Originator: NO Hi, Given the line you mentioned, it looks more like the segfault happened inside the get_status() function because temp_result is an integer. Could you try getting a backtrace from gdb? Run it from the source tree of nagios-plugins if possible. i.e.: $ gdb plugins/check_disk (gdb) run -w 20% -c 10% -vvv -p /var (gdb) bt And sent the full output of gdb. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 From shadhin71 at gmail.com Wed Aug 19 17:57:15 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Wed, 19 Aug 2009 11:57:15 -0400 Subject: [Nagiosplug-devel] check_ping plugin is not processing the -p option properly Message-ID: <6db4a4200908190857h7e6fd126s877262d7ac4986fc@mail.gmail.com> All, I have noticed that check_ping plugin is not processing the -p option properly. I have the following command definition define command{ command_name check-host-alive command_line $USER1$/check_ping -H $HOSTADDRESS$ t 45 -4 -w 3000.0,100% -c 3000.0,100% -p 1 } ./check_ping -H Hos A -p 1 -t 45 -4 -w 2000.0,30% -c 3000.0,40% PING CRITICAL - Packet loss = 50%, RTA = 2.50 ms|rta=2.498000ms;2000.000000;3000.000000;0.000000 pl=50%;30;40;0 If I am sending 1 packet, how is it possible to receive 50% packet loss. Please advise on this. Thanks -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadhin71 at gmail.com Wed Aug 19 18:35:20 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Wed, 19 Aug 2009 12:35:20 -0400 Subject: [Nagiosplug-devel] check_ping plugin is not processing the -p option properly In-Reply-To: <6db4a4200908190857h7e6fd126s877262d7ac4986fc@mail.gmail.com> References: <6db4a4200908190857h7e6fd126s877262d7ac4986fc@mail.gmail.com> Message-ID: <6db4a4200908190935p467558bmfd285a8c5b7727be@mail.gmail.com> I did some troubleshooting and found the following. -t option controls the actual -w option for /bin/ping if you add -t option in check_ping plugin then it add the -w option in /bin/ping command. If we don't put -t option then it automatically adds -w option with default 10 value so if we do '/bin/ping -n -U -w 10 -c 1 host A' the following is the output PING host A (x.x.x.x) 56(84) bytes of data. 64 bytes from 128.59.60.22: icmp_seq=4 ttl=59 time=2.95 ms --- unixrack5-ups1.cc.columbia.edu ping statistics --- 4 packets transmitted, 1 received, 75% packet loss, time 3002ms rtt min/avg/max/mdev = 2.952/2.952/2.952/0.000 ms however if you do '/bin/ping -n -U -c 1 host A' we get the following output PING host A (x.x.x.x) 56(84) bytes of data. --- unixrack5-ups1.cc.columbia.edu ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Would it be possible not to add the -w option by default. Please advise on this. Thanks P. S - I am running rhel 5 with kernel version 2.6.18-128.2.1.el5 On Wed, Aug 19, 2009 at 11:57 AM, shadih rahman wrote: > All, > I have noticed that check_ping plugin is not processing the -p option > properly. > > I have the following command definition > > define command{ > command_name check-host-alive > command_line $USER1$/check_ping -H $HOSTADDRESS$ t 45 -4 -w > 3000.0,100% -c 3000.0,100% -p 1 > } > > > ./check_ping -H Hos A -p 1 -t 45 -4 -w 2000.0,30% -c 3000.0,40% > PING CRITICAL - Packet loss = 50%, RTA = 2.50 > ms|rta=2.498000ms;2000.000000;3000.000000;0.000000 pl=50%;30;40;0 > > > > > If I am sending 1 packet, how is it possible to receive 50% packet loss. > Please advise on this. Thanks > > > > > -- > Cordially, > Shadhin Rahman > -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfnetmail at nurfuerspam.de Wed Aug 19 19:02:00 2009 From: sfnetmail at nurfuerspam.de (Olli Hauer) Date: Wed, 19 Aug 2009 19:02:00 +0200 Subject: [Nagiosplug-devel] check_ping plugin is not processing the -p option properly In-Reply-To: <6db4a4200908190935p467558bmfd285a8c5b7727be@mail.gmail.com> References: <6db4a4200908190857h7e6fd126s877262d7ac4986fc@mail.gmail.com> <6db4a4200908190935p467558bmfd285a8c5b7727be@mail.gmail.com> Message-ID: <20090819170200.25580@gmx.net> > I did some troubleshooting and found the following. > > -t option controls the actual -w option for /bin/ping > > if you add -t option in check_ping plugin then it add the -w option in > /bin/ping command. If we don't put -t option then it automatically adds > -w > option with default 10 value > > > so if we do '/bin/ping -n -U -w 10 -c 1 host A' the following is the > output > > > PING host A (x.x.x.x) 56(84) bytes of data. > 64 bytes from 128.59.60.22: icmp_seq=4 ttl=59 time=2.95 ms > > --- unixrack5-ups1.cc.columbia.edu ping statistics --- > 4 packets transmitted, 1 received, 75% packet loss, time 3002ms > rtt min/avg/max/mdev = 2.952/2.952/2.952/0.000 ms > > > however if you do '/bin/ping -n -U -c 1 host A' we get the following > output > > PING host A (x.x.x.x) 56(84) bytes of data. > > --- unixrack5-ups1.cc.columbia.edu ping statistics --- > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > > > Would it be possible not to add the -w option by default. Please advise > on > this. Thanks > > > P. S - I am running rhel 5 with kernel version 2.6.18-128.2.1.el5 > > > > > > > On Wed, Aug 19, 2009 at 11:57 AM, shadih rahman > wrote: > > > All, > > I have noticed that check_ping plugin is not processing the -p > option > > properly. > > > > I have the following command definition > > > > define command{ > > command_name check-host-alive > > command_line $USER1$/check_ping -H $HOSTADDRESS$ t 45 -4 -w > > 3000.0,100% -c 3000.0,100% -p 1 > > } > > > > > > ./check_ping -H Hos A -p 1 -t 45 -4 -w 2000.0,30% -c 3000.0,40% > > PING CRITICAL - Packet loss = 50%, RTA = 2.50 > > ms|rta=2.498000ms;2000.000000;3000.000000;0.000000 pl=50%;30;40;0 > > > > > > > > > > If I am sending 1 packet, how is it possible to receive 50% packet loss. > > Please advise on this. Thanks > > > > Take a look into check_icmp. I think after swapping you don't look back -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser From kuhlmeier at riege.com Wed Aug 26 13:38:26 2009 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Wed, 26 Aug 2009 13:38:26 +0200 Subject: [Nagiosplug-devel] Strange Behaviour with check_procs Message-ID: <4A951EB2.3060505@riege.com> Hello, maybe someone can help with this. Running check_procs seems to overlook two processes from the "condor" package on one of our machines. http://www.eso.org/~qc/dfos/condor.html I hope this is all info you might need. [root at ftam plugins]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.3 (Tikanga) [root at ftam plugins]# uname -a Linux ftam.xxxx 2.6.18-128.4.1.el5xen #1 SMP Thu Jul 23 20:30:27 EDT 2009 i686 i686 i386 GNU/Linux [root at ftam plugins]# ./check_procs --version check_procs v2019 (nagios-plugins 1.4.13) [root at ftam plugins]# ./check_procs -c 1:1 -C condor_collector PROCS CRITICAL: 0 processes with command name 'condor_collector' [root at ftam plugins]# ps aux | grep condor_collector condor 2027 0.0 0.1 9452 3524 ? Ss Aug19 1:13 condor_collector -f root 25907 0.0 0.0 320 124 pts/1 R+ 13:31 0:00 grep condor_collector [root at ftam plugins]# ps aux | grep condor_negotiator condor 2123 0.0 0.1 9148 2720 ? Ss Aug19 1:04 condor_negotiator -f [root at ftam plugins]# ./check_procs -c 1:1 -C condor_negotiator PROCS CRITICAL: 0 processes with command name 'condor_negotiator' And just another example, showing it works in principle: [root at ftam plugins]# ./check_procs -c 1:1 -C condor_schedd PROCS OK: 1 process with command name 'condor_schedd' [root at ftam plugins]# ps aux | grep condor_schedd condor 2124 0.7 0.9 27744 20520 ? Ss Aug19 72:31 condor_schedd -f Thanks for any ideas! Regards, Dennis -- .............................................................. Riege Software International GmbH Fon: +49 (2159) 9148 0 Mollsfeld 10 Fax: +49 (2159) 9148 11 40670 Meerbusch Web: www.riege.com Germany E-Mail: kuhlmeier at riege.com --- --- Handelsregister: Managing Directors: Amtsgericht Neuss HRB-NR 4207 Christian Riege USt-ID-Nr.: DE120585842 Gabriele Riege Johannes Riege .............................................................. YOU CARE FOR FREIGHT, WE CARE FOR YOU -------------- next part -------------- A non-text attachment was scrubbed... Name: kuhlmeier.vcf Type: text/x-vcard Size: 306 bytes Desc: not available URL: From marc at ena.com Wed Aug 26 14:30:15 2009 From: marc at ena.com (Marc Powell) Date: Wed, 26 Aug 2009 07:30:15 -0500 Subject: [Nagiosplug-devel] Strange Behaviour with check_procs In-Reply-To: <4A951EB2.3060505@riege.com> References: <4A951EB2.3060505@riege.com> Message-ID: <544FF8EF-F464-4F8F-B8F5-E611AA01C5EB@ena.com> On Aug 26, 2009, at 6:38 AM, Dennis Kuhlmeier wrote: > Hello, > > maybe someone can help with this. > Running check_procs seems to overlook two processes from the > "condor" package on one of our machines. > http://www.eso.org/~qc/dfos/condor.html > > I hope this is all info you might need > [root at ftam plugins]# ./check_procs -c 1:1 -C condor_collector > PROCS CRITICAL: 0 processes with command name 'condor_collector' > [root at ftam plugins]# ps aux | grep condor_collector > condor 2027 0.0 0.1 9452 3524 ? Ss Aug19 1:13 > condor_collector -f > root 25907 0.0 0.0 320 124 pts/1 R+ 13:31 0:00 > grep condor_collector\ While I don't have you answer, I suspect I might. check_procs is likely using a different ps command and those process names don't show in that output. Try the following and examine the output. check_procs -c 1:1 -C condor_collector -v -v -v -- Marc From kuhlmeier at riege.com Wed Aug 26 14:38:45 2009 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Wed, 26 Aug 2009 14:38:45 +0200 Subject: [Nagiosplug-devel] Strange Behaviour with check_procs In-Reply-To: <544FF8EF-F464-4F8F-B8F5-E611AA01C5EB@ena.com> References: <4A951EB2.3060505@riege.com> <544FF8EF-F464-4F8F-B8F5-E611AA01C5EB@ena.com> Message-ID: <4A952CD5.8050201@riege.com> Marc Powell wrote: > On Aug 26, 2009, at 6:38 AM, Dennis Kuhlmeier wrote: > >> Hello, >> >> maybe someone can help with this. >> Running check_procs seems to overlook two processes from the >> "condor" package on one of our machines. >> http://www.eso.org/~qc/dfos/condor.html >> >> I hope this is all info you might need > >> [root at ftam plugins]# ./check_procs -c 1:1 -C condor_collector >> PROCS CRITICAL: 0 processes with command name 'condor_collector' >> [root at ftam plugins]# ps aux | grep condor_collector >> condor 2027 0.0 0.1 9452 3524 ? Ss Aug19 1:13 >> condor_collector -f >> root 25907 0.0 0.0 320 124 pts/1 R+ 13:31 0:00 >> grep condor_collector\ > > While I don't have you answer, I suspect I might. check_procs is > likely using a different ps command and those process names don't show > in that output. Try the following and examine the output. > > check_procs -c 1:1 -C condor_collector -v -v -v > Thanks, that actually helped. The process name is cut off at 15 letters. Ss 64 2027 2026 9452 3524 0.0 condor_collecto condor_collector -fproc#=0 uid=64 vsz=9452 rss=3524 pid=2027 ppid=2026 pcpu=0.00 stat=Ss etime= prog=condor_collecto args=condor_collector -f Matched: uid=64 vsz=9452 rss=3524 pid=2027 ppid=2026 pcpu=0.00 stat=Ss etime= prog=condor_collecto args=condor_collector -f Found my process, although I am not perfectly happy with that. [root at ftam plugins]# ./check_procs -c 1:1 -C condor_collecto PROCS OK: 1 process with command name 'condor_collecto' Regards, Dennis -- .............................................................. Riege Software International GmbH Fon: +49 (2159) 9148 0 Mollsfeld 10 Fax: +49 (2159) 9148 11 40670 Meerbusch Web: www.riege.com Germany E-Mail: kuhlmeier at riege.com --- --- Handelsregister: Managing Directors: Amtsgericht Neuss HRB-NR 4207 Christian Riege USt-ID-Nr.: DE120585842 Gabriele Riege Johannes Riege .............................................................. YOU CARE FOR FREIGHT, WE CARE FOR YOU -------------- next part -------------- A non-text attachment was scrubbed... Name: kuhlmeier.vcf Type: text/x-vcard Size: 306 bytes Desc: not available URL: From addw at phcomp.co.uk Sat Aug 29 13:12:04 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 12:12:04 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access Message-ID: <20090829111204.GT21433@phcomp.co.uk> In may I submitted a patch to check_procs along with complete documentation, motivation, example config. It was discussed a couple of times, I pushed, some more chat then nothing. People seemed happy with it, but no one did anything ... so I shall put it into the repository myself. See: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2794120&group_id=29880 Please give me a GIT account. Many thanks -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From waja at cyconet.org Sat Aug 29 15:49:14 2009 From: waja at cyconet.org (Jan Wagner) Date: Sat, 29 Aug 2009 15:49:14 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829111204.GT21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> Message-ID: <200908291549.18891.waja@cyconet.org> On Saturday, 29. August 2009, Alain Williams wrote: > Please give me a GIT account. Speaking as user: lol? Regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 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------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From hir3npatel at gmail.com Sat Aug 29 16:46:38 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sat, 29 Aug 2009 16:46:38 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829111204.GT21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> Message-ID: <4A993F4E.6070503@gmail.com> Alain Williams wrote: > In may I submitted a patch to check_procs along with complete documentation, > motivation, example config. > > It was discussed a couple of times, I pushed, some more chat then nothing. > People seemed happy with it, but no one did anything ... so I shall put it > into the repository myself. > > See: > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2794120&group_id=29880 > > Please give me a GIT account. > as far as I recall, there was some hesitance due to the patch causing the check to have a state file, and it's own configuration file (if I remember right). personally I'm wondering if it's not perhaps better to have a separate check to specifically watch for cpu hogging, instead of putting that into check_procs. From addw at phcomp.co.uk Sat Aug 29 17:04:09 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 16:04:09 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A993F4E.6070503@gmail.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> Message-ID: <20090829150409.GW21433@phcomp.co.uk> On Sat, Aug 29, 2009 at 04:46:38PM +0200, Hiren Patel wrote: > Alain Williams wrote: > > In may I submitted a patch to check_procs along with complete documentation, > > motivation, example config. > > > > It was discussed a couple of times, I pushed, some more chat then nothing. > > People seemed happy with it, but no one did anything ... so I shall put it > > into the repository myself. > > > > See: > > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2794120&group_id=29880 > > > > Please give me a GIT account. > > > > as far as I recall, there was some hesitance due to the patch causing > the check to have a state file, and it's own configuration file (if I > remember right). I does not have a configuration file. Yes: it does have a state file -- to record cpu hogging processes at the time that it runs, so it can check if the same ones are running X minutes later. I cannot see how else to do it - the information needs to be stored somewhere. No one suggested anything else. It could do something like checking for environemnt NAGIOS_STATE_DIR and storing there -- overriding it's built in one. But that means a change to nagios. > personally I'm wondering if it's not perhaps better to have a separate > check to specifically watch for cpu hogging, instead of putting that > into check_procs. It will also do detection of a process having more than the specified amount of * virtual memory size * resident set memory size * percentage CPU * time elapsed in seconds This is all stuff monitored by check_procs already. All that I have done is to allow detection of processes that exceed such a limit for more than a certain time -- ie ignore short lived events. You guys are hard to work with! -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From hir3npatel at gmail.com Sat Aug 29 17:47:20 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sat, 29 Aug 2009 17:47:20 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829150409.GW21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> Message-ID: <4A994D88.3070303@gmail.com> Alain Williams wrote: > I does not have a configuration file. > > Yes: it does have a state file -- to record cpu hogging processes at the > time that it runs, so it can check if the same ones are running X minutes later. > > I cannot see how else to do it - the information needs to be stored somewhere. > No one suggested anything else. > I also don't know any other good way to keep the information, either than a state file. > It could do something like checking for environemnt NAGIOS_STATE_DIR > and storing there -- overriding it's built in one. But that means a change > to nagios. > >> personally I'm wondering if it's not perhaps better to have a separate >> check to specifically watch for cpu hogging, instead of putting that >> into check_procs. > > It will also do detection of a process having more than the specified amount of > > * virtual memory size > * resident set memory size > * percentage CPU > * time elapsed in seconds > > This is all stuff monitored by check_procs already. All that I have done is > to allow detection of processes that exceed such a limit for more than a > certain time -- ie ignore short lived events. > > You guys are hard to work with! > this doesn't break compatibility with previous versions right? I'm not a core member with access, I'm commenting from a contributor perspective. if this doesn't break compatibility, make your plea to the core members, lets see what they have to say. it's highly unlikely to get git commit access without being a regular contributor for a while I think. the other thing is that the mantis bug/feature list is possibly considered a formal place for open bugs/features pending testing/approval, in my experience the list is know to lag in testing/committing bugs/features. From perldork at webwizarddesign.com Sat Aug 29 17:59:42 2009 From: perldork at webwizarddesign.com (Max) Date: Sat, 29 Aug 2009 11:59:42 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A994D88.3070303@gmail.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> Message-ID: On Sat, Aug 29, 2009 at 11:47 AM, Hiren Patel wrote: > Alain Williams wrote: >> I cannot see how else to do it - the information needs to be stored somewhere. >> No one suggested anything else. >> > > I also don't know any other good way to keep the information, either > than a state file. Sorry I didn't see this whole plugin thread when it first came out; we use Memcache for this purpose (for SNMP delta processing). Yes, external dependency, but performance is excellent and you can move the cache off-host if you need to :). - Max From pitchfork at ederdrom.de Sat Aug 29 18:03:41 2009 From: pitchfork at ederdrom.de (Joerg Linge) Date: Sat, 29 Aug 2009 18:03:41 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A994D88.3070303@gmail.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> Message-ID: <4A99515D.4040801@ederdrom.de> Hiren Patel schrieb: > Alain Williams wrote: >> I does not have a configuration file. >> >> Yes: it does have a state file -- to record cpu hogging processes at the >> time that it runs, so it can check if the same ones are running X minutes later. >> >> I cannot see how else to do it - the information needs to be stored somewhere. >> No one suggested anything else. >> > > I also don't know any other good way to keep the information, either > than a state file. Let Nagios push the last perfdata and timestamp back to the plugin next time it will called by using On-Demand Macros. So its possible for the Plugin to parse its own perfdata and compute the delta. Cheers Joerg From holger at CIS.FU-Berlin.DE Sat Aug 29 18:18:07 2009 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sat, 29 Aug 2009 18:18:07 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829111204.GT21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> Message-ID: <20090829161807.GF69749771@Waran.CIS.FU-Berlin.DE> * Alain Williams [2009-08-29 12:12]: > In may I submitted a patch to check_procs along with complete documentation, > motivation, example config. > > It was discussed a couple of times, I pushed, some more chat then nothing. > People seemed happy with it, but no one did anything ... I know (very well) that it can be frustrating when patches don't get accepted, but I'm afraid your impression that everyone "seemed happy with it" is not quite correct. See the previous discussion on this topic: http://thread.gmane.org/gmane.network.nagios.plugins.devel/6577 Both team members who commented on your patch stated that they are unhappy with the fact that your plugin uses a file for holding state information. I tend to agree with them: while I do see that a mechanism for holding state information could be useful for some plugins, I'd prefer a generic solution over home-brewn implementations in individual plugins. Apart from that, Thomas raised the concern that the changes are quite invasive and therefore suggested to outsource the new functionality into a separate plugin. > so I shall put it into the repository myself. Is that a question? > Please give me a GIT account. I'd be more than happy to see new team members who have the motiviation, time, and skills to look into other people's bug reports and to review and test their patches. But asking for Git access in order to be able to push your own stuff before a consensus was reached is quite a different pair of shoes. While I do have Git access, I would not (ab)use it to push any patch of mine without seriously addressing such concerns from Thomas and Matthias. Holger From addw at phcomp.co.uk Sat Aug 29 18:53:44 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 17:53:44 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A994D88.3070303@gmail.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> Message-ID: <20090829165344.GX21433@phcomp.co.uk> On Sat, Aug 29, 2009 at 05:47:20PM +0200, Hiren Patel wrote: > this doesn't break compatibility with previous versions right? No. Unless you give the --state-file option it behaves just as the previous version. > I'm not a core member with access, I'm commenting from a contributor > perspective. if this doesn't break compatibility, make your plea to the > core members, lets see what they have to say. > it's highly unlikely to get git commit access without being a regular > contributor for a while I think. No - I put something else up a couple of years ago, that I'll have another go with at some point. I am not really interested in git access, I just want to get this functionality that, I think will improve nagios, into the plugin ... it has been in use for several months. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From addw at phcomp.co.uk Sat Aug 29 19:11:54 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 18:11:54 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> Message-ID: <20090829171154.GY21433@phcomp.co.uk> OK: now 2 ways of storing the state info. Could you please point me at examples of the 2 techniques below. Can I assume that either would be perfectly acceptable ? On Sat, Aug 29, 2009 at 11:59:42AM -0400, Max wrote: > On Sat, Aug 29, 2009 at 11:47 AM, Hiren Patel wrote: > > Alain Williams wrote: > >> I cannot see how else to do it - the information needs to be stored somewhere. > >> No one suggested anything else. > >> > > > > I also don't know any other good way to keep the information, either > > than a state file. > > Sorry I didn't see this whole plugin thread when it first came out; we > use Memcache for this purpose (for SNMP delta processing). Yes, > external dependency, but performance is excellent and you can move the > cache off-host if you need to :). This does seem much more complicated than just giving a file name, more difficult for an end user to set up. It is also RAM kept permanently in use, whereas with a file - it is opened once every 5 minutes. Why do you consider this superior to using a file ? After all nagios itself uses a status.dat file to store state info. I don't understand. On Sat, Aug 29, 2009 at 06:03:41PM +0200, Joerg Linge wrote: > Hiren Patel schrieb: > > Alain Williams wrote: > >> I does not have a configuration file. > >> > >> Yes: it does have a state file -- to record cpu hogging processes at the > >> time that it runs, so it can check if the same ones are running X minutes later. > >> > >> I cannot see how else to do it - the information needs to be stored somewhere. > >> No one suggested anything else. > >> > > > > I also don't know any other good way to keep the information, either > > than a state file. > > Let Nagios push the last perfdata and timestamp back to the plugin next time it will called by using On-Demand Macros. > > So its possible for the Plugin to parse its own perfdata and compute the delta. I can't see that.... -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From cmr at financial.com Sat Aug 29 19:31:42 2009 From: cmr at financial.com (Christoph Maser) Date: Sat, 29 Aug 2009 19:31:42 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829171154.GY21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> Message-ID: <1251567102.4051.2.camel@l3f8946.financial.com> Am Samstag, den 29.08.2009, 19:11 +0200 schrieb Alain Williams: > > > > Let Nagios push the last perfdata and timestamp back to the plugin next time it will called by using On-Demand Macros. > > > > So its possible for the Plugin to parse its own perfdata and compute the delta. > > I can't see that.... > Why not that is a quite common way to do it and works pretty well. financial.com AG Munich head office/Hauptsitz M?nchen: Maria-Probst-Str. 19 | 80939 M?nchen | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich ? HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553 From addw at phcomp.co.uk Sat Aug 29 19:59:09 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 18:59:09 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <1251567102.4051.2.camel@l3f8946.financial.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> <1251567102.4051.2.camel@l3f8946.financial.com> Message-ID: <20090829175909.GZ21433@phcomp.co.uk> On Sat, Aug 29, 2009 at 07:31:42PM +0200, Christoph Maser wrote: > Am Samstag, den 29.08.2009, 19:11 +0200 schrieb Alain Williams: > > > > > > > Let Nagios push the last perfdata and timestamp back to the plugin next time it will called by using On-Demand Macros. > > > > > > So its possible for the Plugin to parse its own perfdata and compute the delta. > > > > I can't see that.... > > > > Why not that is a quite common way to do it and works pretty well. If it is common you should be eable to easily point me to a few examples. I haven't seen any -- but then I don't know what I am looking for. Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From perldork at webwizarddesign.com Sat Aug 29 20:00:59 2009 From: perldork at webwizarddesign.com (Max) Date: Sat, 29 Aug 2009 14:00:59 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829171154.GY21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> Message-ID: On Sat, Aug 29, 2009 at 1:11 PM, Alain Williams wrote: >> Sorry I didn't see this whole plugin thread when it first came out; we >> use Memcache for this purpose (for SNMP delta processing). ?Yes, >> external dependency, but performance is excellent and you can move the >> cache off-host if you need to :). > > This does seem much more complicated than just giving a file name, more difficult > for an end user to set up. It is also RAM kept permanently in use, whereas > with a file - it is opened once every 5 minutes. I am not arguing it is easier or better. I only brought it up as a way to keep state for plugins in general :) as you said no one had responded with alternate ideas. Since check_procs is typically run on a remote host via NRPE or ssh, yes, I can see that having memcache on every managed client would not be a smart idea and I would not do that myself, memcache is great for centralized plugins running from the context of the Nagios poller. > Why do you consider this superior to using a file ? After all nagios itself > uses a status.dat file to store state info. > I don't understand. We find memcache scales very well for plugins run from the central Nagios poller; in our experience we have found RAM-based data stores, either through a memory-based cache like memcache or RAM disks, perform the best for us. If I were using your plugin and it required a state file and I was running it through NRPE I would certainly place the state file on a RAM disk on each monitored host to get the persistence and the best performance from it. - Max From hir3npatel at gmail.com Sat Aug 29 20:26:43 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sat, 29 Aug 2009 20:26:43 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829171154.GY21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> Message-ID: <4A9972E3.8090305@gmail.com> Alain Williams wrote: > OK: now 2 ways of storing the state info. > > Could you please point me at examples of the 2 techniques below. > > Can I assume that either would be perfectly acceptable ? > do not assume that any of these are acceptable until the core members give you word that a certain methods would be considered for inclusion. the comments otherwise made here could be from contributors and may not be accepted for inclusion in the official plugin. as far as I'm aware, non of the supported official plugins keep state in any way, I'm guessing this might be the intention. some of the plugins in contrib like log file monitoring etc, do keep state as they need to, and from what I've seen, do so in files. I've seen that the plugins tarball has a contribs directory with contrib modules, which perhaps aren't official, but are distributed, maybe your chances of getting this plugin into contrib would be better, I'm not sure. > On Sat, Aug 29, 2009 at 11:59:42AM -0400, Max wrote: >> On Sat, Aug 29, 2009 at 11:47 AM, Hiren Patel wrote: >>> Alain Williams wrote: >>>> I cannot see how else to do it - the information needs to be stored somewhere. >>>> No one suggested anything else. >>>> >>> I also don't know any other good way to keep the information, either >>> than a state file. >> Sorry I didn't see this whole plugin thread when it first came out; we >> use Memcache for this purpose (for SNMP delta processing). Yes, >> external dependency, but performance is excellent and you can move the >> cache off-host if you need to :). > From addw at phcomp.co.uk Sat Aug 29 20:31:41 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 19:31:41 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> Message-ID: <20090829183141.GA21433@phcomp.co.uk> On Sat, Aug 29, 2009 at 02:00:59PM -0400, Max wrote: > I am not arguing it is easier or better. I only brought it up as a > way to keep state for plugins in general :) as you said no one had > responded with alternate ideas. OK -- I understand > Since check_procs is typically run on a remote host via NRPE or ssh, > yes, I can see that having memcache on every managed client would not > be a smart idea and I would not do that myself, memcache is great for > centralized plugins running from the context of the Nagios poller. Memcache is great for something that has high use, eg data that web server scripts need. check_procs is going to be run about once every 5 minutes on a machine, hardly something of critical speed importance. > We find memcache scales very well for plugins run from the central > Nagios poller; in our experience we have found RAM-based data stores, > either through a memory-based cache like memcache or RAM disks, > perform the best for us. How many machines are you talking about -- that you have in your cluster ? > If I were using your plugin and it required a state file and I was > running it through NRPE I would certainly place the state file on a > RAM disk on each monitored host to get the persistence and the best > performance from it. I would not use precious RAM for something that is used every 5 minutes or so and for which a little extra delay will hardly be noticed. I would rather let my operating system decide how to use the RAM: if the machine is lightly loaded then a disk file is likely to remain in cache; if the machine is heavily loaded then the cache will be used by some other file/data/... -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From addw at phcomp.co.uk Sat Aug 29 20:33:47 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Sat, 29 Aug 2009 19:33:47 +0100 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A9972E3.8090305@gmail.com> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> <4A9972E3.8090305@gmail.com> Message-ID: <20090829183347.GB21433@phcomp.co.uk> On Sat, Aug 29, 2009 at 08:26:43PM +0200, Hiren Patel wrote: > Alain Williams wrote: > > OK: now 2 ways of storing the state info. > > > > Could you please point me at examples of the 2 techniques below. > > > > Can I assume that either would be perfectly acceptable ? > > > > do not assume that any of these are acceptable until the core members > give you word that a certain methods would be considered for inclusion. Would a core member like to comment ? - please. > the comments otherwise made here could be from contributors and may not > be accepted for inclusion in the official plugin. > as far as I'm aware, non of the supported official plugins keep state in > any way, I'm guessing this might be the intention. > some of the plugins in contrib like log file monitoring etc, do keep > state as they need to, and from what I've seen, do so in files. > I've seen that the plugins tarball has a contribs directory with contrib > modules, which perhaps aren't official, but are distributed, maybe your > chances of getting this plugin into contrib would be better, I'm not sure. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From perldork at webwizarddesign.com Sat Aug 29 20:44:44 2009 From: perldork at webwizarddesign.com (Max) Date: Sat, 29 Aug 2009 14:44:44 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829183141.GA21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A994D88.3070303@gmail.com> <20090829171154.GY21433@phcomp.co.uk> <20090829183141.GA21433@phcomp.co.uk> Message-ID: On Sat, Aug 29, 2009 at 2:31 PM, Alain Williams wrote: > > How many machines are you talking about -- that you have in your cluster ? We have one poller, but we are currently at 8500+ checks every 5 minutes, at least 900-1000 of those use the delta processing we have in place .. having everything in RAM made a noticable difference for us. - Max From waja at cyconet.org Sat Aug 29 22:23:51 2009 From: waja at cyconet.org (Jan Wagner) Date: Sat, 29 Aug 2009 22:23:51 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829183347.GB21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A9972E3.8090305@gmail.com> <20090829183347.GB21433@phcomp.co.uk> Message-ID: <200908292223.56627.waja@cyconet.org> On Saturday, 29. August 2009, Alain Williams wrote: > On Sat, Aug 29, 2009 at 08:26:43PM +0200, Hiren Patel wrote: > > do not assume that any of these are acceptable until the core members > > give you word that a certain methods would be considered for inclusion. > > Would a core member like to comment ? - please. What about Message-ID: <20090829161807.GF69749771 at Waran.CIS.FU-Berlin.DE>? With kind regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 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------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From noreply at sourceforge.net Sun Aug 30 14:00:09 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Aug 2009 12:00:09 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2812592 ] check_linux_raid returns UNKNOWN for md10 and above Message-ID: Bugs item #2812592, was opened at 2009-06-26 08:53 Message generated for change (Comment added) made by dragoslav You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2812592&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: Release (specify) Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_linux_raid returns UNKNOWN for md10 and above Initial Comment: The following Bugreport we got against our debian package (1.4.12): check_linux_raid malfunctions if system has software RAID devices with two or more digits. For example, for system having /dev/md10, /dev/md11 etc, the plugin returns 'UNKNOWN' in automatic mode (if RAID devices are manually specified it works). Also, if system has both one-digit, and two-digit RAID devices, the two-digit devices are silently ignored in checks, which is even more problematic. Problem is that plugin checks only for 'md[0-9]' devices in /proc/mdstat. Trivial patch which fixes that by looking for 'md[0-9]+' instead is attached. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534604 Thanks and kind regards, Jan. ---------------------------------------------------------------------- Comment By: Stefan Mayr (dragoslav) Date: 2009-08-30 14:00 Message: The same issue has been mentioned in german thread at the Nagios portal: http://www.nagios-portal.org/wbb/index.php?page=Thread&threadID=15773 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2812592&group_id=29880 From dermoth at aei.ca Sun Aug 30 22:36:21 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 30 Aug 2009 16:36:21 -0400 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <20090829150409.GW21433@phcomp.co.uk> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> Message-ID: <4A9AE2C5.70106@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/08/09 11:04 AM, Alain Williams wrote: > On Sat, Aug 29, 2009 at 04:46:38PM +0200, Hiren Patel wrote: >> as far as I recall, there was some hesitance due to the patch causing >> the check to have a state file, and it's own configuration file (if I >> remember right). > > I does not have a configuration file. > > Yes: it does have a state file -- to record cpu hogging processes at the > time that it runs, so it can check if the same ones are running X minutes later. > > I cannot see how else to do it - the information needs to be stored somewhere. > No one suggested anything else. You can use the performance data as I'm implementing in check_snmp... I wrote functions to get data out of it. Unfortunately my server with own branch mirror is down right now - I'll create a fork on repo.or.cz later and push there. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKmuLF6dZ+Kt5BchYRAn3XAJ9Ijy/lCAp0maXPJggb6p0W5cfclQCfd36C JfclTB+NJeUAJ5ke7RA1yJQ= =iBbz -----END PGP SIGNATURE----- From holger at CIS.FU-Berlin.DE Mon Aug 31 01:18:54 2009 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Mon, 31 Aug 2009 01:18:54 +0200 Subject: [Nagiosplug-devel] Please can I have GIT access In-Reply-To: <4A9AE2C5.70106@aei.ca> References: <20090829111204.GT21433@phcomp.co.uk> <4A993F4E.6070503@gmail.com> <20090829150409.GW21433@phcomp.co.uk> <4A9AE2C5.70106@aei.ca> Message-ID: <20090830231854.GG69749771@Waran.CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2009-08-30 16:36]: > On 29/08/09 11:04 AM, Alain Williams wrote: > > I cannot see how else to do it - the information needs to be stored somewhere. > > No one suggested anything else. > > You can use the performance data as I'm implementing in check_snmp... I > wrote functions to get data out of it. To be honest, I don't really like abusing the performance data string (or any other solution which involves Nagios) all that much, either. For example, this won't work without additional hacks if the plugin is executed as a passive check, or if it's used with a monitoring software other than Nagios (unless that software makes the performance string of the previous check available, too). Personally, I'd actually be fine with holding state in files, I'd just prefer abstracting that away via some np_{read,write}_state() functions just in case other plugins need such functionality in the future, too. This would make sure that all such plugins in our repository use the same mechanism (which makes things clear for the user; e.g., deleting a single file or directory would clear all state), and the storage backend could be changed (or even be made configurable) in the future without touching the plugins. Just my 2 ?, Holger