From noreply at sourceforge.net Fri Sep 2 12:13:53 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Sep 2011 12:13:53 +0200 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 svencb 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: Sven Schoradt (svencb) Date: 2011-09-02 12:13 Message: Hello, I got the same problem with a new webserver /usr/lib/nagios/plugins/check_http_old -H www.juleica-antrag.de --ssl -vvv GET / HTTP/1.1 User-Agent: check_http/v1.4.15 (nagios-plugins 1.4.15) Connection: close Host: www.juleica-antrag.de HTTP CRITICAL - Error on receive with the version from the debian package 1.4.15 and also with a fresh compile from git, so I debug it a litle bit and find out that SSL_read returns in our case SSL_ERROR_WANT_READ. Following the SSL_get_error manpage I add further reading and it seems to work. I add a small patch with my changes. I hope you can fix the problem in further versions. Sven ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-10-18 22:40 Message: Hi Steffen, could please let us know, against which device/Webserver you test the plugin? Noone of us is able to reproduce the problem. Thanks, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 16:36 Message: Steffen, please try tp reproduce this from the latest snapshot (you don't have to install it, just run check_http off the plugins/ directory). If you can reproduce it, then try applying the attached patch. If it still fails with the attached patch applied then please send debug output of check_http (add -vvv to the command line). The snapshots can be found here: http://nagiosplug.sourceforge.net/snapshot/ It turns out the version you are using is way past 1.4.13 and there are a few changes in the current tree that could change how check_http interacts with web servers. Thanks ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-11 15:20 Message: From IRC: dermoth: stable: 0.9.8g-15+lenny3 and on unstable actually 0.9.8k-3 dermoth: you can also have a look at http://packages.debian.org/openssl ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-08-05 20:56 Message: > Obviously. As far as I can see it seems like a problem with the specific > OpenSSL package in debian, so unless you can come up with an openssl > version to test with I can't do much in term of debugging (I check many > SSL-enabled sites, and also have multiple succeeding tests on my tinderbox > and dev workstation). I rolled out the package recompiled against stable on our monitoring infrastructure. So fas we don't have any problems with our SSL-enabled sites there. But just out of kind, what maybe all apache webserver, which was stated as still working by the initial bug report. So we need to be supplied with a public available test sites, where we can reproduce the problem (by using the debian package from sid and maybe the lenny backported one and the one from stable). Steffen: please supply such a ssl-site if possible. > > > You shouldn't expect high stability out of debian Sid. > > > > Why not? Packages uploaded to sid (and migrating later to testing) are > > considered to be released in the next stable release. > > Then that is strange that Nagios-plugins has been updated to a git HEAD. > What makes matter worse is that uses often aren't well aware of development > process and in this case is was reported against 1.4.13. When I looked at > differences between 1.4.12 and 1.4.13 I was obviously missing a lot of > patches. Reasons was stated for example at http://blog.waja.info/2009/07/07/nagios-plugins-1413git200906171200-1-uploaded/ > > From Debian point of view, this is absolutely necessary to reproduce this > > bug (and maybe fixing, if needed). > > Could you at least check that latest sid is not affected on random SSL > sites. If it's only specific to certain setups and/or web servers then at > least it's not as critical. I've tested the following server on stable and sid: Server: Microsoft-IIS/7.0 Server: lighttpd/1.4.19 Server: nginx/0.7.60 Server: Apache No problem so far. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 15:15 Message: > > Well, then first of all you should have reported this against debian's > bug > > database (if you already did please link the bug #). It could be a > > debian-specific bug. > > Maybe and maybe not. :) Obviously. As far as I can see it seems like a problem with the specific OpenSSL package in debian, so unless you can come up with an openssl version to test with I can't do much in term of debugging (I check many SSL-enabled sites, and also have multiple succeeding tests on my tinderbox and dev workstation). > > It also looks like your package is based on a development version with > > known bugs. > > You was discussing to release months ago. So did guess that it would be > released "soon" (and is some kind of stable). A bunch of things went in since then... And we could have sent a release with the last blocker bug before I discovered it (check_snmp regression) but I'm sure it would have been discovered very quickly and we'd have to make a 2nd release to fix it. > > You shouldn't expect high stability out of debian Sid. > > Why not? Packages uploaded to sid (and migrating later to testing) are > considered to be released in the next stable release. Then that is strange that Nagios-plugins has been updated to a git HEAD. What makes matter worse is that uses often aren't well aware of development process and in this case is was reported against 1.4.13. When I looked at differences between 1.4.12 and 1.4.13 I was obviously missing a lot of patches. > > Finally it would be *very* helpful if you can reproduce this on an > > external http web site so I can test as well. > > From Debian point of view, this is absolutely necessary to reproduce this > bug (and maybe fixing, if needed). Could you at least check that latest sid is not affected on random SSL sites. If it's only specific to certain setups and/or web servers then at least it's not as critical. Thanks ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-08-05 11:31 Message: > Well, then first of all you should have reported this against debian's bug > database (if you already did please link the bug #). It could be a > debian-specific bug. Maybe and maybe not. :) > It also looks like your package is based on a development version with > known bugs. You was discussing to release months ago. So did guess that it would be released "soon" (and is some kind of stable). > You shouldn't expect high stability out of debian Sid. Why not? Packages uploaded to sid (and migrating later to testing) are considered to be released in the next stable release. > Finally it would be *very* helpful if you can reproduce this on an > external http web site so I can test as well. From Debian point of view, this is absolutely necessary to reproduce this bug (and maybe fixing, if needed). With kind regards, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-08-05 06:42 Message: Well, then first of all you should have reported this against debian's bug database (if you already did please link the bug #). It could be a debian-specific bug. It also looks like your package is based on a development version with known bugs. You shouldn't expect high stability out of debian Sid. Finally it would be *very* helpful if you can reproduce this on an external http web site so I can test as well. Thanks ---------------------------------------------------------------------- Comment By: Steffen (steffencl) Date: 2009-07-27 20:58 Message: We use Debian "sid". OpenSSL was before the update and still is verion 0.9.8k 25 Mar 2009 According to Debian's update log the following has changed: [UPGRADE] nagios-nrpe-plugin 2.12-3 -> 2.12-3.1 [UPGRADE] nagios-plugins 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios-plugins-basic 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios-plugins-standard 1.4.12-5 -> 1.4.13+git200906171200-1 [UPGRADE] nagios3 3.0.6-4 -> 3.0.6-5 [UPGRADE] nagios3-common 3.0.6-4 -> 3.0.6-5 [UPGRADE] nagios3-doc 3.0.6-4 -> 3.0.6-5 Since we use packages of provided by or for the used distribution, we do not compile but use the packagetmanager of the distribution (here Debian sid). - Steffen ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-07-25 03:51 Message: Hi, and thanks for your report. I checked the change logs between these two release and there's absolutely no difference between 1.4.12 and 1.4.13 that could explain this (the only change that affects what check_http sends is that is doesn't send the defaut port anymore on the Host: line - RFC 2616). My best guess would be a change in your OpenSSL installation. Can you try recompiling 1.4.12 from scratch (don't re-use your previous compile tree)? It would also be nice to know: - Your configure parameters - Your OpenSSL version - An externally accessible server to test with, if possible. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2826570&group_id=29880 From noreply at sourceforge.net Wed Sep 7 12:26:42 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2011 12:26:42 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2786808 ] check_http asks for HTTP/1.1, but doesn't understand chunked Message-ID: Bugs item #2786808, was opened at 2009-05-04 21:19 Message generated for change (Comment added) made by tothandor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&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: Parsing problem Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ferenc W?gner (wferi) Assigned to: Holger Weiss (hweiss) Summary: check_http asks for HTTP/1.1, but doesn't understand chunked Initial Comment: Fixing 2638765 uncovered this bug (actually, most HTTP servers respect Host: headers in HTTP/1.0 requests, even though it isn't part of the spec). Anyway: if a client sends a HTTP/1.1 request, it must be able to handle the incoming HTTP/1.1 reply. Which includes coping with a chunked one. This exact same command worked with check_http version 1.4.5 (and still does so with -H replaced by -I, but that isn't the point). $ /usr/lib/nagios/plugins/check_http -v -H idp.niif.hu -u /idp/profile/Status --ssl -r "^ok$" GET /idp/profile/Status HTTP/1.1 Host: idp.niif.hu:443 User-Agent: check_http/v1991 (nagios-plugins 1.4.12) Connection: close https://idp.niif.hu:443/idp/profile/Status is 141 characters STATUS: HTTP/1.1 200 OK **** HEADER **** Date: Mon, 04 May 2009 19:12:13 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/plain **** CONTENT **** 2 ok 0 HTTP CRITICAL - pattern not found|time=0.067933s;;;0.000000 size=141B;;;0 ---------------------------------------------------------------------- Comment By: Andor (tothandor) Date: 2011-09-07 12:26 Message: +1 Present in 1.4.15. A possible workaround is to use -k "Host: example.com" ---------------------------------------------------------------------- Comment By: Chris Hiestand (chrishiestand) Date: 2010-11-24 07:23 Message: +1 here too. I spent my whole evening figuring out why a nagios check was failing on a page that was fully functional, and had the sought-for regular expression. If the regular expression happens to be broken up by a chunk, the check fails. ---------------------------------------------------------------------- Comment By: Lamont Granquist (lamontgranquist) Date: 2010-08-01 05:40 Message: +1, I just ran into this bug. I started blaming our software devs for not marshalling their data correctly into XML and garbling it on the wire before I realized that the problem was that check_http didn't understand chunked encoding... ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2009-05-19 21:04 Message: I'll look into teaching check_http how to cope with chunked replies. Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&group_id=2988 From noreply at sourceforge.net Wed Sep 7 14:31:04 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Sep 2011 14:31:04 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3405551 ] check_ircd does not work with IPv6 Message-ID: Bugs item #3405551, was opened at 2011-09-07 14:31 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=3405551&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ircd does not work with IPv6 Initial Comment: The following Bugreport we got against our debian package: The check_ircd script uses low-level socket library calls and as such cannot check IPv6 IRC servers. It would probably make sense to rewrite this to use an IRC library. Net::IRC is deprecated these daays (#608583) and claims that Bot::BasicBot or POE::Component::IRC is the best way forward, but both of those may be a little heavyweight, I suspect. may contain a working patch to add IPv6 support to the existing code, although needing to pass the -6 flag isn't ideal. Cheers, Dominic. You can track the bugreport via http://bugs.debian.org/638310 Many thanks, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3405551&group_id=29880 From casper at meteor.dp.ua Fri Sep 9 10:03:01 2011 From: casper at meteor.dp.ua (=?koi8-r?Q?=F0=CF=CB=CF=D4=C9=CC=C5=CE=CB=CF_?= =?koi8-r?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE_?= =?koi8-r?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2=CF=D7=C9?= =?koi8-r?Q?=DE?=) Date: Fri, 09 Sep 2011 11:03:01 +0300 Subject: [Nagiosplug-devel] Patch for check_procs Message-ID: <1315555381.3147.20.camel@casper-pbank.local> Hi, I've made a patch for check_procs (check_procs_perf) to add those features: - Total warning and total critical thresholds ranges (options -x, -y) applied to summary metric across all processes that matched filter - Extended status information for failed processes: pid, metric and value (not applicable for PROC metric) - Added Global status (max of total and per-process) as well as total status and usual per-process status - Performance data dependant on metric requested: PROC, VSZ, RSS, CPU -v as required to output performance data total warning and total critical are used as thresholds in performance data Please tell what you think on this. Maybe consider including it as separate test check_procs_perf -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.15-check_procs_perf.tar.gz Type: application/x-compressed-tar Size: 9835 bytes Desc: not available URL: From casper at meteor.dp.ua Fri Sep 9 10:03:43 2011 From: casper at meteor.dp.ua (=?koi8-r?Q?=F0=CF=CB=CF=D4=C9=CC=C5=CE=CB=CF_?= =?koi8-r?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE_?= =?koi8-r?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2=CF=D7=C9?= =?koi8-r?Q?=DE?=) Date: Fri, 09 Sep 2011 11:03:43 +0300 Subject: [Nagiosplug-devel] Patch for check_procs Message-ID: <1315555423.3147.22.camel@casper-pbank.local> Hi, I've made a patch for check_procs (check_procs_perf) to add those features: - Total warning and total critical thresholds ranges (options -x, -y) applied to summary metric across all processes that matched filter - Extended status information for failed processes: pid, metric and value (not applicable for PROC metric) - Added Global status (max of total and per-process) as well as total status and usual per-process status - Performance data dependant on metric requested: PROC, VSZ, RSS, CPU -v as required to output performance data total warning and total critical are used as thresholds in performance data Please tell what you think on this. Maybe consider including it as -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.15-check_procs_perf.tar.gz Type: application/x-compressed-tar Size: 9835 bytes Desc: not available URL: From noreply at sourceforge.net Tue Sep 13 15:20:53 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2011 16:20:53 +0300 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3408602 ] MySQL ignore authentication failure command line option Message-ID: Patches item #3408602, was opened at 2011-09-13 16:20 Message generated for change (Tracker Item Submitted) made by juliuskriukas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&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: Julius Kriukas (juliuskriukas) Assigned to: Nobody/Anonymous (nobody) Summary: MySQL ignore authentication failure command line option Initial Comment: This patch allows checking if MySQL server is running without providing valid username and password. Similar to check_ssh plugin it returns MySQL server version string and protocol number. Example: check_mysql -n -H aaa.bbb.ccc.ddd MySQL OK - Version: 5.0.51a-24+lenny5 (protocol 10) This is useful for monitoring servers where one does not have administrator privileges or does not want to grant any privileges for the monitoring station. To enable this functionality new option --ignore-auth (-n) is added to check_mysql plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&group_id=29880 From noreply at sourceforge.net Tue Sep 13 15:26:19 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2011 16:26:19 +0300 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3408602 ] check_mysqlignore authentication failure Message-ID: Patches item #3408602, was opened at 2011-09-13 16:20 Message generated for change (Settings changed) made by juliuskriukas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&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: Julius Kriukas (juliuskriukas) Assigned to: Nobody/Anonymous (nobody) >Summary: check_mysqlignore authentication failure Initial Comment: This patch allows checking if MySQL server is running without providing valid username and password. Similar to check_ssh plugin it returns MySQL server version string and protocol number. Example: check_mysql -n -H aaa.bbb.ccc.ddd MySQL OK - Version: 5.0.51a-24+lenny5 (protocol 10) This is useful for monitoring servers where one does not have administrator privileges or does not want to grant any privileges for the monitoring station. To enable this functionality new option --ignore-auth (-n) is added to check_mysql plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&group_id=29880 From noreply at sourceforge.net Tue Sep 13 15:26:42 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Sep 2011 16:26:42 +0300 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3408602 ] check_mysql: ignore authentication failure Message-ID: Patches item #3408602, was opened at 2011-09-13 16:20 Message generated for change (Settings changed) made by juliuskriukas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&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: Julius Kriukas (juliuskriukas) Assigned to: Nobody/Anonymous (nobody) >Summary: check_mysql: ignore authentication failure Initial Comment: This patch allows checking if MySQL server is running without providing valid username and password. Similar to check_ssh plugin it returns MySQL server version string and protocol number. Example: check_mysql -n -H aaa.bbb.ccc.ddd MySQL OK - Version: 5.0.51a-24+lenny5 (protocol 10) This is useful for monitoring servers where one does not have administrator privileges or does not want to grant any privileges for the monitoring station. To enable this functionality new option --ignore-auth (-n) is added to check_mysql plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3408602&group_id=29880 From honia2002 at hotmail.com Thu Sep 22 16:23:53 2011 From: honia2002 at hotmail.com (Honia A) Date: Thu, 22 Sep 2011 10:23:53 -0400 Subject: [Nagiosplug-devel] Nagios to poll Cisco switch via SNMP v3? Message-ID: Hi all, I have a Cisco 2960 which is configured for SNMP. The machine's IP is 10.10.10.3 and can communicate with the Cisco 2960 switch 10.10.10.2 via SNMP. (I tested it with snmpwalk -v 3 -u tom -l authPriv -a sha -A [passwordpassword] -x aes -X passwordpassword 10.10.10.2) And I also modified Nagios's switch.cfg (code below). Nagios is now monitoring the switch. I tried running this command ./check_snmp -H 10.10.10.2 -o "ifOperStatus.1" -U tom -A [passwordpassword] -X passwordpassword -L authPriv -P 3 -a MD5 -c 1050 But looks like it's not working: SNMP problem - No data received from host CMD: /usr/bin/snmpget -t 1 -r 5 -m ALL -v 3 [authpriv] 10.10.10.2:161 ifOperStatus.1 What I would like to do is configure Nagios to poll this switch via SNMP v3. So I understand the check_command part should be changed but am not sure how to do that. Can you please help? Thanks in advance, t ############################################################################### ############################################################################### # # HOST DEFINITIONS # ############################################################################### ############################################################################### # Define the switch that we'll be monitoring define host{ use generic-switch ; Inherit default values from a template host_name linksys-srw224p ; The name we're giving to this switch alias Linksys SRW224P Switch ; A longer name associated with the switch address 192.168.1.253 ; IP address of the switch hostgroups switches ; Host groups this switch is associated with } define host{ use generic-switch host_name core-switch alias Cisco Core Switch address 10.10.10.2 hostgroups switches } ############################################################################### ############################################################################### # # HOST GROUP DEFINITIONS # ############################################################################### ############################################################################### # Create a new hostgroup for switches define hostgroup{ hostgroup_name switches ; The name of the hostgroup alias Network Switches ; Long name of the group } ############################################################################### ############################################################################### # # SERVICE DEFINITIONS # ############################################################################### ############################################################################### # Create a service to PING to switch define service{ use generic-service ; Inherit values from a template host_name linksys-srw224p ; The name of the host the service is associated with service_description PING ; The service description check_command check_ping!200.0,20%!600.0,60% ; The command used to monitor the service normal_check_interval 5 ; Check the service every 5 minutes under normal conditions retry_check_interval 1 ; Re-check the service every minute until its final/hard state is determined } # Monitor uptime via SNMP define service{ use generic-service ; Inherit values from a template host_name linksys-srw224p service_description Uptime check_command check_snmp!-C public -o sysUpTime.0 } # Monitor Port 1 status via SNMP define service{ use generic-service ; Inherit values from a template host_name linksys-srw224p service_description Port 1 Link Status check_command check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB } # Monitor bandwidth via MRTG logs define service{ use generic-service ; Inherit values from a template host_name linksys-srw224p service_description Port 1 Bandwidth Usage check_command check_local_mrtgtraf!/var/lib/mrtg/192.168.1.253_1.log!AVG!1000000,1000000!5000000,5000000!10 } # Service definition to ping the switch using check_ping define service{ use generic-service hostgroup_name switches service_description PING check_command check_ping!200.0,20%!600.0,60% normal_check_interval 5 retry_check_interval 1 } # Service definition to monitor switch uptime using check_snmp define service{ use generic-service hostgroup_name switches service_description Uptime check_command check_snmp!-C public -o sysUpTime.0 } # Monitor status of port number 1 on the Cisco core switch define service{ use generic-service host_name core-switch service_description Port 1 Link Status check_command check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB } # Monitor status of port number 5 on the Cisco core switch define service{ use generic-service host_name core-switch service_description Port 5 Link Status check_command check_snmp!-C public -o ifOperStatus.5 -r 1 -m RFC1213-MIB } # Monitor ports 1 - 6 on the Cisco core switch. define service{ use generic-service host_name core-switch service_description Ports 1-6 Link Status check_command check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB, -o ifOperStatus.2 -r 1 -m RFC1213-MIB, -o ifOperStatus.3 -r 1 -m RFC1213-MIB, -o ifOperStatus.4 -r 1 -m RFC1213-MIB, -o ifOperStatus.5 -r 1 -m RFC1213-MIB, -o ifOperStatus.6 -r 1 -m RFC1213-MIB } -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Sep 28 10:21:35 2011 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Sep 2011 08:21:35 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3414894 ] check_http: add CONNECT method Message-ID: Patches item #3414894, was opened at 2011-09-28 08:21 Message generated for change (Tracker Item Submitted) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3414894&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: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: add CONNECT method Initial Comment: Add 'CONNECT' method to chek+http Patch taken from http://nagios.frank4dd.com/howto/monitor-ssl-websites-through-proxy.htm and reworked slightly for nagios-plugins-1.4.15 The arguments will be check_http_new -I -p -u -S(sl) -j CONNECT -H A suggested test would be check_http_new -I -p -u https://www.verisign.com/ -S -j CONNECT -H www.verisign.com This has been tested by one of our Opsview customers and works as expected Duncs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3414894&group_id=29880