From noreply at sourceforge.net Mon Jun 1 05:15:53 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 03:15:53 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2799281 ] check_pgsql doesn't support -v option Message-ID: Patches item #2799281, was opened at 2009-06-01 12:15 Message generated for change (Tracker Item Submitted) made by kuriyama You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2799281&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jun Kuriyama (kuriyama) Assigned to: Nobody/Anonymous (nobody) Summary: check_pgsql doesn't support -v option Initial Comment: check_pgsql help summary shows "-v" option as verbose output, but this plugin does not include verbose output mode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2799281&group_id=29880 From noreply at sourceforge.net Mon Jun 1 14:15:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 12:15:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2347686 ] check_fping: expose fping timeout option (-t) Message-ID: Patches item #2347686, was opened at 2008-11-26 01:41 Message generated for change (Comment added) made by xtea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2347686&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: Martin Foster (martin_foster) Assigned to: Nobody/Anonymous (nobody) Summary: check_fping: expose fping timeout option (-t) Initial Comment: This patch exposes the fping timeout (-t) option to check_fping. Necessary for checking hosts that are likely to have more than the default of 500msec RTT. Works in the same way as the timeout option for ping/check_ping. Attached patch applies to version 1.4.13 of the plugins, though we've maintained this patch at my site for years. Hopefully useful to the greater community. ---------------------------------------------------------------------- Comment By: Andre Sachs (xtea) Date: 2009-06-01 12:15 Message: +1 ! This really helps for monitoring high latency satellite based links. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2347686&group_id=29880 From noreply at sourceforge.net Mon Jun 1 16:57:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 14:57:33 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2347686 ] check_fping: expose fping timeout option (-t) Message-ID: Patches item #2347686, was opened at 2008-11-26 02:41 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2347686&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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Martin Foster (martin_foster) >Assigned to: Matthias Eble (psychotrahe) Summary: check_fping: expose fping timeout option (-t) Initial Comment: This patch exposes the fping timeout (-t) option to check_fping. Necessary for checking hosts that are likely to have more than the default of 500msec RTT. Works in the same way as the timeout option for ping/check_ping. Attached patch applies to version 1.4.13 of the plugins, though we've maintained this patch at my site for years. Hopefully useful to the greater community. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-06-01 16:57 Message: Hi Martin, I applied the patch to our git repository. However I had to change some things: * use -T instead of -t as -t is usually meant to provide an overall timeout rather than a timeout for individual requests. * If timeout is not specified, check_fpings default wil be used. Rather than specifying a default value in check_fping itself. I also added a -i option to specify the packet interval fping uses (if -n >1) Thanks for the patch Matthias ---------------------------------------------------------------------- Comment By: Andre Sachs (xtea) Date: 2009-06-01 14:15 Message: +1 ! This really helps for monitoring high latency satellite based links. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2347686&group_id=29880 From noreply at sourceforge.net Mon Jun 1 16:59:01 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 14:59:01 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2341696 ] check_fping: expose fping timeout option (-t) Message-ID: Patches item #2341696, was opened at 2008-11-25 06:21 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2341696&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: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: Martin Foster (martin_foster) Assigned to: Nobody/Anonymous (nobody) Summary: check_fping: expose fping timeout option (-t) Initial Comment: This patch exposes the fping timeout (-t) option to check_fping. Necessary for checking hosts that are likely to have more than the default of 500msec RTT. Works in the same way as the timeout option for ping/check_ping. Attached patch applies to version 1.4.13 of the plugins, though we've maintained this patch at my site for years. Hopefully useful to the greater community. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2341696&group_id=29880 From noreply at sourceforge.net Mon Jun 1 22:13:32 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 20:13:32 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2799281 ] check_pgsql doesn't support -v option Message-ID: Patches item #2799281, was opened at 2009-06-01 05:15 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2799281&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: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jun Kuriyama (kuriyama) >Assigned to: Matthias Eble (psychotrahe) Summary: check_pgsql doesn't support -v option Initial Comment: check_pgsql help summary shows "-v" option as verbose output, but this plugin does not include verbose output mode. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-06-01 22:13 Message: Hi, rather than dropping the -v argument, I've added a -v flag and some verbose output to check_pgsql in our repository. Thanks for your report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2799281&group_id=29880 From noreply at sourceforge.net Mon Jun 1 22:49:55 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 20:49:55 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2796624 ] check_icmp wrong output in help Message-ID: Bugs item #2796624, was opened at 2009-05-26 01:13 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2796624&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Matthias Eble (psychotrahe) Summary: check_icmp wrong output in help Initial Comment: The following Bugreport we got against our debian package (1.4.12): At no point are warn.rta and crit.rta handled differently. The default behavior has a .5s timeout, not a 500s timeout. The range for pl seems to be 0..100, and not some orders of magnitude otherwise. All evidence indicates that the factor of 1000 was misplaced during some code change. --- ./check_icmp.c +++ /tmp/tmp.BWCqbw/check_icmp.c 2009-05-25 10:32:23.000000000 -0700 @@ -1271,10 +1271,10 @@ printf (" %s\n", _("specify a target")); printf (" %s\n", "-w"); printf (" %s", _("warning threshold (currently ")); - printf ("%0.3fms,%u%%)\n", (float)warn.rta / 1000 , warn.pl / 1000); + printf ("%0.3fms,%u%%)\n", (float)warn.rta / 1000 , warn.pl); printf (" %s\n", "-c"); printf (" %s", _("critical threshold (currently ")); - printf ("%0.3fms,%u%%)\n", (float)crit.rta, crit.pl); + printf ("%0.3fms,%u%%)\n", (float)crit.rta / 1000, crit.pl); printf (" %s\n", "-s"); printf (" %s\n", _("specify a source IP address or device name")); printf (" %s\n", "-n"); I know, its not an unified diff, but thats what we got so far, sorry. :) You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530553 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-06-01 22:49 Message: Hi again! ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2009-06-01 22:49 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2796624&group_id=29880 From noreply at sourceforge.net Tue Jun 2 01:20:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 01 Jun 2009 23:20:40 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2797757 ] segfault in check_mysql when checking slave (-S) Message-ID: Bugs item #2797757, was opened at 2009-05-28 10:03 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2797757&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nikita Kalabukhov (nikitajob) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in check_mysql when checking slave (-S) Initial Comment: Plugin Version (-V output): check_mysql v2034 (nagios-plugins 1.4.13) Plugin Name: check_mysql Plugin Commandline showing issues: check_mysql -u checker -p "123" -H 172.16.7.17 -P 13306 -S Operating System: FreeBSD 7.1-RELEASE-p4 amd64 Architecture: amd64 Compiler: gcc version 4.2.1 20070719 [FreeBSD] check_mysql crashes with segfault when checking mysql slave (-S option), regardless of warning/critical ranges specified or not (MYSQL server has to be alive to reproduce the bug). Only 64-bit arch is affected, i386 version works fine. I discovered the memory allocation problem in function _set_thresholds() (line 107 of lib/utils_base.c file): ... thresholds *temp_thresholds = NULL; temp_thresholds = malloc(sizeof(temp_thresholds)); ... Instead of thresholds struct size, it's requested the size of _pointer_ to thresholds, so it leads to insufficient memoty allocation for the struct and further memory corruption while mysql_init (&mysql) call (line 92 in check_mysql.c): --- gdb.txt --- Breakpoint 1 at 0x4020d0: file check_mysql.c, line 92. Starting program: ~/src/nagios-plugins-1.4.13/plugins/check_mysql -u checker -p "123" -H 172.16.7.17 -P 13306 -S Breakpoint 1, main (argc=10, argv=0x7fffffffeb70) at check_mysql.c:92 92 mysql_init (&mysql); Watchpoint 2: my_threshold->critical $1 = (range *) 0x0 Continuing. Watchpoint 2: my_threshold->critical Old value = (range *) 0x0 New value = (range *) 0x67 0x0000000801374420 in memcpy () from /lib/libc.so.7 #0 0x0000000801374420 in memcpy () from /lib/libc.so.7 #1 0x00000008012fb86f in strdup () from /lib/libc.so.7 #2 0x0000000801349b42 in _nsyylex () from /lib/libc.so.7 #3 0x0000000801348e63 in _nsyyparse () from /lib/libc.so.7 #4 0x000000080134e9a7 in nsdispatch () from /lib/libc.so.7 #5 0x000000080133fdbc in getservbyname_r () from /lib/libc.so.7 #6 0x000000080133f79b in if_nametoindex () from /lib/libc.so.7 #7 0x000000080065b2f6 in mysql_server_init () from /usr/pkg/lib/mysql/libmysqlclient.so.14 #8 0x000000080067a9b8 in mysql_init () from /usr/pkg/lib/mysql/libmysqlclient.so.14 #9 0x00000000004020dd in main (argc=10, argv=0x7fffffffeb70) at check_mysql.c:92 Continuing. Watchpoint 2: my_threshold->critical Old value = (range *) 0x67 New value = (range *) 0x7267 0x0000000801374420 in memcpy () from /lib/libc.so.7 Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0000000000403ad2 in check_range (value=0, my_range=0x70756f7267) at utils_base.c:168 168 if (my_range->alert_on == INSIDE) { --- end of gdb.txt --- The bug still exists in latest nagios-plugins snapshot. ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2009-06-02 01:20 Message: This is now fixed in Git. Thank you very much for reporting the bug and spotting the problem! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2797757&group_id=29880 From noreply at sourceforge.net Wed Jun 3 15:41:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Jun 2009 13:41:40 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2800510 ] Problem check_dhcp on infoblox Message-ID: Bugs item #2800510, was opened at 2009-06-03 15:41 Message generated for change (Tracker Item Submitted) made by ptitsnake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&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: Ptitsnake (ptitsnake) Assigned to: Nobody/Anonymous (nobody) Summary: Problem check_dhcp on infoblox Initial Comment: Hello, I try to check my DHCP server with Nagios 3.0.3 thanks to the "check_dhcp" plugins coming from the 1.4.13plugin pack on RedHat Entreprise R5 Server (2.6.18), (i386 or i686 because I have i686 i686 i386 when i launch uname -a). I use gcc 4.1.2-44. My approach is, my Nagios server is located in a network 192.168.A.B and my DHCP server 192.168.X.Y. And I try to check the correct work of DHCP server with the following command : ./check_dhcp -v -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF Requested server address: 92.168.X.Y Hardware address: 1:AB:23:CD:45:EF DHCP socket: 3 Pretending to be relay client 192.168.A.B DHCPDISCOVER to 192.168.X.Y port 67 DHCPDISCOVER XID: 164920453 (0x9D47C85) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 192.168.A.B send_dhcp_packet result: 548 recv_result_1: 331 recv_result_2: 331 receive_dhcp_packet() result: 331 receive_dhcp_packet() source: 192.168.X.Y Result=OK DHCPOFFER from IP address 192.168.X.Y via 192.168.X.Y DHCPOFFER XID: 164920453 (0x9D47C85) DHCPOFFER chaddr: 01AB23CD45EF DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.A.B DHCPOFFER siaddr: 0.0.0.0 DHCPOFFER giaddr: 192.168.A.B Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 6 (0x08) Option: 12 (0x12) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 604800 seconds Renewal Time: 302400 seconds Rebinding Time: 529200 seconds Added offer from server @ 192.168.X.Y of IP address 192.168.A.B No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 DHCP Server Match: Offerer=192.168.X.Y Requested=192.168.X.Y OK: Received 1 DHCPOFFER(s), 1 of 1 requested servers responded, requested address (192.168.90.B was offered, max lease time = 604800 sec. I've make a reservation in my infoblox with this MAC address. I try to analyse the return code but I have nothing, echo $result ==> NOTHING How I can verify, if the check works well, and In my web nagios interface toward the check_dhcp I have : (null). My declarations in the differents config files : Commands.cfg : ------------------------ #'check_dhcp' command definition avec r?servation adresse MAC define command{ command_name check_dhcp command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF } #'check_dhcp2' command definition avec r?servation adresse MAC au travers de variable define command{ command_name check_dhcp2 command_line sudo $USER1$/check_dhcp -v -u -s $ARG1$ -r $ARG2$ -m $ARG3$ } #'check_dhcp3' command definition simple define command{ command_name check_dhcp3 command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y } Switch.cfg : ----------------- #Define a service to check the DHCP service define service{ use generic-service host_name infoblox-forum service_description dhcp reservation MAC check_command check_dhcp } define service{ use generic-service host_name infoblox service_description dhcp2 reservation MAC avec ARG check_command check_dhcp2 } define service{ use generic-service host_name infoblox service_description dhcp3 sans rien check_command check_dhcp3 } How to solve problem with the server Infoblox? And how to test the return code of the plugins? Thank you in advance, for your help. Ptitsnake ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&group_id=29880 From noreply at sourceforge.net Wed Jun 3 15:43:22 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Jun 2009 13:43:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2800510 ] Problem check_dhcp on infoblox Message-ID: Bugs item #2800510, was opened at 2009-06-03 15:41 Message generated for change (Settings changed) made by ptitsnake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&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: 9 Private: No Submitted By: Ptitsnake (ptitsnake) Assigned to: Nobody/Anonymous (nobody) Summary: Problem check_dhcp on infoblox Initial Comment: Hello, I try to check my DHCP server with Nagios 3.0.3 thanks to the "check_dhcp" plugins coming from the 1.4.13plugin pack on RedHat Entreprise R5 Server (2.6.18), (i386 or i686 because I have i686 i686 i386 when i launch uname -a). I use gcc 4.1.2-44. My approach is, my Nagios server is located in a network 192.168.A.B and my DHCP server 192.168.X.Y. And I try to check the correct work of DHCP server with the following command : ./check_dhcp -v -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF Requested server address: 92.168.X.Y Hardware address: 1:AB:23:CD:45:EF DHCP socket: 3 Pretending to be relay client 192.168.A.B DHCPDISCOVER to 192.168.X.Y port 67 DHCPDISCOVER XID: 164920453 (0x9D47C85) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 192.168.A.B send_dhcp_packet result: 548 recv_result_1: 331 recv_result_2: 331 receive_dhcp_packet() result: 331 receive_dhcp_packet() source: 192.168.X.Y Result=OK DHCPOFFER from IP address 192.168.X.Y via 192.168.X.Y DHCPOFFER XID: 164920453 (0x9D47C85) DHCPOFFER chaddr: 01AB23CD45EF DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.A.B DHCPOFFER siaddr: 0.0.0.0 DHCPOFFER giaddr: 192.168.A.B Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 6 (0x08) Option: 12 (0x12) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 604800 seconds Renewal Time: 302400 seconds Rebinding Time: 529200 seconds Added offer from server @ 192.168.X.Y of IP address 192.168.A.B No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 DHCP Server Match: Offerer=192.168.X.Y Requested=192.168.X.Y OK: Received 1 DHCPOFFER(s), 1 of 1 requested servers responded, requested address (192.168.90.B was offered, max lease time = 604800 sec. I've make a reservation in my infoblox with this MAC address. I try to analyse the return code but I have nothing, echo $result ==> NOTHING How I can verify, if the check works well, and In my web nagios interface toward the check_dhcp I have : (null). My declarations in the differents config files : Commands.cfg : ------------------------ #'check_dhcp' command definition avec r?servation adresse MAC define command{ command_name check_dhcp command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF } #'check_dhcp2' command definition avec r?servation adresse MAC au travers de variable define command{ command_name check_dhcp2 command_line sudo $USER1$/check_dhcp -v -u -s $ARG1$ -r $ARG2$ -m $ARG3$ } #'check_dhcp3' command definition simple define command{ command_name check_dhcp3 command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y } Switch.cfg : ----------------- #Define a service to check the DHCP service define service{ use generic-service host_name infoblox-forum service_description dhcp reservation MAC check_command check_dhcp } define service{ use generic-service host_name infoblox service_description dhcp2 reservation MAC avec ARG check_command check_dhcp2 } define service{ use generic-service host_name infoblox service_description dhcp3 sans rien check_command check_dhcp3 } How to solve problem with the server Infoblox? And how to test the return code of the plugins? Thank you in advance, for your help. Ptitsnake ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&group_id=29880 From noreply at sourceforge.net Wed Jun 3 15:59:08 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Jun 2009 13:59:08 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2800510 ] Problem check_dhcp on infoblox Message-ID: Bugs item #2800510, was opened at 2009-06-03 15:41 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&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: Closed >Resolution: Invalid >Priority: 5 Private: No Submitted By: Ptitsnake (ptitsnake) Assigned to: Nobody/Anonymous (nobody) Summary: Problem check_dhcp on infoblox Initial Comment: Hello, I try to check my DHCP server with Nagios 3.0.3 thanks to the "check_dhcp" plugins coming from the 1.4.13plugin pack on RedHat Entreprise R5 Server (2.6.18), (i386 or i686 because I have i686 i686 i386 when i launch uname -a). I use gcc 4.1.2-44. My approach is, my Nagios server is located in a network 192.168.A.B and my DHCP server 192.168.X.Y. And I try to check the correct work of DHCP server with the following command : ./check_dhcp -v -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF Requested server address: 92.168.X.Y Hardware address: 1:AB:23:CD:45:EF DHCP socket: 3 Pretending to be relay client 192.168.A.B DHCPDISCOVER to 192.168.X.Y port 67 DHCPDISCOVER XID: 164920453 (0x9D47C85) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 192.168.A.B send_dhcp_packet result: 548 recv_result_1: 331 recv_result_2: 331 receive_dhcp_packet() result: 331 receive_dhcp_packet() source: 192.168.X.Y Result=OK DHCPOFFER from IP address 192.168.X.Y via 192.168.X.Y DHCPOFFER XID: 164920453 (0x9D47C85) DHCPOFFER chaddr: 01AB23CD45EF DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.A.B DHCPOFFER siaddr: 0.0.0.0 DHCPOFFER giaddr: 192.168.A.B Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 6 (0x08) Option: 12 (0x12) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 604800 seconds Renewal Time: 302400 seconds Rebinding Time: 529200 seconds Added offer from server @ 192.168.X.Y of IP address 192.168.A.B No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 DHCP Server Match: Offerer=192.168.X.Y Requested=192.168.X.Y OK: Received 1 DHCPOFFER(s), 1 of 1 requested servers responded, requested address (192.168.90.B was offered, max lease time = 604800 sec. I've make a reservation in my infoblox with this MAC address. I try to analyse the return code but I have nothing, echo $result ==> NOTHING How I can verify, if the check works well, and In my web nagios interface toward the check_dhcp I have : (null). My declarations in the differents config files : Commands.cfg : ------------------------ #'check_dhcp' command definition avec r?servation adresse MAC define command{ command_name check_dhcp command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y -r 192.168.A.B -m 01:AB:23:CD:45:EF } #'check_dhcp2' command definition avec r?servation adresse MAC au travers de variable define command{ command_name check_dhcp2 command_line sudo $USER1$/check_dhcp -v -u -s $ARG1$ -r $ARG2$ -m $ARG3$ } #'check_dhcp3' command definition simple define command{ command_name check_dhcp3 command_line sudo $USER1$/check_dhcp -u -s 192.168.X.Y } Switch.cfg : ----------------- #Define a service to check the DHCP service define service{ use generic-service host_name infoblox-forum service_description dhcp reservation MAC check_command check_dhcp } define service{ use generic-service host_name infoblox service_description dhcp2 reservation MAC avec ARG check_command check_dhcp2 } define service{ use generic-service host_name infoblox service_description dhcp3 sans rien check_command check_dhcp3 } How to solve problem with the server Infoblox? And how to test the return code of the plugins? Thank you in advance, for your help. Ptitsnake ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2009-06-03 15:59 Message: Please post questions regarding your Nagios configuration to the "nagios-users" mailing list (see https://lists.sourceforge.net/lists/listinfo/nagios-users) instead of submitting them as a Nagios Plugins bug (and raising the priority to the highest level). As you've shown yourself, the plugin itself works just fine if you call it on the command line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2800510&group_id=29880 From noreply at sourceforge.net Fri Jun 5 23:05:03 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jun 2009 21:05:03 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2801990 ] Fix to check_ntp - PATH_TO_NTPDATE must be defined Message-ID: Patches item #2801990, was opened at 2009-06-05 14:05 Message generated for change (Tracker Item Submitted) made by nomisbeme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to check_ntp - PATH_TO_NTPDATE must be defined Initial Comment: This plugin requires PATH_TO_NTPDATE to be defined, make sure it is defined during configuration. (4 patches to chkntp.pl, configure, configure.in, utils.pm.in) Simon sbennett AT groundworkopensource.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&group_id=29880 From noreply at sourceforge.net Fri Jun 5 23:21:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jun 2009 21:21:30 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2801990 ] Fix to check_ntp - PATH_TO_NTPDATE must be defined Message-ID: Patches item #2801990, was opened at 2009-06-05 14:05 Message generated for change (Comment added) made by nomisbeme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to check_ntp - PATH_TO_NTPDATE must be defined Initial Comment: This plugin requires PATH_TO_NTPDATE to be defined, make sure it is defined during configuration. (4 patches to chkntp.pl, configure, configure.in, utils.pm.in) Simon sbennett AT groundworkopensource.com ---------------------------------------------------------------------- >Comment By: Simon (nomisbeme) Date: 2009-06-05 14:21 Message: Patch against Plugin Version: 1.4.13 source Plugin Name: check_ntp Example Plugin Commandline: [nagios at kyburg libexec]$ ./check_ntp.pl -H 172.28.113.213 NTP CRITICAL: Offset 28507.496607 sec > +/- 120 sec Tested on operating system: RHEL5 Tested on architecture: ia32 Tested with compiler: gcc-4.1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&group_id=29880 From noreply at sourceforge.net Fri Jun 5 23:31:05 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jun 2009 21:31:05 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802005 ] Fix warn/crit in check_snmp_process_monitor.pl Message-ID: Patches item #2802005, was opened at 2009-06-05 14:31 Message generated for change (Tracker Item Submitted) made by nomisbeme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802005&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) Summary: Fix warn/crit in check_snmp_process_monitor.pl Initial Comment: This is a patch to a contrib plug-in. I know they're not supposed to be posted here but email to the original author is bouncing. Adds more useful output messages for this plugin. Plugin name: check_snmp_process_monitor Command-line: [nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e mingetty -c 6,9 OK - 6 process(es) found resembling 'mingetty' [[nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e mingetty -c 9,9 CRITICAL - 6 process(es) found resembling 'mingetty' [nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e init -w 7,8 WARNING - 1 process(es) found resembling 'init' Tested: RHEL 5 64-bit. Compiler: N/A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802005&group_id=29880 From noreply at sourceforge.net Fri Jun 5 23:31:41 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jun 2009 21:31:41 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802005 ] Better output from check_snmp_process_monitor.pl Message-ID: Patches item #2802005, was opened at 2009-06-05 14:31 Message generated for change (Settings changed) made by nomisbeme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802005&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) >Summary: Better output from check_snmp_process_monitor.pl Initial Comment: This is a patch to a contrib plug-in. I know they're not supposed to be posted here but email to the original author is bouncing. Adds more useful output messages for this plugin. Plugin name: check_snmp_process_monitor Command-line: [nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e mingetty -c 6,9 OK - 6 process(es) found resembling 'mingetty' [[nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e mingetty -c 9,9 CRITICAL - 6 process(es) found resembling 'mingetty' [nagios at kyburg libexec]$ ./check_snmp_process_monitor.pl -H 172.28.113.107 -C public -e init -w 7,8 WARNING - 1 process(es) found resembling 'init' Tested: RHEL 5 64-bit. Compiler: N/A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802005&group_id=29880 From noreply at sourceforge.net Fri Jun 5 23:36:20 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jun 2009 21:36:20 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802007 ] check_snmp_disk_monitor fix crit/warn options Message-ID: Patches item #2802007, was opened at 2009-06-05 14:36 Message generated for change (Tracker Item Submitted) made by nomisbeme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802007&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: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp_disk_monitor fix crit/warn options Initial Comment: This is a contrib patch, I couldn't raise the upstream developer. Warn/critical arguments were swapped. If there is a better home for contrib patches please let me know. Tested: 1.4.13/RHEL5/64-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802007&group_id=29880 From noreply at sourceforge.net Sat Jun 6 16:52:37 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Jun 2009 14:52:37 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2801990 ] Fix to check_ntp - PATH_TO_NTPDATE must be defined Message-ID: Patches item #2801990, was opened at 2009-06-05 17:05 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&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: Bugfix Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Simon (nomisbeme) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to check_ntp - PATH_TO_NTPDATE must be defined Initial Comment: This plugin requires PATH_TO_NTPDATE to be defined, make sure it is defined during configuration. (4 patches to chkntp.pl, configure, configure.in, utils.pm.in) Simon sbennett AT groundworkopensource.com ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-06-06 10:52 Message: check_ntp (.pl) is deprecated in favor of the new C plugin of the same name (in plugins/ in the source tree). It even seems that you installed it by hands as normal installation of the perl plugins removes the .pl suffix. If you have any issue running the C version of the check_ntp plugin please let us know. Thanks ---------------------------------------------------------------------- Comment By: Simon (nomisbeme) Date: 2009-06-05 17:21 Message: Patch against Plugin Version: 1.4.13 source Plugin Name: check_ntp Example Plugin Commandline: [nagios at kyburg libexec]$ ./check_ntp.pl -H 172.28.113.213 NTP CRITICAL: Offset 28507.496607 sec > +/- 120 sec Tested on operating system: RHEL5 Tested on architecture: ia32 Tested with compiler: gcc-4.1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2801990&group_id=29880 From noreply at sourceforge.net Mon Jun 8 14:29:45 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Jun 2009 12:29:45 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802895 ] Enforce C locale usage for parsing text output Message-ID: Patches item #2802895, was opened at 2009-06-08 14:29 Message generated for change (Tracker Item Submitted) made by guillomovitch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: Enforce C locale usage for parsing text output Initial Comment: Many plugins rely on parsing text output. But the formatting of this output varies according to the current system locale, making it quite fragile. It was already reported for instance in https://sourceforge.net/tracker/index.php?func=detail&aid=1433114&group_id=29880&atid=397597 The attached patch, contributed former mandriva package maintainer Oden Eriksson, enforces the use of C locale for all plugins, fixing the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 From mjbauer at eecs.tufts.edu Tue Jun 9 21:25:13 2009 From: mjbauer at eecs.tufts.edu (Michael J. Bauer) Date: Tue, 09 Jun 2009 15:25:13 -0400 Subject: [Nagiosplug-devel] check_snmp bug report and feature request: negative numbers for warning and critical flags Message-ID: <4A2EB719.3070003@eecs.tufts.edu> The check_snmp documentation says that both the warning and critical flags take integer ranges as arguments. However, both flags fail on negative integer ranges: # ./check_snmp -H localhost -o .1.3.6.1.4.1.42.2.70.101.1.1.8.1.4.88 -C public --critical=-13007:-11036 check_snmp: Invalid critical threshold - -13007:-11036 Usage:check_snmp -H -o [-w warn_range] [-c crit_range] [-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e retries] [-l label] [-u units] [-p port-number] [-d delimiter] [-D output-delimiter] [-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a authproto] [-A authpasswd] [-X privpasswd] I get the same result if I change it to --warning, or if I use -c or -w without the =. The OID in question is a sensor for the -12V power on a SunFire X4100 M2 motherboard. It reports voltage * 1000, and I'd like to be able to monitor it. The OS and version I'm using. The hardware is a SunFire X4100 M2 in all cases. As far as I can tell, I have the latest version of check_snmp, but I know that Red Hat versioning can be slippery. # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.3 (Tikanga) # ./check_snmp --version check_snmp v2021 (nagios-plugins 1.4.13) # rpm -qi nagios-plugins-snmp Name : nagios-plugins-snmp Relocations: (not relocatable) Version : 1.4.13 Vendor: Fedora Project Release : 11.el5 Build Date: Tue Nov 18 10:00:35 2008 Install Date: Fri Jan 23 16:21:22 2009 Build Host: xenbuilder2.fedora.redhat.com Group : Applications/System Source RPM: nagios-plugins-1.4.13-11.el5.src.rpm Size : 147712 License: GPLv2+ Signature : DSA/SHA1, Tue Nov 18 12:15:45 2008, Key ID 119cc036217521f6 Packager : Fedora Project URL : http://nagiosplug.sourceforge.net/ Summary : Nagios Plugin - check_snmp Description : Provides check_snmp support for Nagios. From ton.voon at opsera.com Tue Jun 9 22:07:18 2009 From: ton.voon at opsera.com (Ton Voon) Date: Tue, 9 Jun 2009 21:07:18 +0100 Subject: [Nagiosplug-devel] check_snmp bug report and feature request: negative numbers for warning and critical flags In-Reply-To: <4A2EB719.3070003@eecs.tufts.edu> References: <4A2EB719.3070003@eecs.tufts.edu> Message-ID: <66625642-0A87-4FEB-909F-2E2D370BB052@opsera.com> Hi Michael, Can you try the latest snapshot at http://nagiosplug.sourceforge.net/snapshot/ Thomas has recently converted the thresholds to use the standard library which supports negative numbers. Ton On 9 Jun 2009, at 20:25, Michael J. Bauer wrote: > The check_snmp documentation says that both the warning and critical > flags take integer ranges as arguments. However, both flags fail on > negative integer ranges: > > # ./check_snmp -H localhost -o .1.3.6.1.4.1.42.2.70.101.1.1.8.1.4.88 > -C > public --critical=-13007:-11036 > check_snmp: Invalid critical threshold - -13007:-11036 > Usage:check_snmp -H -o [-w warn_range] [-c > crit_range] > [-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e > retries] > [-l label] [-u units] [-p port-number] [-d delimiter] [-D output- > delimiter] > [-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a > authproto] > [-A authpasswd] [-X privpasswd] > > I get the same result if I change it to --warning, or if I use -c or > -w > without the =. The OID in question is a sensor for the -12V power > on a > SunFire X4100 M2 motherboard. It reports voltage * 1000, and I'd like > to be able to monitor it. > > The OS and version I'm using. The hardware is a SunFire X4100 M2 in > all > cases. As far as I can tell, I have the latest version of check_snmp, > but I know that Red Hat versioning can be slippery. > > # cat /etc/redhat-release > Red Hat Enterprise Linux Server release 5.3 (Tikanga) > > # ./check_snmp --version > check_snmp v2021 (nagios-plugins 1.4.13) > > # rpm -qi nagios-plugins-snmp > Name : nagios-plugins-snmp Relocations: (not > relocatable) > Version : 1.4.13 Vendor: Fedora Project > > Release : 11.el5 Build Date: Tue Nov 18 > 10:00:35 2008 > Install Date: Fri Jan 23 16:21:22 2009 Build Host: > xenbuilder2.fedora.redhat.com > Group : Applications/System Source RPM: > nagios-plugins-1.4.13-11.el5.src.rpm > Size : 147712 License: GPLv2+ > Signature : DSA/SHA1, Tue Nov 18 12:15:45 2008, Key ID > 119cc036217521f6 > Packager : Fedora Project > URL : http://nagiosplug.sourceforge.net/ > Summary : Nagios Plugin - check_snmp > Description : > Provides check_snmp support for Nagios. > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________________ > 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 Ton Voon Product Architect Opsera Limited | Unit 69 Suttons Business Park Reading | Berkshire | RG6 1AZ | UK Phone: +44 (0) 845 057 7887 Mobile: +44 (0) 7931 365796 Skype: tonvoon Email: ton.voon at opsera.com www.opsera.com This e-mail is confidential, intended only for the named recipient(s) above and may contain information that is privileged and confidential. If you receive this message in error, or are not the named recipient(s), please notify the sender at the phone number above, do not copy this message, do not disclose its contents to anyone, and delete this e-mail message from your computer. Although Opsera routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Opsera makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Opsera Limited is registered in the UK under Company Number 5396532. Our registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From Mark.Mathieson at concepts.co.nz Wed Jun 10 01:35:41 2009 From: Mark.Mathieson at concepts.co.nz (Mark Mathieson) Date: Wed, 10 Jun 2009 11:35:41 +1200 Subject: [Nagiosplug-devel] Check_http suggestion Message-ID: Greetings All, I was wondering if anyone had considered forcing, or at least allowing, the check_http plug-in to use the local *_proxy variables. It doesn't appear to use them at the moment. It may seem an odd sort of request, so I'll explain the situation briefly. I have a Nagios server that can see the outside world directly, but all of the internal users use a proxy. I'm running check_http to verify that web access is available to users and various internal services. Thing is, because the existing check_http doesn't use a proxy but the users do, if the proxy link goes down, Nagios thinks everything is fine and I don't find out that it's not until users start screaming. I've tried embedding the call in a script, exporting the *_proxy variables manually, but check_http happily ignores the variables and will continue returned success values due to the direct link, even if you turn the proxy off! I can't turn the direct link off, as there are other checks that rely on it. My only other option appears to be writing my own plug-in leveraging wget. Any thoughts? Cheers, Mark Mathieson Senior Systems Engineer computer concepts limited Notice of confidential information: The information contained in this e-mail message is confidential information and may also be legally privileged, intended only for the individual or entity named above. If you are not the intended recipient you are hereby notified that any use, review, dissemination, distribution or copying of this document is strictly prohibited. If you have received this document in error, please immediately notify the sender by telephone and destroy the message. Thank you. Any pricing quoted in this email is exclusive of GST and freight and is only valid while stocks are available at the quoted price. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tiberiu.Padurean at tdn.de Wed Jun 10 13:09:43 2009 From: Tiberiu.Padurean at tdn.de (Tiberiu Padurean) Date: Wed, 10 Jun 2009 13:09:43 +0200 Subject: [Nagiosplug-devel] check_mysql not compiling. Message-ID: Hello, I have a Suse10 Enterprise server and I need to verify mysql on it with the "check_mysql" nagios plugin. Unfortunately when I compile the plugins, the check_mysql is not created. I have tried : ./configure --with-mysql=/usr/bin/ --prefix=/home/user/plugins/ Or ./configure --with-mysql=/usr/bin/mysql_config --prefix=/home/user/plugins/ The file mysql_config exists and is located in that directory. And nothing seems to work. Any help will be appreciated. Thanks Tiberiu Padurean -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Wed Jun 10 14:24:12 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 10 Jun 2009 14:24:12 +0200 Subject: [Nagiosplug-devel] check_mysql not compiling. In-Reply-To: References: Message-ID: <20090610122412.GD49915831@CIS.FU-Berlin.DE> * Tiberiu Padurean [2009-06-10 13:09]: > I have a Suse10 Enterprise server and I need to verify mysql on it with the "check_mysql" nagios plugin. > Unfortunately when I compile the plugins, the check_mysql is not created. > I have tried : > > ./configure --with-mysql=/usr/bin/ --prefix=/home/user/plugins/ > > Or > > ./configure --with-mysql=/usr/bin/mysql_config --prefix=/home/user/plugins/ > > The file mysql_config exists and is located in that directory. Try "./configure --with-mysql=/usr --prefix=/home/user/plugins". If that doesn't help, check the output of the configure script for anything regarding MySQL and if still won't work, report what you found out on: Holger From dermoth at aei.ca Wed Jun 10 14:15:16 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 10 Jun 2009 08:15:16 -0400 Subject: [Nagiosplug-devel] check_mysql not compiling. In-Reply-To: References: Message-ID: <4A2FA3D4.1080007@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/06/09 07:09 AM, Tiberiu Padurean wrote: > Hello, > > > > I have a Suse10 Enterprise server and I need to verify mysql on it with > the ?check_mysql? nagios plugin. > > Unfortunately when I compile the plugins, the check_mysql is not created. > > I have tried : > > > > ./configure --with-mysql=/usr/bin/ --prefix=/home/user/plugins/ > > > > Or > > > > ./configure --with-mysql=/usr/bin/mysql_config --prefix=/home/user/plugins/ If mysql is installed in a standard location you shouldn't have to specify a mysql path... Do you have the mysql development files installed (probably a package named mysql-devel)? Do you have Mysql headers files installed in /usr/include/mysql/ ? If you answered yes to the above two questions, can you: 1. Send the output of the following three commands: $ mysql_config --cflags $ mysql_config --include $ mysql_config --libs 2. Send your config.log file or the relevant part of it? Thanks. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKL6PU6dZ+Kt5BchYRAgjdAKCIfJA10haPYqyEPc4SjtLmSzzUEgCfYFCf VCD+Rc+mkYekARInwlmTO24= =pEdK -----END PGP SIGNATURE----- From hir3npatel at gmail.com Wed Jun 10 21:24:22 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Wed, 10 Jun 2009 21:24:22 +0200 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: References: Message-ID: <4A300866.40902@gmail.com> Mark Mathieson wrote: > I was wondering if anyone had considered forcing, or at least allowing, > the check_http plug-in to use the local *_proxy variables. It doesn?t > appear to use them at the moment. > > > > It may seem an odd sort of request, so I?ll explain the situation > briefly. I have a Nagios server that can see the outside world > directly, but all of the internal users use a proxy. I?m running > check_http to verify that web access is available to users and various > internal services. Thing is, because the existing check_http doesn?t > use a proxy but the users do, if the proxy link goes down, Nagios thinks > everything is fine and I don?t find out that it?s not until users start > screaming. > > > > I?ve tried embedding the call in a script, exporting the *_proxy > variables manually, but check_http happily ignores the variables and > will continue returned success values due to the direct link, even if > you turn the proxy off! I can?t turn the direct link off, as there are > other checks that rely on it. > > > > My only other option appears to be writing my own plug-in leveraging wget. > > > > Any thoughts? > > personally I think it's a good idea, it could be useful in cases like yours, would a patch for this be accepted? I'd be prepared to work on this if core developers would accept it? From Patrick.Zambelli at wuerth-phoenix.com Thu Jun 11 10:16:26 2009 From: Patrick.Zambelli at wuerth-phoenix.com (Zambelli, Patrick) Date: Thu, 11 Jun 2009 10:16:26 +0200 Subject: [Nagiosplug-devel] check_icmp RTA calculation issue Message-ID: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> Hello, I would like to report a behavior of check_icmp I discovered on an installation with ping and system time issues. The result of the execution of the Nagios check_icmp was containing strange rta values. In most cases it is the max integer value minus something, indicating an integer value overflow. Checking the source code of check_icmp.c of the last plugin version I found the condition in line 1030 where the value early is compared to value early. Since also the comment is indicating if early > later ... I would suggest to change to condition to this: /* if early > later we return 0 so as to indicate a timeout */ if(early->tv_sec > later->tv_sec || (early->tv_sec == later->tv_sec && early->tv_usec > later->tv_usec)) { return 0; } Old code: if(early->tv_sec > early->tv_sec || (early->tv_sec == later->tv_sec && early->tv_usec > later->tv_usec)) { return 0; } This is a fragment of some of the strange check results: [15-05-2009 23:47:20] SERVICE ALERT: comserverhrl;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.95: rta 4294902.440ms, lost 50% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:47:10] SERVICE ALERT: srvisa;PING;CRITICAL;SOFT;1;CRITICAL - 192.168.1.2: rta 4294895.381ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:43:42] SERVICE ALERT: sw-10.1.6.237;PING;OK;SOFT;2;OK - 10.1.6.237: rta 0.775ms, lost 0% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:43:42] SERVICE ALERT: srvex;PING;OK;SOFT;2;OK - 10.1.6.4: rta 0.166ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:42:42] SERVICE ALERT: sw-10.1.6.237;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.237: rta 2147448.008ms, lost 33% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:42:42] SERVICE ALERT: srvex;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.4: rta 858994.148ms, lost 0% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:41:43] SERVICE ALERT: xpbd2;PING;OK;SOFT;2;OK - 10.1.6.93: rta 0.139ms, lost 0% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:41:03] SERVICE ALERT: webappliance;PING;OK;SOFT;2;OK - 10.1.6.10: rta 0.109ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:40:43] SERVICE ALERT: xpbd2;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.93: rta 4294894.831ms, lost 50% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:40:03] SERVICE ALERT: webappliance;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.10: rta 4294895.864ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:22:45] SERVICE ALERT: ds4700;PING;OK;SOFT;2;OK - 10.1.20.240: rta 0.225ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:21:45] SERVICE ALERT: ds4700;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.20.240: rta 4294895.387ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:18:36] SERVICE ALERT: srvdc2;PING;OK;SOFT;2;OK - 10.1.6.9: rta 14.452ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:17:35] SERVICE ALERT: srvdc2;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.9: rta 4294895.334ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:16:45] SERVICE ALERT: ds4700;PING;OK;SOFT;2;OK - 10.1.20.240: rta 0.327ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:15:46] SERVICE ALERT: ds4700;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.20.240: rta 4294895.512ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:13:26] SERVICE ALERT: milntssrv1;PING;OK;SOFT;2;OK - 10.1.6.7: rta 0.167ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:12:26] SERVICE ALERT: milntssrv1;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.7: rta 4294895.420ms, lost 50% [cid:image002.png at 01C9EA7D.AD9A6C40][15-05-2009 23:05:47] SERVICE ALERT: xpbd2;PING;OK;SOFT;2;OK - 10.1.6.93: rta 0.164ms, lost 0% [cid:image001.png at 01C9EA7D.AD9A6C40][15-05-2009 23:04:47] SERVICE ALERT: xpbd2;PING;CRITICAL;SOFT;1;CRITICAL - 10.1.6.93: rta 4294895.488ms, lost 50% Best regards Patrick W?rth Phoenix S.r.l. Patrick Zambelli System Integration Via Kravogl 4 I-39100 Bolzano Direct: +39 0471 564 174 E-Mail: patrick.zambelli at wuerth-phoenix.com Website: www.wuerth-phoenix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1166 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1367 bytes Desc: image002.png URL: From noreply at sourceforge.net Thu Jun 11 14:43:21 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Jun 2009 12:43:21 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2804825 ] Range support for check_nt Message-ID: Patches item #2804825, was opened at 2009-06-11 14:43 Message generated for change (Tracker Item Submitted) made by rakhun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2804825&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: Henrik Nilsson (rakhun) Assigned to: Nobody/Anonymous (nobody) Summary: Range support for check_nt Initial Comment: Plugin name and version: check_nt v1.4.13.138.g9eab.dirty (nagios-plugins 1.4.13) Example commandline: plugins/check_nt -H IP -v USEDDISKSPACE -l C -w 50 -c 5:95 Tested on: Fedora 10, i686 with compiler gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) The patch makes it possible to determine the status based on ranges, like in the example where the status is critical if disk usage is below 5 or above 95 (not the best example, but something might be seriously wrong if the usage gets too low) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2804825&group_id=29880 From PsychoTrahe at gmx.de Thu Jun 11 18:22:44 2009 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Thu, 11 Jun 2009 18:22:44 +0200 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: <4A300866.40902@gmail.com> References: <4A300866.40902@gmail.com> Message-ID: <1244737364.24688.19.camel@pc.site> Am Mittwoch, den 10.06.2009, 21:24 +0200 schrieb Hiren Patel: > Mark Mathieson wrote: > > I was wondering if anyone had considered forcing, or at least allowing, > > the check_http plug-in to use the local *_proxy variables. It doesn?t > > appear to use them at the moment. To me, specifying the proxy to use should be a command line argument rather than env-var. It can then be easily specified in the nagios/nrpe config. > > It may seem an odd sort of request, so I?ll explain the situation > > briefly. I have a Nagios server that can see the outside world > > directly, but all of the internal users use a proxy. I?m running > > check_http to verify that web access is available to users and various > > internal services. Thing is, because the existing check_http doesn?t > > use a proxy but the users do, if the proxy link goes down, Nagios thinks > > everything is fine and I don?t find out that it?s not until users start > > screaming. With current version you can specify -I to define where the tcp socket connects to. -H is then used to select the requested name in the http "Host:" header. So -I proxy -H www.google.com should work but will not function with SOCKS (not 100% sure though). Another drawback is that with current implementation, the proxy you use use must listen on the same port as the website you're requesting does since tcp connect and Host header use the same variable (-p). > personally I think it's a good idea, it could be useful in cases like > yours, would a patch for this be accepted? I'd be prepared to work on > this if core developers would accept it? I wouldn't mind if the implementation is clean and backward compatible. As said, the environment thing would be something I would not like so much - and probably refuse depending on team's feedback. Also providing proper test cases of course makes it easier for us to commit enhancements. Matthias From marc at ena.com Thu Jun 11 18:46:15 2009 From: marc at ena.com (Marc Powell) Date: Thu, 11 Jun 2009 11:46:15 -0500 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: <1244737364.24688.19.camel@pc.site> References: <4A300866.40902@gmail.com> <1244737364.24688.19.camel@pc.site> Message-ID: On Jun 11, 2009, at 11:22 AM, Matthias Eble wrote: > Am Mittwoch, den 10.06.2009, 21:24 +0200 schrieb Hiren Patel: >> Mark Mathieson wrote: > To me, specifying the proxy to use should be a command line argument > rather than env-var. It can then be easily specified in the nagios/ > nrpe > config. I concur. It's clearer and easier to troubleshoot problems. > With current version you can specify -I to define where the tcp socket > connects to. -H is then used to select the requested name in the http > "Host:" header. So -I proxy -H www.google.com should work but will not > function with SOCKS (not 100% sure though). Yes, the use of -I and -H works. I use that methodology to check several urls through several hundred proxies... Can't comment about SOCKS though... command_line $USER1$/check_http -H $ARG1$ -I $HOSTADDRESS$ -p 8080 -wt 20 -ct 30 -to 35 -u http://$ARG1$ -s $ARG2$ ... check_command check_filt!www.myspace.com!block.cgi > nother drawback is that > with current implementation, the proxy you use use must listen on the > same port as the website you're requesting does since tcp connect and > Host header use the same variable (-p). > >> personally I think it's a good idea, it could be useful in cases like >> yours, would a patch for this be accepted? I'd be prepared to work on >> this if core developers would accept it? There's no need as far as I can tell. Maybe it's some voodoo from the proxies I use but I don't believe so -- $ ~nagios/libexec/check_http -v -I cache01.davidson.tn.ena.net -p 8080 -H transamrit.net -u http://transamrit.net:8082 GET http://transamrit.net:8082 HTTP/1.0 User-Agent: check_http/1.89 (nagios-plugins 1.4.3) Host: transamrit.net http://cache01.davidson.tn.ena.net:8080http://transamrit.net:8082 is 14868 characters STATUS: HTTP/1.1 200 OK **** HEADER **** Content-Type: text/html; charset=iso-8859-1 Via: 1.1 cache01.davidson Content-Length: 14690 Connection: close Age: 0 Date: Thu, 11 Jun 2009 16:41:13 GMT **** CONTENT **** BNBT Tracker Info {snip} HTTP OK HTTP/1.1 200 OK - 14868 bytes in 0.703 seconds | time=0.703203s;;;0.000000 size=14868B;;;0 -- Marc From hir3npatel at gmail.com Thu Jun 11 21:21:29 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Thu, 11 Jun 2009 21:21:29 +0200 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: References: <4A300866.40902@gmail.com> <1244737364.24688.19.camel@pc.site> Message-ID: <4A315939.8010207@gmail.com> Marc Powell wrote: >>> personally I think it's a good idea, it could be useful in cases like >>> yours, would a patch for this be accepted? I'd be prepared to work on >>> this if core developers would accept it? > > There's no need as far as I can tell. Maybe it's some voodoo from the > proxies I use but I don't believe so -- > > $ ~nagios/libexec/check_http -v -I cache01.davidson.tn.ena.net -p 8080 > -H transamrit.net -u http://transamrit.net:8082 > GET http://transamrit.net:8082 HTTP/1.0 > User-Agent: check_http/1.89 (nagios-plugins 1.4.3) > Host: transamrit.net > > > http://cache01.davidson.tn.ena.net:8080http://transamrit.net:8082 is > 14868 characters > STATUS: HTTP/1.1 200 OK > **** HEADER **** > Content-Type: text/html; charset=iso-8859-1 > Via: 1.1 cache01.davidson > Content-Length: 14690 > Connection: close > Age: 0 > Date: Thu, 11 Jun 2009 16:41:13 GMT > **** CONTENT **** > > > BNBT Tracker Info > > {snip} > HTTP OK HTTP/1.1 200 OK - 14868 bytes in 0.703 seconds | > time=0.703203s;;;0.000000 size=14868B;;;0 > ah okay, looks legit. from http://www.ietf.org/rfc/rfc2616.txt: ------- 5.1 Request-Line The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF Request-URI = "*" | absoluteURI | abs_path | authority ..... The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI .... An example Request-Line would be: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 ------- sorry for the noise, seems -I and -u can be used to request from a proxy then, not too sure about socks either. From hamid at pcsourcenet.com Thu Jun 11 18:54:07 2009 From: hamid at pcsourcenet.com (Hamid Majidy) Date: Thu, 11 Jun 2009 09:54:07 -0700 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: References: <4A300866.40902@gmail.com> <1244737364.24688.19.camel@pc.site> Message-ID: <15d201c9eab5$3c8acf80$b5a06e80$@com> SOCKS proxies can require user name & password so they can track activity by user. Just a design consideration if proxy support is to be added. -----Original Message----- From: Marc Powell [mailto:marc at ena.com] Sent: Thursday, June 11, 2009 9:46 AM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] Check_http suggestion On Jun 11, 2009, at 11:22 AM, Matthias Eble wrote: > Am Mittwoch, den 10.06.2009, 21:24 +0200 schrieb Hiren Patel: >> Mark Mathieson wrote: > To me, specifying the proxy to use should be a command line argument > rather than env-var. It can then be easily specified in the nagios/ > nrpe > config. I concur. It's clearer and easier to troubleshoot problems. > With current version you can specify -I to define where the tcp socket > connects to. -H is then used to select the requested name in the http > "Host:" header. So -I proxy -H www.google.com should work but will not > function with SOCKS (not 100% sure though). Yes, the use of -I and -H works. I use that methodology to check several urls through several hundred proxies... Can't comment about SOCKS though... command_line $USER1$/check_http -H $ARG1$ -I $HOSTADDRESS$ -p 8080 -wt 20 -ct 30 -to 35 -u http://$ARG1$ -s $ARG2$ ... check_command check_filt!www.myspace.com!block.cgi > nother drawback is that > with current implementation, the proxy you use use must listen on the > same port as the website you're requesting does since tcp connect and > Host header use the same variable (-p). > >> personally I think it's a good idea, it could be useful in cases like >> yours, would a patch for this be accepted? I'd be prepared to work on >> this if core developers would accept it? There's no need as far as I can tell. Maybe it's some voodoo from the proxies I use but I don't believe so -- $ ~nagios/libexec/check_http -v -I cache01.davidson.tn.ena.net -p 8080 -H transamrit.net -u http://transamrit.net:8082 GET http://transamrit.net:8082 HTTP/1.0 User-Agent: check_http/1.89 (nagios-plugins 1.4.3) Host: transamrit.net http://cache01.davidson.tn.ena.net:8080http://transamrit.net:8082 is 14868 characters STATUS: HTTP/1.1 200 OK **** HEADER **** Content-Type: text/html; charset=iso-8859-1 Via: 1.1 cache01.davidson Content-Length: 14690 Connection: close Age: 0 Date: Thu, 11 Jun 2009 16:41:13 GMT **** CONTENT **** BNBT Tracker Info {snip} HTTP OK HTTP/1.1 200 OK - 14868 bytes in 0.703 seconds | time=0.703203s;;;0.000000 size=14868B;;;0 -- Marc ---------------------------------------------------------------------------- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________________ 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 From dermoth at aei.ca Fri Jun 12 01:31:55 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 11 Jun 2009 19:31:55 -0400 Subject: [Nagiosplug-devel] Check_http suggestion In-Reply-To: <4A315939.8010207@gmail.com> References: <4A300866.40902@gmail.com> <1244737364.24688.19.camel@pc.site> <4A315939.8010207@gmail.com> Message-ID: <4A3193EB.8080803@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/09 03:21 PM, Hiren Patel wrote: > Marc Powell wrote: >> >> $ ~nagios/libexec/check_http -v -I cache01.davidson.tn.ena.net -p 8080 >> -H transamrit.net -u http://transamrit.net:8082 >> GET http://transamrit.net:8082 HTTP/1.0 >> User-Agent: check_http/1.89 (nagios-plugins 1.4.3) >> Host: transamrit.net >> >> >> http://cache01.davidson.tn.ena.net:8080http://transamrit.net:8082 is >> 14868 characters >> STATUS: HTTP/1.1 200 OK >> **** HEADER **** >> Content-Type: text/html; charset=iso-8859-1 >> Via: 1.1 cache01.davidson >> Content-Length: 14690 >> Connection: close >> Age: 0 >> Date: Thu, 11 Jun 2009 16:41:13 GMT >> **** CONTENT **** >> >> >> BNBT Tracker Info >> >> {snip} >> HTTP OK HTTP/1.1 200 OK - 14868 bytes in 0.703 seconds | >> time=0.703203s;;;0.000000 size=14868B;;;0 >> > ah okay, looks legit. > from http://www.ietf.org/rfc/rfc2616.txt: > ------- > 5.1 Request-Line > > The Request-Line begins with a method token, followed by the > Request-URI and the protocol version, and ending with CRLF. The > elements are separated by SP characters. No CR or LF is allowed > except in the final CRLF sequence. > > Request-Line = Method SP Request-URI SP HTTP-Version CRLF > > Request-URI = "*" | absoluteURI | abs_path | authority > > > ..... > > The absoluteURI form is REQUIRED when the request is being made to a > proxy. The proxy is requested to forward the request or service it > from a valid cache, and return the response. Note that the proxy MAY > forward the request on to another proxy or directly to the server > specified by the absoluteURI > > .... > > An example > Request-Line would be: > > GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 > ------- > sorry for the noise, seems -I and -u can be used to request from a proxy > then, not too sure about socks either. I'm not against supporting proxies in check_http, but in the mean time you could try that: > $ plugins/check_http -I localhost -H www.w3.org -u http://www.w3.org/pub/WWW/TheProject.html -vvv > GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 > User-Agent: check_http/v1.4.13.133.g18d6.dirty (nagios-plugins 1.4.13) > Connection: close > Host: www.w3.org Also it is possible to pass multi-line requests with check_tcp... some of my http checks are actually implemented with check_tcp because of similar issues. On a side note, every once in a while we talk about using a real http library like curl for check_http... doing so would also allow proxy support, and likely many other features... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKMZPr6dZ+Kt5BchYRAo/sAKDm+too8QDh34y6c6K9gmpVXrGBAgCg0Ib7 G7S8RDUsqDcSE6vbLLmlLs4= =9dLA -----END PGP SIGNATURE----- From addw at phcomp.co.uk Fri Jun 12 19:32:59 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Fri, 12 Jun 2009 18:32:59 +0100 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: <1243357878.10342.10.camel@pc.site> References: <20090526154320.GI7032@mint.phcomp.co.uk> <1243357878.10342.10.camel@pc.site> Message-ID: <20090612173259.GQ14436@mint.phcomp.co.uk> On Tue, May 26, 2009 at 07:11:18PM +0200, Matthias Eble wrote: > Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: > > About a week ago I put up a patch for the check_procs plugin, I have not > > seen any comment about it. How can I help it to be made part of the released version ? > > > > You can view a description of it here: > > > > http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 > > > > Hi Alain, > > I had a short look at it and I somewhat disliked the fact that it makes > use of a temp file. Even though this looks absolutely arguable for your > enhancement, we usually avoid temporary files: > http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 > > Submitting patches to the tracker and ringing the bells on np-devel if > nothing happens is the right approach. > > Detecting a CPU hog would be a nice thing, though. Other opinions? No comments since -- neither has it been integrated with HEAD. What do I need to do to get the patch put in ? -- 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 Sun Jun 14 12:57:59 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sun, 14 Jun 2009 12:57:59 +0200 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: <20090612173259.GQ14436@mint.phcomp.co.uk> References: <20090526154320.GI7032@mint.phcomp.co.uk> <1243357878.10342.10.camel@pc.site> <20090612173259.GQ14436@mint.phcomp.co.uk> Message-ID: <4A34D7B7.6060807@gmail.com> Alain Williams wrote: > On Tue, May 26, 2009 at 07:11:18PM +0200, Matthias Eble wrote: >> Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: >>> About a week ago I put up a patch for the check_procs plugin, I have not >>> seen any comment about it. How can I help it to be made part of the released version ? >>> >>> You can view a description of it here: >>> >>> http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 >>> >> Hi Alain, >> >> I had a short look at it and I somewhat disliked the fact that it makes >> use of a temp file. Even though this looks absolutely arguable for your >> enhancement, we usually avoid temporary files: >> http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 >> >> Submitting patches to the tracker and ringing the bells on np-devel if >> nothing happens is the right approach. >> >> Detecting a CPU hog would be a nice thing, though. Other opinions? > > No comments since -- neither has it been integrated with HEAD. > > What do I need to do to get the patch put in ? > opinion: personally this feature would make no difference to me, in our setup we use check_procs to ensure that service x is running, we hardly use any of the other metrics. we have load and swap checks for CPU/memory abuse, and we usually log onto the machine at the time of an alert to see what the offender is and deal with it as needed. it is an interesting feature though. From hir3npatel at gmail.com Sun Jun 14 13:41:30 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sun, 14 Jun 2009 13:41:30 +0200 Subject: [Nagiosplug-devel] check_icmp RTA calculation issue In-Reply-To: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> References: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> Message-ID: <4A34E1EA.6010507@gmail.com> Zambelli, Patrick wrote: > Hello, > > > > I would like to report a behavior of check_icmp I discovered on an > installation with ping and system time issues. The result of the > execution of the Nagios check_icmp was containing strange rta values. > > In most cases it is the max integer value minus something, indicating an > integer value overflow. > > > > Checking the source code of check_icmp.c of the last plugin version I > found the condition in line 1030 where the value early is compared to > value early. Since also the comment is indicating if early > later ? I > would suggest to change to condition to this: > > > > /* if early > later we return 0 so as to indicate a timeout */ > > if(early->tv_sec > later->tv_sec || > > (early->tv_sec == later->tv_sec && early->tv_usec > later->tv_usec)) > > { > > return 0; > > } I think the developers prefer diffs for these, I noticed that this is still not committed to svn, diff attached. thanks for reporting this and the fix. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_icmp URL: From Mark.Mathieson at concepts.co.nz Sun Jun 14 23:29:08 2009 From: Mark.Mathieson at concepts.co.nz (Mark Mathieson) Date: Mon, 15 Jun 2009 09:29:08 +1200 Subject: [Nagiosplug-devel] FW: Nagiosplug-devel Digest, Vol 37, Issue 6 Message-ID: Greetings All, So many responses to my check_http proxy query! Thank you all. I do, however, have another spanner to throw in the works, as below: proxy authentication. ;) > I'm not against supporting proxies in check_http, but in the mean time > you could try that: > > > $ plugins/check_http -I localhost -H www.w3.org -u > http://www.w3.org/pub/WWW/TheProject.html -vvv > > GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 > > User-Agent: check_http/v1.4.13.133.g18d6.dirty (nagios-plugins 1.4.13) > > Connection: close > > Host: www.w3.org I tried this, and it works fine as long as your proxy doesn't require authentication. Of course, at least one of the ones I monitor requires authentication. Check via unauthenticated proxy: --- # ./check_http -vvv -I 192.168.0.8 -p 3128 -H www.google.com -u http://www.google.com/index.html GET http://www.google.com/index.html HTTP/1.0 User-Agent: check_http/v2053 (nagios-plugins 1.4.13) Connection: close Host: www.google.com:3128 http://192.168.0.8:3128http://www.google.com/index.html is 826 characters [snip body] HTTP OK - HTTP/1.0 302 Moved Temporarily - 0.332 second response time |time=0.332021s;;;0.000000 size=826B;;;0 --- Check via authenticated proxy (details provided for //) --- # ./check_http -vvv -I -p 8081 -a : -H www.google.com -u http://www.google.com/index. GET http://www.google.com/index.html HTTP/1.0 User-Agent: check_http/v2053 (nagios-plugins 1.4.13) Connection: close Host: www.google.com:8081 Authorization: Basic bGRhcDpsZGFwcXVlcnk= CRITICAL - Socket timeout after 10 seconds --- Any thoughts? I think the problem is that the -a switch is a reference to authentication on the Host only. Not sure how to pass authentication to the proxy. Note also that I am checking from the Nagios box itself, as I am trying to determine functionality of the web access, rather than from the W2K3 server that acts as the proxy. Cheers, Mark Notice of confidential information: The information contained in this e-mail message is confidential information and may also be legally privileged, intended only for the individual or entity named above. If you are not the intended recipient you are hereby notified that any use, review, dissemination, distribution or copying of this document is strictly prohibited. If you have received this document in error, please immediately notify the sender by telephone and destroy the message. Thank you. Any pricing quoted in this email is exclusive of GST and freight and is only valid while stocks are available at the quoted price. From noreply at sourceforge.net Sun Jun 14 23:53:35 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 14 Jun 2009 21:53:35 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2343438 ] SNMPv3 fixes for perl plugins Message-ID: Bugs item #2343438, was opened at 2008-11-25 14:32 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2343438&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Robin Schroeder (r_schroeder) >Assigned to: Matthias Eble (psychotrahe) Summary: SNMPv3 fixes for perl plugins Initial Comment: When calling check_ifoperstatus or check_ifstatus with the following arguments, I get errors: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 UNKNOWN: Invalid argument '-authpass => XXXXXXXX' ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Missing arguments! check_ifoperstatus and check_ifstatus generate the "-authpass => ..." parameter in a way, Net::SNMP->session doesn't understand. check_ifstatus doesn't recognize "-L authPriv". The attached patch fixes all problems for me. Some details about my environment: Plugin Version (-V output): check_ifoperstatus v1642 (nagios-plugins 1.4.13) Plugin Version (-V output): check_ifstatus v884 (nagios-plugins 1.4.13) Plugin Name: check_ifoperstatus, check_ifstatus Plugin Commandline showing issues: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Operating System: Debian GNU/Linux etch (4.0) Architecture: i686 Compiler: perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.24.4, archname=i486-linux-gnu-thread-multi uname='linux ninsei 2.6.24.4 #1 smp preempt fri apr 18 15:36:09 pdt 2008 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-21)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8 gnulibc_version='2.3.6' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Apr 25 2008 20:23:05 @INC: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-06-14 23:53 Message: Hi Robin, I can affirm the problems you encountered. However I didn't apply your patches as I made some further restructuring of these plugins. You can try our latest snapshot from http://repo.or.cz/w/nagiosplugins.git or http://nagiosplug.sourceforge.net/snapshot/ I also added a privproto flag to select the privacy protocol. Matthias ---------------------------------------------------------------------- Comment By: Michael Kania (mkania) Date: 2009-01-12 23:51 Message: The patches for check_ifoperstatus worked great. ---------------------------------------------------------------------- Comment By: Robin Schroeder (r_schroeder) Date: 2008-12-29 22:24 Message: Nobody using these plugins except me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2343438&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jun 15 09:27:37 2009 From: matthias.eble at mailing.kaufland-informationssysteme.com (matthias eble) Date: Mon, 15 Jun 2009 09:27:37 +0200 Subject: [Nagiosplug-devel] check_icmp RTA calculation issue In-Reply-To: <4A34E1EA.6010507@gmail.com> References: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> <4A34E1EA.6010507@gmail.com> Message-ID: <1245050857.15418.6.camel@de101315> Hi, On Sun, 2009-06-14 at 13:41 +0200, Hiren Patel wrote: > Zambelli, Patrick wrote: > > I would like to report a behavior of check_icmp I discovered on an > > installation with ping and system time issues. The result of the > > execution of the Nagios check_icmp was containing strange rta > values. > > > > In most cases it is the max integer value minus something, > indicating an > > integer value overflow. > --- plugins-root/check_icmp.c 2009-06-12 09:43:54.000000000 +0200 > +++ /tmp/check_icmp.c 2009-06-14 13:37:34.000000000 +0200 > @@ -1035,7 +1035,7 @@ > if(!early) early = &prog_start; > > /* if early > later we return 0 so as to indicate a timeout */ > - if(early->tv_sec > early->tv_sec || > + if(early->tv_sec > later->tv_sec || > (early->tv_sec == later->tv_sec && early->tv_usec > later->tv_usec)) > { > return 0; I committed the change to git yesterday. Thanks to both of you. As a sidenote, fixing the clock issue would still be a good idea. Matthias From noreply at sourceforge.net Mon Jun 15 11:53:44 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Jun 2009 09:53:44 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802895 ] Enforce C locale usage for parsing text output Message-ID: Patches item #2802895, was opened at 2009-06-08 14:29 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: Enforce C locale usage for parsing text output Initial Comment: Many plugins rely on parsing text output. But the formatting of this output varies according to the current system locale, making it quite fragile. It was already reported for instance in https://sourceforge.net/tracker/index.php?func=detail&aid=1433114&group_id=29880&atid=397597 The attached patch, contributed former mandriva package maintainer Oden Eriksson, enforces the use of C locale for all plugins, fixing the issue. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-06-15 11:53 Message: any chance to get that into 1.4.14? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 From noreply at sourceforge.net Mon Jun 15 12:37:36 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 15 Jun 2009 10:37:36 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2802895 ] Enforce C locale usage for parsing text output Message-ID: Patches item #2802895, was opened at 2009-06-08 14:29 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: Enforce C locale usage for parsing text output Initial Comment: Many plugins rely on parsing text output. But the formatting of this output varies according to the current system locale, making it quite fragile. It was already reported for instance in https://sourceforge.net/tracker/index.php?func=detail&aid=1433114&group_id=29880&atid=397597 The attached patch, contributed former mandriva package maintainer Oden Eriksson, enforces the use of C locale for all plugins, fixing the issue. ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2009-06-15 12:37 Message: This patch would eliminate the locale specific output generated by most plugins; that's not an option, sorry. Therefore, we can only accept patches which enforce the C locale specifically for the execution of external commands (as in #1433114). ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-06-15 11:53 Message: any chance to get that into 1.4.14? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2802895&group_id=29880 From hir3npatel at gmail.com Mon Jun 15 14:42:19 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Mon, 15 Jun 2009 14:42:19 +0200 Subject: [Nagiosplug-devel] FW: Nagiosplug-devel Digest, Vol 37, Issue 6 In-Reply-To: References: Message-ID: <4A3641AB.6080703@gmail.com> Mark Mathieson wrote: > Check via unauthenticated proxy: > --- > # ./check_http -vvv -I 192.168.0.8 -p 3128 -H www.google.com -u http://www.google.com/index.html > > GET http://www.google.com/index.html HTTP/1.0 > User-Agent: check_http/v2053 (nagios-plugins 1.4.13) > Connection: close > Host: www.google.com:3128 > > http://192.168.0.8:3128http://www.google.com/index.html is 826 characters > [snip body] > > HTTP OK - HTTP/1.0 302 Moved Temporarily - 0.332 second response time |time=0.332021s;;;0.000000 size=826B;;;0 > --- > > Check via authenticated proxy (details provided for //) > --- > # ./check_http -vvv -I -p 8081 -a : -H www.google.com -u http://www.google.com/index. > > GET http://www.google.com/index.html HTTP/1.0 > User-Agent: check_http/v2053 (nagios-plugins 1.4.13) > Connection: close > Host: www.google.com:8081 > Authorization: Basic bGRhcDpsZGFwcXVlcnk= > CRITICAL - Socket timeout after 10 seconds > --- > > Any thoughts? I think the problem is that the -a switch is a reference to authentication on the Host only. Not sure how to pass authentication to the proxy. > > Note also that I am checking from the Nagios box itself, as I am trying to determine functionality of the web access, rather than from the W2K3 server that acts as the proxy. I have not gotten a chance to test this so I won't comment. on a side note, I am interested in having a look at the curl library to see what's involved in moving to using it if the advantages are great. From hir3npatel at gmail.com Mon Jun 15 14:44:52 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Mon, 15 Jun 2009 14:44:52 +0200 Subject: [Nagiosplug-devel] check_icmp RTA calculation issue In-Reply-To: <1245050857.15418.6.camel@de101315> References: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> <4A34E1EA.6010507@gmail.com> <1245050857.15418.6.camel@de101315> Message-ID: <4A364244.8020702@gmail.com> matthias eble wrote: >> --- plugins-root/check_icmp.c 2009-06-12 09:43:54.000000000 +0200 >> +++ /tmp/check_icmp.c 2009-06-14 13:37:34.000000000 +0200 >> @@ -1035,7 +1035,7 @@ >> if(!early) early = &prog_start; >> >> /* if early > later we return 0 so as to indicate a timeout */ >> - if(early->tv_sec > early->tv_sec || >> + if(early->tv_sec > later->tv_sec || >> (early->tv_sec == later->tv_sec && early->tv_usec > later->tv_usec)) >> { >> return 0; > > I committed the change to git yesterday. > Thanks to both of you. > As a sidenote, fixing the clock issue would still be a good idea. > excuse my ignorance, which clock issue would you be referring to here? From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jun 15 15:18:48 2009 From: matthias.eble at mailing.kaufland-informationssysteme.com (matthias eble) Date: Mon, 15 Jun 2009 15:18:48 +0200 Subject: [Nagiosplug-devel] check_icmp RTA calculation issue In-Reply-To: <4A364244.8020702@gmail.com> References: <1EF3A7C1CC906644B87818682663D48D0695F92897@wpitex02.it.phoenix.wuerth.com> <4A34E1EA.6010507@gmail.com> <1245050857.15418.6.camel@de101315> <4A364244.8020702@gmail.com> Message-ID: <1245071928.15418.9.camel@de101315> > > As a sidenote, fixing the clock issue would still be a good idea. > > > excuse my ignorance, which clock issue would you be referring to here? I just meant fixing the system clock issues his system shows up. Matthias From noreply at sourceforge.net Tue Jun 16 15:53:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jun 2009 13:53:38 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1939578 ] check_jabber: Always returns WARNING with Openfire server. Message-ID: Bugs item #1939578, was opened at 2008-04-10 19:20 Message generated for change (Comment added) made by mmahut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1939578&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Buchbinder (gdrago23) Assigned to: Nobody/Anonymous (nobody) Summary: check_jabber: Always returns WARNING with Openfire server. Initial Comment: check_jabber always returns WARNING when run against an Openfire Jabber server. It may do so against other servers, but I have no way of checking that. Running check_jabber -v with no -e, -A or -a arguments shows that it expects the string " References: Message-ID: <200906161552.33224.waja@cyconet.org> Hi, On Monday 15 June 2009 12:37:36 SourceForge.net wrote: > Many plugins rely on parsing text output. But the formatting of this output > varies according to the current system locale, making it quite fragile. It > was already reported for instance in > https://sourceforge.net/tracker/index.php?func=detail&aid=1433114&group_id= >29880&atid=397597 > > The attached patch, contributed former mandriva package maintainer Oden > Eriksson, enforces the use of C locale for all plugins, fixing the issue. > > ---------------------------------------------------------------------- > > >Comment By: Holger Wei? (hweiss) > > Date: 2009-06-15 12:37 > > Message: > This patch would eliminate the locale specific output generated by most > plugins; that's not an option, sorry. Therefore, we can only accept patches > which enforce the C locale specifically for the execution of external > commands (as in #1433114). wasn't there any discussion about localized output of the plugins? I thought there was, but can't find it anymore in my archives. We have actually one open bug[1] and a closed one[2] caused by localization. Thanks and with kind regards, Jan. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531716 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509359 -- 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 Sun Jun 21 15:18:39 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Sun, 21 Jun 2009 15:18:39 +0200 Subject: [Nagiosplug-devel] plans to use curl for http Message-ID: <4A3E332F.2050407@gmail.com> I had a brief look at the curl library, they offer two modes of using the library, easy and multi. multi supporting threads, which we wouldn't use for a plugin right? I'd like to begin having a look at a new HTTP plugin using curl's easy mode, but wanted to hear what the list/developers think about this first. From holger at CIS.FU-Berlin.DE Sun Jun 21 17:46:06 2009 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sun, 21 Jun 2009 17:46:06 +0200 Subject: [Nagiosplug-devel] plans to use curl for http In-Reply-To: <4A3E332F.2050407@gmail.com> References: <4A3E332F.2050407@gmail.com> Message-ID: <20090621154606.GS51876385@CIS.FU-Berlin.DE> * Hiren Patel [2009-06-21 15:18]: > I had a brief look at the curl library, they offer two modes of using > the library, easy and multi. multi supporting threads [...] You can use either interface in a multi-threaded program, the difference is that the "multi" interface allows for multiplexing the socket I/O (by using select(3) or friends) in single-threaded programs. > which we wouldn't use for a plugin right? The "multi" interface would be useful if a plugin using the new code should ever support checking multiple documents "simultaneously". Otherwise, the "easy" interface should be just fine. Holger From noreply at sourceforge.net Mon Jun 22 09:40:49 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Jun 2009 07:40:49 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2810124 ] HTTP compliance in check_http Message-ID: Patches item #2810124, was opened at 2009-06-22 09:40 Message generated for change (Tracker Item Submitted) made by rakhun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Henrik Nilsson (rakhun) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP compliance in check_http Initial Comment: check_http v1.4.13.138.g9eab.dirty (nagios-plugins 1.4.13) Example plugin commandline: plugins/check_http -I http1-0server.com Tested on: Fedora 10, i686 with compiler gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Originally the plugins sends the "Connection: close" in all cases, while only HTTP/1.1 supports it (HTTP/1.0 has this behaviour by default, not supporting keep-alive), the patch makes it use "Connection: close" only when using HTTP/1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 From noreply at sourceforge.net Mon Jun 22 13:45:53 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Jun 2009 11:45:53 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2810124 ] HTTP compliance in check_http Message-ID: Patches item #2810124, was opened at 2009-06-22 09:40 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Henrik Nilsson (rakhun) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP compliance in check_http Initial Comment: check_http v1.4.13.138.g9eab.dirty (nagios-plugins 1.4.13) Example plugin commandline: plugins/check_http -I http1-0server.com Tested on: Fedora 10, i686 with compiler gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Originally the plugins sends the "Connection: close" in all cases, while only HTTP/1.1 supports it (HTTP/1.0 has this behaviour by default, not supporting keep-alive), the patch makes it use "Connection: close" only when using HTTP/1.1 ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2009-06-22 13:45 Message: We heard reports of server configurations which only close the connection after sending the response if "Connection: close" was specified even in the case of HTTP/1.0 requests. Therefore, we didn't limit the use of this header line to HTTP/1.1 requests. Have you seen any HTTP/1.0 server which complains about the header? If so, that would be a server bug, as the HTTP/1.0 standard clearly states that "Unrecognized header fields should be ignored by the recipient" (RFC 1945, 7.1). That said, I wonder whether anyone actually checks a server which cannot handle HTTP/1.1 requests these days. Maybe we should drop HTTP/1.0 support entirely some day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 From noreply at sourceforge.net Mon Jun 22 15:41:43 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Jun 2009 13:41:43 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2810124 ] HTTP compliance in check_http Message-ID: Patches item #2810124, was opened at 2009-06-22 09:40 Message generated for change (Settings changed) made by rakhun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Henrik Nilsson (rakhun) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP compliance in check_http Initial Comment: check_http v1.4.13.138.g9eab.dirty (nagios-plugins 1.4.13) Example plugin commandline: plugins/check_http -I http1-0server.com Tested on: Fedora 10, i686 with compiler gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Originally the plugins sends the "Connection: close" in all cases, while only HTTP/1.1 supports it (HTTP/1.0 has this behaviour by default, not supporting keep-alive), the patch makes it use "Connection: close" only when using HTTP/1.1 ---------------------------------------------------------------------- >Comment By: Henrik Nilsson (rakhun) Date: 2009-06-22 15:41 Message: We have received reports that a proxy bails out when receiving "Connection: close" for HTTP/1.0, however after reading the RFC I agree it is the error of the proxy. ---------------------------------------------------------------------- Comment By: Holger Wei? (hweiss) Date: 2009-06-22 13:45 Message: We heard reports of server configurations which only close the connection after sending the response if "Connection: close" was specified even in the case of HTTP/1.0 requests. Therefore, we didn't limit the use of this header line to HTTP/1.1 requests. Have you seen any HTTP/1.0 server which complains about the header? If so, that would be a server bug, as the HTTP/1.0 standard clearly states that "Unrecognized header fields should be ignored by the recipient" (RFC 1945, 7.1). That said, I wonder whether anyone actually checks a server which cannot handle HTTP/1.1 requests these days. Maybe we should drop HTTP/1.0 support entirely some day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 From noreply at sourceforge.net Mon Jun 22 15:42:51 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 22 Jun 2009 13:42:51 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2810124 ] HTTP compliance in check_http Message-ID: Patches item #2810124, was opened at 2009-06-22 09:40 Message generated for change (Settings changed) made by rakhun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Henrik Nilsson (rakhun) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP compliance in check_http Initial Comment: check_http v1.4.13.138.g9eab.dirty (nagios-plugins 1.4.13) Example plugin commandline: plugins/check_http -I http1-0server.com Tested on: Fedora 10, i686 with compiler gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Originally the plugins sends the "Connection: close" in all cases, while only HTTP/1.1 supports it (HTTP/1.0 has this behaviour by default, not supporting keep-alive), the patch makes it use "Connection: close" only when using HTTP/1.1 ---------------------------------------------------------------------- Comment By: Henrik Nilsson (rakhun) Date: 2009-06-22 15:41 Message: We have received reports that a proxy bails out when receiving "Connection: close" for HTTP/1.0, however after reading the RFC I agree it is the error of the proxy. ---------------------------------------------------------------------- Comment By: Holger Wei? (hweiss) Date: 2009-06-22 13:45 Message: We heard reports of server configurations which only close the connection after sending the response if "Connection: close" was specified even in the case of HTTP/1.0 requests. Therefore, we didn't limit the use of this header line to HTTP/1.1 requests. Have you seen any HTTP/1.0 server which complains about the header? If so, that would be a server bug, as the HTTP/1.0 standard clearly states that "Unrecognized header fields should be ignored by the recipient" (RFC 1945, 7.1). That said, I wonder whether anyone actually checks a server which cannot handle HTTP/1.1 requests these days. Maybe we should drop HTTP/1.0 support entirely some day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2810124&group_id=29880 From nagiosplug-devel at lusis.org Mon Jun 22 19:22:58 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Mon, 22 Jun 2009 13:22:58 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding Message-ID: So I've been attempting to use check_memcached and in the process was cleaning up some invalid perfdata output. I also noticed that the thresholding is somewhat broken. This plugin, like many database plugins, has a hit ratio metric. Hit ratio metrics make the most sense when approcahed from a "warning/critical below X%" (at least in my mind). So if my hit ratio drops below 75%, I want a warning and if it goes below 50% I want a critical. What's the best way to handle this with Nagios::Plugin? Should the logic be done in the script or should it be done in the module itself? John E. Vincent From rich at richhorner.com Mon Jun 22 19:33:07 2009 From: rich at richhorner.com (Richard Edward Horner) Date: Mon, 22 Jun 2009 17:33:07 +0000 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: <7a65a83a0906221033t69222ccbm28421bcc16e4e9a4@mail.gmail.com> I don't write plugins in Perl because I write all of them in BASH but I wrote a single check_value() function that conforms to the threshold and ranges spec and then I include it in all my scripts. If you're working from a Perl module, I suppose you could write a similar function and include it in the module and then just call it from every script. Here's my relevant BASH code if you want to rewrite it in Perl. I'm using 999999999 to represent infinity. You can find more Nagios BASH code at: http://rhosts.net/nagios/ function check_value { # if the range starts with an @, alert if value is inside the range, otherwise alert if value is outside of range INSIDE=`echo "$1" | grep -c '^@'` RANGE=`echo "$1" | sed 's/^@//'` # start is anything left of the colon or 0 # end is anything right of the colon or the whole string if there's no colon or infinity if there is a colon and nothing to the right of it # is there a colon? PARTS=`echo "$RANGE" | awk -F : '{ print NF }'` if [ $PARTS -gt 1 ] ; then START=${RANGE%%:*} END=${RANGE##*:} else START=0 END=$RANGE fi # 4. to specify negative infinity, use "~" if [ "$START" == "~" ] ; then START=-999999999 fi if [ -z "$END" ] ; then END=999999999 fi if [ $START -gt $END ] ; then echo "In threshold START:END, START must be less than or equal to END" range_help fi # if the range starts with an @, alert if value is inside the range, otherwise alert if value is outside of range # all ranges are inclusive of endpoints so we use less than or equal on the inside and just less than on the outside if [ "$INSIDE" -gt 0 ] ; then if [ "$START" -le "$2" -a "$2" -le "$END" ] ; then return 1 fi else if [ "$2" -lt "$START" -o "$END" -lt "$2" ] ; then return 1 fi fi return 0 } # check conditions - yes this is ugly, blame BASH. If you want to blame me, please provide a cleaner way that is as fast or faster check_value "$CRITICAL" "$VALUE" if [ $? -gt 0 ] ; then STATE=$STATE_CRITICAL else check_value "$WARNING" "$VALUE" if [ $? -gt 0 ] ; then STATE=$STATE_WARNING else STATE=$STATE_OK fi fi Rich(ard) On Mon, Jun 22, 2009 at 5:22 PM, John Vincent wrote: > So I've been attempting to use check_memcached and in the process was > cleaning up some invalid perfdata output. I also noticed that the > thresholding is somewhat broken. This plugin, like many database > plugins, has a hit ratio metric. Hit ratio metrics make the most sense > when approcahed from a "warning/critical below X%" (at least in my > mind). So if my hit ratio drops below 75%, I want a warning and if it > goes below 50% I want a critical. > > What's the best way to handle this with Nagios::Plugin? Should the > logic be done in the script or should it be done in the module itself? > > John E. Vincent > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso richhorner.com | rhosts.net | sabayonlinux.org From nagiosplug-devel at lusis.org Mon Jun 22 20:14:09 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Mon, 22 Jun 2009 14:14:09 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: <7a65a83a0906221033t69222ccbm28421bcc16e4e9a4@mail.gmail.com> References: <7a65a83a0906221033t69222ccbm28421bcc16e4e9a4@mail.gmail.com> Message-ID: I've done something similar but in this case the plugin I'm using is already using the Nagios::Plugin perl module from CPAN. I guess I'm trying to determine what Ton or anyone else would consider a best practice in this case. Do I submit a patch to Threshold.pm for handling this scenario or do I do all the annoying work on the existing module? On Mon, Jun 22, 2009 at 1:33 PM, Richard Edward Horner wrote: > I don't write plugins in Perl because I write all of them in BASH but > I wrote a single check_value() function that conforms to the threshold > and ranges spec and then I include it in all my scripts. If you're > working from a Perl module, I suppose you could write a similar > function and include it in the module and then just call it from every > script. Here's my relevant BASH code if you want to rewrite it in > Perl. I'm using 999999999 to represent infinity. You can find more > Nagios BASH code at: > > http://rhosts.net/nagios/ > > function check_value { > ? ? ? ?# if the range starts with an @, alert if value is inside the range, > otherwise alert if value is outside of range > ? ? ? ?INSIDE=`echo "$1" | grep -c '^@'` > ? ? ? ?RANGE=`echo "$1" | sed 's/^@//'` > > ? ? ? ?# start is anything left of the colon or 0 > ? ? ? ?# end is anything right of the colon or the whole string if there's > no colon or infinity if there is a colon and nothing to the right of > it > > ? ? ? ?# is there a colon? > ? ? ? ?PARTS=`echo "$RANGE" | awk -F : '{ print NF }'` > ? ? ? ?if [ $PARTS -gt 1 ] ; then > ? ? ? ? ? ? ? ?START=${RANGE%%:*} > ? ? ? ? ? ? ? ?END=${RANGE##*:} > ? ? ? ?else > ? ? ? ? ? ? ? ?START=0 > ? ? ? ? ? ? ? ?END=$RANGE > ? ? ? ?fi > > ? ? ? ?# 4. to specify negative infinity, use "~" > ? ? ? ?if [ "$START" == "~" ] ; then > ? ? ? ? ? ? ? ?START=-999999999 > ? ? ? ?fi > > ? ? ? ?if [ -z "$END" ] ; then > ? ? ? ? ? ? ? ?END=999999999 > ? ? ? ?fi > > ? ? ? ?if [ $START -gt $END ] ; then > ? ? ? ? ? ? ? ?echo "In threshold START:END, START must be less than or equal to END" > ? ? ? ? ? ? ? ?range_help > ? ? ? ?fi > > ? ? ? ?# if the range starts with an @, alert if value is inside the range, > otherwise alert if value is outside of range > ? ? ? ?# all ranges are inclusive of endpoints so we use less than or equal > on the inside and just less than on the outside > ? ? ? ?if [ "$INSIDE" -gt 0 ] ; then > ? ? ? ? ? ? ? ?if [ "$START" -le "$2" -a "$2" -le "$END" ] ; then > ? ? ? ? ? ? ? ? ? ? ? ?return 1 > ? ? ? ? ? ? ? ?fi > ? ? ? ?else > ? ? ? ? ? ? ? ?if [ "$2" -lt "$START" -o "$END" -lt "$2" ] ; then > ? ? ? ? ? ? ? ? ? ? ? ?return 1 > ? ? ? ? ? ? ? ?fi > ? ? ? ?fi > > ? ? ? ?return 0 > } > > # check conditions - yes this is ugly, blame BASH. If you want to > blame me, please provide a cleaner way that is as fast or faster > check_value "$CRITICAL" "$VALUE" > if [ $? -gt 0 ] ; then > ? ? ? ?STATE=$STATE_CRITICAL > else > ? ? ? ?check_value "$WARNING" "$VALUE" > ? ? ? ?if [ $? -gt 0 ] ; then > ? ? ? ? ? ? ? ?STATE=$STATE_WARNING > ? ? ? ?else > ? ? ? ? ? ? ? ?STATE=$STATE_OK > ? ? ? ?fi > fi > > Rich(ard) > > On Mon, Jun 22, 2009 at 5:22 PM, John Vincent wrote: >> So I've been attempting to use check_memcached and in the process was >> cleaning up some invalid perfdata output. I also noticed that the >> thresholding is somewhat broken. This plugin, like many database >> plugins, has a hit ratio metric. Hit ratio metrics make the most sense >> when approcahed from a "warning/critical below X%" (at least in my >> mind). So if my hit ratio drops below 75%, I want a warning and if it >> goes below 50% I want a critical. >> >> What's the best way to handle this with Nagios::Plugin? Should the >> logic be done in the script or should it be done in the module itself? >> >> John E. Vincent >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge conference! >> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________________ >> Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net >> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >> ::: Please include plugins version (-v) and OS when reporting any issue. >> ::: Messages without supporting info will risk being sent to /dev/null >> > > > > -- > Richard Edward Horner > Engineer / Composer / Electric Guitar Virtuoso > richhorner.com | rhosts.net | sabayonlinux.org > From rich at richhorner.com Mon Jun 22 20:21:13 2009 From: rich at richhorner.com (Richard Edward Horner) Date: Mon, 22 Jun 2009 18:21:13 +0000 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: <7a65a83a0906221033t69222ccbm28421bcc16e4e9a4@mail.gmail.com> Message-ID: <7a65a83a0906221121v180d8c12x2ce1333bf221b817@mail.gmail.com> Understood. Well, while I don't expect my opinion to count for a whole lot, especially since I'm not developing Perl plugins, my thought on patches is that they're always good to have on hand because then ppl can choose whether or not they want to apply them and this whole open source thing is about choice...I think :) Rich(ard) On Mon, Jun 22, 2009 at 6:14 PM, John Vincent wrote: > I've done something similar but in this case the plugin I'm using is > already using the Nagios::Plugin perl module from CPAN. I guess I'm > trying to determine what Ton or anyone else would consider a best > practice in this case. Do I submit a patch to Threshold.pm for > handling this scenario or do I do all the annoying work on the > existing module? > > > On Mon, Jun 22, 2009 at 1:33 PM, Richard Edward > Horner wrote: >> I don't write plugins in Perl because I write all of them in BASH but >> I wrote a single check_value() function that conforms to the threshold >> and ranges spec and then I include it in all my scripts. If you're >> working from a Perl module, I suppose you could write a similar >> function and include it in the module and then just call it from every >> script. Here's my relevant BASH code if you want to rewrite it in >> Perl. I'm using 999999999 to represent infinity. You can find more >> Nagios BASH code at: >> >> http://rhosts.net/nagios/ >> >> function check_value { >> ? ? ? ?# if the range starts with an @, alert if value is inside the range, >> otherwise alert if value is outside of range >> ? ? ? ?INSIDE=`echo "$1" | grep -c '^@'` >> ? ? ? ?RANGE=`echo "$1" | sed 's/^@//'` >> >> ? ? ? ?# start is anything left of the colon or 0 >> ? ? ? ?# end is anything right of the colon or the whole string if there's >> no colon or infinity if there is a colon and nothing to the right of >> it >> >> ? ? ? ?# is there a colon? >> ? ? ? ?PARTS=`echo "$RANGE" | awk -F : '{ print NF }'` >> ? ? ? ?if [ $PARTS -gt 1 ] ; then >> ? ? ? ? ? ? ? ?START=${RANGE%%:*} >> ? ? ? ? ? ? ? ?END=${RANGE##*:} >> ? ? ? ?else >> ? ? ? ? ? ? ? ?START=0 >> ? ? ? ? ? ? ? ?END=$RANGE >> ? ? ? ?fi >> >> ? ? ? ?# 4. to specify negative infinity, use "~" >> ? ? ? ?if [ "$START" == "~" ] ; then >> ? ? ? ? ? ? ? ?START=-999999999 >> ? ? ? ?fi >> >> ? ? ? ?if [ -z "$END" ] ; then >> ? ? ? ? ? ? ? ?END=999999999 >> ? ? ? ?fi >> >> ? ? ? ?if [ $START -gt $END ] ; then >> ? ? ? ? ? ? ? ?echo "In threshold START:END, START must be less than or equal to END" >> ? ? ? ? ? ? ? ?range_help >> ? ? ? ?fi >> >> ? ? ? ?# if the range starts with an @, alert if value is inside the range, >> otherwise alert if value is outside of range >> ? ? ? ?# all ranges are inclusive of endpoints so we use less than or equal >> on the inside and just less than on the outside >> ? ? ? ?if [ "$INSIDE" -gt 0 ] ; then >> ? ? ? ? ? ? ? ?if [ "$START" -le "$2" -a "$2" -le "$END" ] ; then >> ? ? ? ? ? ? ? ? ? ? ? ?return 1 >> ? ? ? ? ? ? ? ?fi >> ? ? ? ?else >> ? ? ? ? ? ? ? ?if [ "$2" -lt "$START" -o "$END" -lt "$2" ] ; then >> ? ? ? ? ? ? ? ? ? ? ? ?return 1 >> ? ? ? ? ? ? ? ?fi >> ? ? ? ?fi >> >> ? ? ? ?return 0 >> } >> >> # check conditions - yes this is ugly, blame BASH. If you want to >> blame me, please provide a cleaner way that is as fast or faster >> check_value "$CRITICAL" "$VALUE" >> if [ $? -gt 0 ] ; then >> ? ? ? ?STATE=$STATE_CRITICAL >> else >> ? ? ? ?check_value "$WARNING" "$VALUE" >> ? ? ? ?if [ $? -gt 0 ] ; then >> ? ? ? ? ? ? ? ?STATE=$STATE_WARNING >> ? ? ? ?else >> ? ? ? ? ? ? ? ?STATE=$STATE_OK >> ? ? ? ?fi >> fi >> >> Rich(ard) >> >> On Mon, Jun 22, 2009 at 5:22 PM, John Vincent wrote: >>> So I've been attempting to use check_memcached and in the process was >>> cleaning up some invalid perfdata output. I also noticed that the >>> thresholding is somewhat broken. This plugin, like many database >>> plugins, has a hit ratio metric. Hit ratio metrics make the most sense >>> when approcahed from a "warning/critical below X%" (at least in my >>> mind). So if my hit ratio drops below 75%, I want a warning and if it >>> goes below 50% I want a critical. >>> >>> What's the best way to handle this with Nagios::Plugin? Should the >>> logic be done in the script or should it be done in the module itself? >>> >>> John E. Vincent >>> >>> ------------------------------------------------------------------------------ >>> Are you an open source citizen? Join us for the Open Source Bridge conference! >>> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. >>> Need another reason to go? 24-hour hacker lounge. Register today! >>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >>> _______________________________________________________ >>> Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net >>> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >>> ::: Please include plugins version (-v) and OS when reporting any issue. >>> ::: Messages without supporting info will risk being sent to /dev/null >>> >> >> >> >> -- >> Richard Edward Horner >> Engineer / Composer / Electric Guitar Virtuoso >> richhorner.com | rhosts.net | sabayonlinux.org >> > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso richhorner.com | rhosts.net | sabayonlinux.org From ton.voon at opsera.com Mon Jun 22 21:42:17 2009 From: ton.voon at opsera.com (Ton Voon) Date: Mon, 22 Jun 2009 20:42:17 +0100 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: On 22 Jun 2009, at 18:22, John Vincent wrote: > So I've been attempting to use check_memcached and in the process was > cleaning up some invalid perfdata output. I also noticed that the > thresholding is somewhat broken. This plugin, like many database > plugins, has a hit ratio metric. Hit ratio metrics make the most sense > when approcahed from a "warning/critical below X%" (at least in my > mind). So if my hit ratio drops below 75%, I want a warning and if it > goes below 50% I want a critical. > > What's the best way to handle this with Nagios::Plugin? Should the > logic be done in the script or should it be done in the module itself? Nagios::Plugin already supports the thresholds defined in the guidelines: http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT So you should already be able to use the threshold routines in N::P. If it doesn't work properly, then that would be a bug. Ton From nagiosplug-devel at lusis.org Mon Jun 22 22:03:51 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Mon, 22 Jun 2009 16:03:51 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: On Mon, Jun 22, 2009 at 3:42 PM, Ton Voon wrote: > > On 22 Jun 2009, at 18:22, John Vincent wrote: > >> So I've been attempting to use check_memcached and in the process was >> cleaning up some invalid perfdata output. I also noticed that the >> thresholding is somewhat broken. This plugin, like many database >> plugins, has a hit ratio metric. Hit ratio metrics make the most sense >> when approcahed from a "warning/critical below X%" (at least in my >> mind). So if my hit ratio drops below 75%, I want a warning and if it >> goes below 50% I want a critical. >> >> What's the best way to handle this with Nagios::Plugin? Should the >> logic be done in the script or should it be done in the module itself? > > Nagios::Plugin already supports the thresholds defined in the guidelines: > http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT > > So you should already be able to use the threshold routines in N::P. > > If it doesn't work properly, then that would be a bug. > > Ton > > Ahh okay. Thanks Ton. I wasn't looking hard enough to find what I needed. I was simply looking at it from a greater than/less than scenario as opposed to being outside a given range. From nagiosplug-devel at lusis.org Mon Jun 22 22:18:48 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Mon, 22 Jun 2009 16:18:48 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: On Mon, Jun 22, 2009 at 4:03 PM, John Vincent wrote: > On Mon, Jun 22, 2009 at 3:42 PM, Ton Voon wrote: >> >> On 22 Jun 2009, at 18:22, John Vincent wrote: >> >>> So I've been attempting to use check_memcached and in the process was >>> cleaning up some invalid perfdata output. I also noticed that the >>> thresholding is somewhat broken. This plugin, like many database >>> plugins, has a hit ratio metric. Hit ratio metrics make the most sense >>> when approcahed from a "warning/critical below X%" (at least in my >>> mind). So if my hit ratio drops below 75%, I want a warning and if it >>> goes below 50% I want a critical. >>> >>> What's the best way to handle this with Nagios::Plugin? Should the >>> logic be done in the script or should it be done in the module itself? >> >> Nagios::Plugin already supports the thresholds defined in the guidelines: >> http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT >> >> So you should already be able to use the threshold routines in N::P. >> >> If it doesn't work properly, then that would be a bug. >> >> Ton >> >> > > Ahh okay. Thanks Ton. I wasn't looking hard enough to find what I > needed. I was simply looking at it from a greater than/less than > scenario as opposed to being outside a given range. > One question that I have regarding these threshold ranges. Should the range definitions be passed as-is to the perfdata output or not? If so, then pnp is at fault for not handling it properly in this case (or I really need to make a custom template to graph it properly.). Currently pnp is breaking on "hits=90%;@30:50;30" due to the format of the warn value. Just trying to figure out where to go with it. From nagiosplug-devel at lusis.org Mon Jun 22 22:20:20 2009 From: nagiosplug-devel at lusis.org (John Vincent) Date: Mon, 22 Jun 2009 16:20:20 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: Nevermind. Sorry for wasting everyone's time. I see that pnp does indeed support it. The problem is mine. On Mon, Jun 22, 2009 at 4:18 PM, John Vincent wrote: > On Mon, Jun 22, 2009 at 4:03 PM, John Vincent wrote: >> On Mon, Jun 22, 2009 at 3:42 PM, Ton Voon wrote: >>> >>> On 22 Jun 2009, at 18:22, John Vincent wrote: >>> >>>> So I've been attempting to use check_memcached and in the process was >>>> cleaning up some invalid perfdata output. I also noticed that the >>>> thresholding is somewhat broken. This plugin, like many database >>>> plugins, has a hit ratio metric. Hit ratio metrics make the most sense >>>> when approcahed from a "warning/critical below X%" (at least in my >>>> mind). So if my hit ratio drops below 75%, I want a warning and if it >>>> goes below 50% I want a critical. >>>> >>>> What's the best way to handle this with Nagios::Plugin? Should the >>>> logic be done in the script or should it be done in the module itself? >>> >>> Nagios::Plugin already supports the thresholds defined in the guidelines: >>> http://nagiosplug.sourceforge.net/developer-guidelines.html#THRESHOLDFORMAT >>> >>> So you should already be able to use the threshold routines in N::P. >>> >>> If it doesn't work properly, then that would be a bug. >>> >>> Ton >>> >>> >> >> Ahh okay. Thanks Ton. I wasn't looking hard enough to find what I >> needed. I was simply looking at it from a greater than/less than >> scenario as opposed to being outside a given range. >> > > One question that I have regarding these threshold ranges. Should the > range definitions be passed as-is to the perfdata output or not? If > so, then pnp is at fault for not handling it properly in this case (or > I really need to make a custom template to graph it properly.). > Currently pnp is breaking on "hits=90%;@30:50;30" due to the format of > the warn value. Just trying to figure out where to go with it. > From dermoth at aei.ca Tue Jun 23 17:26:28 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 23 Jun 2009 11:26:28 -0400 Subject: [Nagiosplug-devel] Best practice for thresholding In-Reply-To: References: Message-ID: <4A40F424.9040809@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/06/09 01:22 PM, John Vincent wrote: > So I've been attempting to use check_memcached and in the process was > cleaning up some invalid perfdata output. I also noticed that the > thresholding is somewhat broken. This plugin, like many database > plugins, has a hit ratio metric. Hit ratio metrics make the most sense > when approcahed from a "warning/critical below X%" (at least in my > mind). So if my hit ratio drops below 75%, I want a warning and if it > goes below 50% I want a critical. > > What's the best way to handle this with Nagios::Plugin? Should the > logic be done in the script or should it be done in the module itself? A bit off-topic but if you're interested here's the plugin I use (and wrote) for checking my memcached servers. It's written in PHP, and monitor primarily the evictions (by parsing the performance data string from previous check) and cache ratio. http://solaris.beaubien.net/~dermoth/pages/nagios/plugins.php - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKQPQk6dZ+Kt5BchYRApFxAJ4y5vj6QU6UTvRp8XaN+fpjbNquEACgtk4H KBFr/5T/6UV6xmeLbJV2qlw= =FtN3 -----END PGP SIGNATURE----- From hir3npatel at gmail.com Wed Jun 24 10:20:59 2009 From: hir3npatel at gmail.com (Hiren Patel) Date: Wed, 24 Jun 2009 10:20:59 +0200 Subject: [Nagiosplug-devel] plans to use curl for http In-Reply-To: <20090621154606.GS51876385@CIS.FU-Berlin.DE> References: <4A3E332F.2050407@gmail.com> <20090621154606.GS51876385@CIS.FU-Berlin.DE> Message-ID: <4A41E1EB.5070101@gmail.com> Holger Wei? wrote: > * Hiren Patel [2009-06-21 15:18]: >> I had a brief look at the curl library, they offer two modes of using >> the library, easy and multi. multi supporting threads [...] > > You can use either interface in a multi-threaded program, the difference > is that the "multi" interface allows for multiplexing the socket I/O (by > using select(3) or friends) in single-threaded programs. > ah okay. >> which we wouldn't use for a plugin right? > > The "multi" interface would be useful if a plugin using the new code > should ever support checking multiple documents "simultaneously". > Otherwise, the "easy" interface should be just fine. > okay, I plan to start with a plugin for HTTP using curl this weekend, I will post the status as it progresses. let me know if there are concerns, > Holger > From lists at wyraz.de Wed Jun 24 15:45:01 2009 From: lists at wyraz.de (Michael Wyraz) Date: Wed, 24 Jun 2009 15:45:01 +0200 Subject: [Nagiosplug-devel] NRPE Protocol Message-ID: <4A422DDD.6080504@wyraz.de> Hi, because I wanted to integrate some of our own monitoring tasks to nagios, I spent some time with the NRPE protocol. Since it's almost impossible to find some documentation, I gathered my informations from the source. Here's what I found out about it: - any numbers are stored in big-endian notation (highest bytes first) - a packet consists of exactly 1036 Bytes - 2 byte integer: version of the protocol (currently 1,2,3) - 2 byte integer: type of the packet (1=request, 2=response) - 4 byte long integer: crc32 checksum of the message - 2 byte integer: return code of the remote command (in requests it's filled with a random number) - 1024 byte data: the command or response text, filled with zero-bytes - 2 byte of garbage: this is because the c structure is sent "as it is" over the wire. When creating messages, it's fine to set it to zero. - the crc32 checksum is calculated from the whole message (including the 2 bytes of garbage). the 4 bytes reserved for the crc are set to zero for calculation the crc. The default crc32 algorithm is used. Additionally the communication may be secured by ssl (anonymous dh). This fact is well documented ;-) SSLv3 is used as Protocol. The cipher suite used is one of: - SSL_DH_anon_WITH_RC4_128_MD5 - SSL_DH_anon_WITH_RC4_128_MD5 - SSL_DH_anon_WITH_3DES_EDE_CBC_SHA - SSL_DH_anon_WITH_DES_CBC_SHA - SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 - SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA (This information is from a java implementation of the server and might be wrong - but for me it works) In my opinion the protocol has a few disadvantages: - the "garbage" is part of the protocol (i.e. things will not work without) but it is only there because of an implementation bug - there's encryption but no kind of authentication - the payload size is fixed to 1024 bytes 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). Regards, Michael. From charlie.reddington at gmail.com Wed Jun 24 19:03:19 2009 From: charlie.reddington at gmail.com (Charlie Reddington) Date: Wed, 24 Jun 2009 12:03:19 -0500 Subject: [Nagiosplug-devel] Having trouble with check_ntp_devel Message-ID: <5545952F-2CFF-48D6-BC94-D03EC3BA7240@gmail.com> Hi All, Thanks for making this plugin, it works great. I do have a problem with one host, and I'm trying to trouble shoot the problem, but I could use a bit of insight on how the plugin works. We are on a linux box (Fedora Core 6 Zod), I know it's old as hell. We are running kernel 2.6.22.14-72.fc6. I can successfully use ntp on the server. I can connect to the remote time server we have, and it syncs fine. I reach out on udp port 123. When I try to use the plugin to check this, I get the following on the CLI. ./check_ntp_time -vvv -H 172.16.12.87 -w 1 -c 2 Found 1 peers to check sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 NTP CRITICAL: No response from NTP server And in nagios, it shows up as. NTP CRITICAL: No response from NTP server As for ntpd running, I have in my /etc/ntp.conf the above listed server. It is running successfully. Is there anything I'm missing here? I was thinking that perhaps this check was reaching out on a differnt protocol or something, or a differnt port? I've done a tcpdump port 123 and when I run the check manually we aren't seeing anything at all. tcpdump port 123 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel Also I think the -p option is broken.... I've used -p 123 and -- port=123 and it shows as a unrecognized option. ./nagios-plugs/check_ntp_time -vvv --p=123 -H 172.16.12.87 -w 1 -c 2 ./nagios-plugs/check_ntp_time: unrecognized option `--p=123' Usage: check_ntp_time -H [-w ] [-c ] [-v verbose] ./nagios-plugs/check_ntp_time -vvv -p 123 -H 172.16.12.87 -w 1 -c 2 ./nagios-plugs/check_ntp_time: invalid option -- p Usage: check_ntp_time -H [-w ] [-c ] [-v verbose] ./nagios-plugs/check_ntp_time -P 123 -H 172.16.12.87 -w 1 -c 2 ./nagios-plugs/check_ntp_time: invalid option -- P Usage: check_ntp_time -H [-w ] [-c ] [-v verbose] ./nagios-plugs/check_ntp_time --port=123 -H 172.16.12.87 -w 1 -c 2 ./nagios-plugs/check_ntp_time: invalid option -- port Usage: check_ntp_time -H [-w ] [-c ] [-v verbose] ./nagios-plugs/check_ntp_time -H 172.16.12.87 -w 1 -c 2 NTP CRITICAL: No response from NTP server Thanks for any help, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu Jun 25 12:57:45 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 25 Jun 2009 06:57:45 -0400 Subject: [Nagiosplug-devel] Having trouble with check_ntp_devel In-Reply-To: <5545952F-2CFF-48D6-BC94-D03EC3BA7240@gmail.com> References: <5545952F-2CFF-48D6-BC94-D03EC3BA7240@gmail.com> Message-ID: <4A435829.705@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/06/09 01:03 PM, Charlie Reddington wrote: > Hi All, > > Thanks for making this plugin, it works great. > > I do have a problem with one host, and I'm trying to trouble shoot the > problem, but I could use a bit of insight on how the plugin works. > > We are on a linux box (Fedora Core 6 Zod), I know it's old as hell. We > are running kernel 2.6.22.14-72.fc6. > > I can successfully use ntp on the server. I can connect to the remote > time server we have, and it syncs fine. I reach out on udp port 123. > > When I try to use the plugin to check this, I get the following on the CLI. > > ./check_ntp_time -vvv -H 172.16.12.87 -w 1 -c 2 > Found 1 peers to check > sending request to peer 0 > re-sending request to peer 0 > re-sending request to peer 0 > re-sending request to peer 0 > re-sending request to peer 0 > re-sending request to peer 0 > re-sending request to peer 0 > NTP CRITICAL: No response from NTP server Could it be a firewall/access restriction issue? ntp sends from port 123, while check_ntp* needs to use higher ports because: 1. normal users can't bind to ports <1024 2. if ntp is running, even root can't bind to 123 Please try the commands below; is one of them fail that's the issue. Run them as root and *shut down the local ntp server* first... ntpdate -q 172.16.12.87 ntpdate 172.16.12.87 - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKQ1gp6dZ+Kt5BchYRAoxAAKDVIy/qlAqGXPNw9wzgclw8kWaOgQCeLdLa BvZ4R0gZGfsyVu9ojNNQw0w= =srDU -----END PGP SIGNATURE----- From diego at etszone.com Fri Jun 26 00:18:01 2009 From: diego at etszone.com (Diego Ongaro) Date: Thu, 25 Jun 2009 17:18:01 -0500 Subject: [Nagiosplug-devel] Performance Data for check_asterisk Message-ID: <4A43F799.2090503@etszone.com> Hi all, I modified the contrib/check_asterisk.pl plugin to output performance data in the standard format. If this change is acceptable, please commit it to the plugins repo. The patch is attached (and hopefully the tabs make it through OK). Diego Ongaro ETSZONE -------------- next part -------------- A non-text attachment was scrubbed... Name: check_asterisk.pl.diff Type: text/x-diff Size: 782 bytes Desc: not available URL: From noreply at sourceforge.net Fri Jun 26 08:53:08 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 26 Jun 2009 06:53:08 +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 (Tracker Item Submitted) 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: None Group: Release (specify) Status: Open Resolution: None Priority: 5 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 waja at cyconet.org Fri Jun 26 09:02:37 2009 From: waja at cyconet.org (Jan Wagner) Date: Fri, 26 Jun 2009 09:02:37 +0200 Subject: [Nagiosplug-devel] Performance Data for check_asterisk In-Reply-To: <4A43F799.2090503@etszone.com> References: <4A43F799.2090503@etszone.com> Message-ID: <200906260902.37752.waja@cyconet.org> Hi Diego, On Friday 26 June 2009 00:18:01 Diego Ongaro wrote: > I modified the contrib/check_asterisk.pl plugin to output performance > data in the standard format. If this change is acceptable, please commit > it to the plugins repo. > > The patch is attached (and hopefully the tabs make it through OK). maybe you want to commit it at https://sourceforge.net/tracker/?group_id=29880&atid=397599 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 Tue Jun 30 20:48:28 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 30 Jun 2009 18:48:28 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2814784 ] perf data for check_asterisk Message-ID: Patches item #2814784, was opened at 2009-06-30 13:48 Message generated for change (Tracker Item Submitted) made by ongardie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2814784&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: Perf data Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ongardie (ongardie) Assigned to: Nobody/Anonymous (nobody) Summary: perf data for check_asterisk Initial Comment: Patch against Plugin Version (-V output): plugin does not have -V, but this is on the one and only verison to date Plugin Name: contrib/check_asterisk.pl Example Plugin Commandline: ./check_asterisk.pl -m mgr -h 127.0.0.1 -u nagios -p yourpassword --warning SIP=35,IAX2=35 --critical SIP=40,IAX2=40 Tested on operating system: Linux 2.6.9 Tested on architecture: i386 Tested with compiler: Perl v5.8.5 I modified the contrib/check_asterisk.pl plugin to output performance data in the standard format. If this change is acceptable, please commit it to the plugins repo. I see the message that says to "contact the respective developer directly...for plugins inside the contrib directory", but I couldn't find any information about where this plugin comes from. Sorry. Diego Ongaro ETSZONE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2814784&group_id=29880 From diego at etszone.com Tue Jun 30 20:51:20 2009 From: diego at etszone.com (Diego Ongaro) Date: Tue, 30 Jun 2009 13:51:20 -0500 Subject: [Nagiosplug-devel] Performance Data for check_asterisk In-Reply-To: <200906260902.37752.waja@cyconet.org> References: <4A43F799.2090503@etszone.com> <200906260902.37752.waja@cyconet.org> Message-ID: <4A4A5EA8.1070108@etszone.com> Jan Wagner wrote: > On Friday 26 June 2009 00:18:01 Diego Ongaro wrote: >> I modified the contrib/check_asterisk.pl plugin to output performance >> data in the standard format. If this change is acceptable, please commit >> it to the plugins repo. >> >> The patch is attached (and hopefully the tabs make it through OK). > > maybe you want to commit it at > https://sourceforge.net/tracker/?group_id=29880&atid=397599 Thanks, Jan. For those interested, I've created this entry in the tracker: https://sourceforge.net/tracker/?func=detail&aid=2814784&group_id=29880&atid=397599 -Diego