From noreply at sourceforge.net Mon Aug 4 16:53:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2008 14:53:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 08:04 Message generated for change (Comment added) made by tuxlife You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 16:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Mon Aug 4 18:07:34 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2008 16:07:34 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) >Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Tue Aug 5 10:09:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2008 08:09:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 08:04 Message generated for change (Comment added) made by tuxlife You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 10:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 18:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 16:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From dermoth at aei.ca Wed Aug 6 04:50:19 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 05 Aug 2008 22:50:19 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> Message-ID: <4899116B.7090908@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/07/08 06:13 AM, Ton Voon wrote: > On 29 Jun 2008, at 23:53, Thomas Guyot-Sionnest wrote: > >> Cool, Ton! >> >> If I can find some free time I'll test it on my tinderbox and >> workstation. >> >> We should also encourage tinderbox owners without libtap to use this >> config option. > > I had set this as an included option for tinderbox builds (tools/ > tinderbox_builds), but it caused breakages at the make stage. Partly > due to not linking libraries correctly, but HP/UX was complaining > about the libtap code. > > So I've removed the --enable-libtap from tinderbox build. > Unfortunately, I haven't had time to get the old behaviour restored, > so now no libtap testing is run. Want to see if this stabilises the > builds first. Hi Ton, I just tested it on a server without tap... The problem seems to be a simple dependency - you need to build tap before the actual tests... Although I doubt the way you did it will use GL libraries... The problem with tap is that although it's using gnulib it's missing some modules to work on some servers. I was thinking of including it directly with nagiosplug's build system, i.e. in tap/. The dependency tree with Tap should look like this: +----+ +-----+ +-----+ +---------+ | gl |--->| tap |--->| lib |--->| plugins | +----+ +-----+ +-----+ +---------+ Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImRFr6dZ+Kt5BchYRAi5dAKCGa3bxOcicCqv8HOJyyh4szQ0K4wCg2T8N 8NO7FNl8Cj986GViuqnua00= =E7qc -----END PGP SIGNATURE----- From mharris at nmsu.edu Thu Aug 7 16:59:44 2008 From: mharris at nmsu.edu (Michael Harris) Date: Thu, 7 Aug 2008 08:59:44 -0600 (MDT) Subject: [Nagiosplug-devel] check_http patch Message-ID: <21856.128.123.16.247.1218121184.squirrel@www.jeffharris.net> Hi all, Here's a patch I wrote for the check_http plugin. We were having problems getting 301s back instead of 200s from our VMware servers. This patch re-structures the HTTP 1.1 headers, which fixed the problem. -Michael Harris ^_^ -------------------- http://www.shiftycow.net -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http1.1.patch Type: application/octet-stream Size: 1267 bytes Desc: not available URL: From caronc at navcanada.ca Thu Aug 7 19:34:14 2008 From: caronc at navcanada.ca (Caron, Chris) Date: Thu, 7 Aug 2008 13:34:14 -0400 Subject: [Nagiosplug-devel] Remote execution of plugins reporting local results Message-ID: <474534909BE4064E853161350C47578E0BB3B6F3@ncrmail1.corp.navcan.ca> Hi Everyone, I'm new to Nagios as well as this community, and am having a small issue with the development of a 'Nagios plugin'. All existing plug-ins I use, as well as the ones found on NagiosExchange seem to work great... however I wrote a simple script following the rules (or so I think) which outputs perfectly on my Nagios console. The problem is; Nagios seems to be executing this script locally and placing its result on each host (on the web interface). The tool I run is fairly complicated, but if I strip out all the content and do a simple file count in a directory, I get the same results. Assume 3 hosts: HostA, HostB, and HostC where HostA runs the web application. The output on all 3 hosts always pertains to what is on HostA. Essentially 'Nagios' is 'lying' :-) to me when it reports information on other hosts (but for this plugin only). To reproduce this (the code is significantly reduced to avoid making this email larger then it already is), just make a simple check_test plugin (in the plugin dir) with this content: #!/bin/sh # # ## Plugin for Nagios to tell if it lies :) # Usage: ./check_test STATE_OK=0 COUNT=$(ls /tmp | wc -l) MESG="OK - $COUNT" EXITSTATUS=$STATE_OK echo "$MESG" exit $EXITSTATUS Here is your command information: define command{ command_name check_test command_line /usr/lib/nagios/plugins/check_test } Here is the service information (update the host x3): # Service definition define service{ # Name of service template to use use generic-service host_name node01.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } define service{ # Name of service template to use use generic-service host_name node02.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } define service{ # Name of service template to use use generic-service host_name node03.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } The output from the above on my machine reports 'OK - 14' on each and every host in Nagios. There are in-fact '14' files on Node 01 (host A as per the example above), but there is a completely different file count on the other 2 nodes. Why does Nagios fill in the results from the host using the 'www' package in replace of all other hosts for 'only' this plugin? Or... to rephrase the question: what am I doing wrong? :-) Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at profitability.net Thu Aug 7 19:41:16 2008 From: andrew at profitability.net (Andrew Cruse) Date: Thu, 7 Aug 2008 13:41:16 -0400 Subject: [Nagiosplug-devel] Remote execution of plugins reporting localresults In-Reply-To: <474534909BE4064E853161350C47578E0BB3B6F3@ncrmail1.corp.navcan.ca> Message-ID: <05cc01c8f8b4$cb500580$800101df@andrew2> All you're doing there is checking for the number of files in /tmp on your Nagios server with all three checks. If you need those checks to run on other servers, you'll need to investigate something like NRPE, check_by_ssh, or any of the other remote check tools available. Andrew _____ From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of Caron, Chris Sent: Thursday, August 07, 2008 1:34 PM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] Remote execution of plugins reporting localresults Hi Everyone, I'm new to Nagios as well as this community, and am having a small issue with the development of a 'Nagios plugin'. All existing plug-ins I use, as well as the ones found on NagiosExchange seem to work great. however I wrote a simple script following the rules (or so I think) which outputs perfectly on my Nagios console. The problem is; Nagios seems to be executing this script locally and placing its result on each host (on the web interface). The tool I run is fairly complicated, but if I strip out all the content and do a simple file count in a directory, I get the same results. Assume 3 hosts: HostA, HostB, and HostC where HostA runs the web application. The output on all 3 hosts always pertains to what is on HostA. Essentially 'Nagios' is 'lying' :-) to me when it reports information on other hosts (but for this plugin only). To reproduce this (the code is significantly reduced to avoid making this email larger then it already is), just make a simple check_test plugin (in the plugin dir) with this content: #!/bin/sh # # ## Plugin for Nagios to tell if it lies :) # Usage: ./check_test STATE_OK=0 COUNT=$(ls /tmp | wc -l) MESG="OK - $COUNT" EXITSTATUS=$STATE_OK echo "$MESG" exit $EXITSTATUS Here is your command information: define command{ command_name check_test command_line /usr/lib/nagios/plugins/check_test } Here is the service information (update the host x3): # Service definition define service{ # Name of service template to use use generic-service host_name node01.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } define service{ # Name of service template to use use generic-service host_name node02.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } define service{ # Name of service template to use use generic-service host_name node03.rhc1 service_description Test is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 120 notification_period 24x7 notification_options w,u,c,r check_command check_test } The output from the above on my machine reports 'OK - 14' on each and every host in Nagios. There are in-fact '14' files on Node 01 (host A as per the example above), but there is a completely different file count on the other 2 nodes. Why does Nagios fill in the results from the host using the 'www' package in replace of all other hosts for 'only' this plugin? Or. to rephrase the question: what am I doing wrong? :-) Chris No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.12/1597 - Release Date: 8/7/2008 5:54 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at ena.com Thu Aug 7 19:50:09 2008 From: marc at ena.com (Marc Powell) Date: Thu, 7 Aug 2008 12:50:09 -0500 Subject: [Nagiosplug-devel] Remote execution of plugins reporting localresults Message-ID: <5A4AE2E1A3A86C4DA672C6ED903343EF01237E@misex03.ena.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel- > bounces at lists.sourceforge.net] On Behalf Of Caron, Chris > Sent: Thursday, August 07, 2008 12:34 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Remote execution of plugins reporting localresults > > Hi Everyone, > > > > I'm new to Nagios as well as this community, and am having a small issue with > the development of a 'Nagios plugin'. Hello! > The tool I run is fairly complicated, but if I strip out all the content and > do a simple file count in a directory, I get the same results. Assume 3 hosts: > HostA, HostB, and HostC where HostA runs the web application. The output on > all 3 hosts always pertains to what is on HostA. Essentially 'Nagios' is > 'lying' :-) to me when it reports information on other hosts (but for this > plugin only). Nagios doesn't lie, of course... HostA is the host running nagios, isn't it? > #!/bin/sh > > # > > # ## Plugin for Nagios to tell if it lies :) > Simple indeed. > Here is your command information: > command_line /usr/lib/nagios/plugins/check_test Ok > Here is the service information (update the host x3): > > # Service definition > > define service{ > > # Name of service template to use > > use generic-service > > host_name node01.rhc1 > check_command check_test > > } > > define service{ > > # Name of service template to use > > use generic-service > > host_name node02.rhc1 > check_command check_test > > } > > define service{ > > # Name of service template to use > > use generic-service > > host_name node03.rhc1 > check_command check_test > > } > The output from the above on my machine reports 'OK - 14' on each and every > host in Nagios. There are in-fact '14' files on Node 01 (host A as per the > example above), but there is a completely different file count on the other 2 > nodes. Why does Nagios fill in the results from the host using the 'www' > package in replace of all other hosts for 'only' this plugin? Or... to rephrase > the question: what am I doing wrong? :-) How are you telling nagios that it's supposed to 'connect' to the remote machines? How is nagios to know how to do that (telnet? ssh? rpc? Other?). Nagios always runs plugins on the machine nagios is running on. Always. Either the plugin itself needs to know how to connect to the remote hosts and 'do it's thing' or you need to use a wrapper to do that for you. Common wrappers are NRPE and check-by-ssh for example. They contain the knowledge of how to connect to remote machines and run plugins installed there, returning the results back to nagios. -- Marc From dermoth at aei.ca Fri Aug 8 03:10:21 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 07 Aug 2008 21:10:21 -0400 Subject: [Nagiosplug-devel] check_http patch In-Reply-To: <21856.128.123.16.247.1218121184.squirrel@www.jeffharris.net> References: <21856.128.123.16.247.1218121184.squirrel@www.jeffharris.net> Message-ID: <489B9CFD.2080900@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/08 10:59 AM, Michael Harris wrote: > Hi all, > Here's a patch I wrote for the check_http plugin. We were having > problems getting 301s back instead of 200s from our VMware servers. This > patch re-structures the HTTP 1.1 headers, which fixed the problem. Thanks for the patch; I'll commit it... FYI there's a patch I wrote in the bugtracker that makes check_http perform thresholds checks on 3xx when they're accepted as ok. I never committed it because I think we should rather refactor it a little bit so that all checks are preformed, instead of heaving some kind of undocumented predecence between the various checks check_http can perform. I should definitely take some time and fix it once and for good... - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIm5z96dZ+Kt5BchYRAmjAAKDARN4OyDCazKEBtpq7XQ7amD3XzQCfetGf XVaXZAphf4/iJNC8/22IJpw= =p9ar -----END PGP SIGNATURE----- From jmernin at tssg.org Mon Aug 11 20:00:59 2008 From: jmernin at tssg.org (James Mernin) Date: Mon, 11 Aug 2008 19:00:59 +0100 Subject: [Nagiosplug-devel] check_dns issue Message-ID: <006d01c8fbdc$361b8810$2adc250a@inishdalla> I have a technical query/suggestion regarding the check_dns plugin that comes with nagios-plugins-1.4.12. Is this mailing list the correct place to post my comments or is there a forum where I can post them? Many thanks, -- James Mernin Senior Software Engineer, Telecommunications Software & Systems Group, Waterford Institute of Technology, Waterford, Ireland. +353 (0)51 845694 | mailto:jmernin at tssg.org | http://www.tssg.org | http://www.wit.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Mon Aug 11 21:54:28 2008 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 11 Aug 2008 20:54:28 +0100 Subject: [Nagiosplug-devel] check_dns issue In-Reply-To: <006d01c8fbdc$361b8810$2adc250a@inishdalla> References: <006d01c8fbdc$361b8810$2adc250a@inishdalla> Message-ID: <8DC6CD3D-D0C3-439A-ADA0-487956F78A8B@altinity.com> James, On 11 Aug 2008, at 19:00, James Mernin wrote: > I have a technical query/suggestion regarding the check_dns plugin > that comes with nagios-plugins-1.4.12. Is this mailing list the > correct place to post my comments or is there a forum where I can > post them? This is the right place for technical discussions. Fire away! Ton From jmernin at tssg.org Mon Aug 11 22:31:59 2008 From: jmernin at tssg.org (James Mernin) Date: Mon, 11 Aug 2008 21:31:59 +0100 Subject: [Nagiosplug-devel] check_dns issue Message-ID: <001401c8fbf1$4e51e860$0a00a8c0@inishdalla> My Configuration I would like to use the check_dns plugin (that is included in nagios-plugins-1.4.12) to verify both forward and reverse DNS lookups for one of our domains. I am reliably informed that since we don't actually own the IP space where our servers reside, we have only been given partial control over the DNS setup. As a result, we get somewhat unusual responses from a straightforward (reverse) nslookup on some of our IP addresses. Let me elaborate: # nslookup XXX.XXX.XXX.XXX Server: AAA.BBB.CCC.DDD Non-authoritative answer: XXX.XXX.X.XXX.in-addr.arpa canonical name = XXX.XXX-XXX.XXX.X.XXX.in-addr.arpa. XXX.XXX-XXX.XXX.X.XXX.in-addr.arpa name = host.mydomain.com. Authoritative answers can be found from: .... .... .... # The Problem When I use the check_dns plugin to test this reverse lookup, it seems to return a list of 2 comma-separated matches for the hostname, and this makes it very messy to write a clean nagios command based around check_dns. Looking at the source (check_dns.c) I see that on line 135, it is matching any line of output from the nslookup response that contains the string "name = " and appending this to a list of host names associated with this IP address. Proposed Solution I have worked around this problem by modifying check_dns.c as follows: $ diff check_dns.old check_dns.c 135c135 < if ((temp_buffer = strstr (chld_out.line[i], "name = "))) --- > if ((temp_buffer = strstr (chld_out.line[i], "name = ")) && (NULL == strstr (chld_out.line[i], "canonical name = "))) This change tells the plugin to ignore any nslookup output containing the string "canonical name = " but still matches those containing "name = ". And, for me, it does what I need. Question So, my question is this. Is the above change valid and should it be included in the next release, or perhaps a command-line option added to cater for such situations. All comments welcome. Many thanks, -- James Mernin Senior Software Engineer, Telecommunications Software & Systems Group, Waterford Institute of Technology, Waterford, Ireland. +353 (0)51 845694 | mailto:jmernin at tssg.org | http://www.tssg.org | http://www.wit.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrichero at antel.com.uy Tue Aug 12 15:47:44 2008 From: lrichero at antel.com.uy (Leonardo Richero) Date: Tue, 12 Aug 2008 13:47:44 +0000 (UTC) Subject: [Nagiosplug-devel] =?utf-8?q?check=5Fdisk_with_-e_option_prints_f?= =?utf-8?q?ilesystem_that_are_correct_and_have_no_errors_after_the_?= =?utf-8?b?Inwi?= Message-ID: In order to simplify the configuration and adminstration of nagios, we configured only one command to check all filesystem. And we want to see in errors alarm only (not all filesystem). With the current estable version of the plugin we could do that, but it prints after a "|" lot of information of all filesystem even we use -e option (to only see the erros). Is could be posible to avoid print the things after the "|" ? For example, is more legible to see that: ~/nagios-plugins-1.4.12> plugins/check_disk -e -w 30% -c 10% DISK WARNING - free space: / 935 MB (27% inode=73%); than: ~/nagios-plugins-1.4.12> plugins/check_disk -e -w 30% -c 10% DISK WARNING - free space: / 935 MB (27% inode=73%);| /=2413MB;2468;3174;0;3527 /dev=0MB;176;226;0;252 /opt/apps=636MB;2112;2716;0;3018 It could be posible to eliminate, (or filter only errors) in what is printed after the "|" ? From nagios at babar.us Tue Aug 12 16:50:23 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Tue, 12 Aug 2008 16:50:23 +0200 Subject: [Nagiosplug-devel] check_disk with -e option prints filesystem that are correct and have no errors after the "|" In-Reply-To: References: Message-ID: <20080812145023.GA31792@mail.babar.us> On Tue, Aug 12, 2008 at 01:47:44PM +0000, Leonardo Richero wrote: > Is could be posible to avoid print the things after the "|" ? > It could be posible to eliminate, (or filter only errors) in what is printed > after the "|" ? Why would you want to do that?! What's being printed after the | is performance data. You'd want performance data for all your disks, all the time, and not only when they're in an error state. This way, you can graph the usage over time. If you don't use performance data, then it doesn't matter, you won't see it anywhere anyway (apart from under the performance data field in the interface). See http://nagios.sourceforge.net/docs/3_0/perfdata.html -- Babar. From lrichero at antel.com.uy Tue Aug 12 18:16:57 2008 From: lrichero at antel.com.uy (lrichero at antel.com.uy) Date: Tue, 12 Aug 2008 13:16:57 -0300 Subject: [Nagiosplug-devel] check_disk with -e option prints filesystemthat are correct and have no errors after the "|" In-Reply-To: <20080812145023.GA31792@mail.babar.us> References: <20080812145023.GA31792@mail.babar.us> Message-ID: What we want is to avoid to include the "perform data" in the mail that is send as an alarm. I don't know if it could be configured at nagios server, instead of the plugin. We use a centralized Nagios Server 2.9, that an other group administrate. Its is planed to upgrade to 3.0 in few months, but not now. And the check_disk v1848 (nagios-plugins 1.4.11). El presente e-mail y cualquier posible archivo adjunto est? dirigido ?nicamente al destinatario del mensaje y contiene informaci?n que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Est? prohibida cualquier utilizaci?n, difusi?n o copia de este e-mail por cualquier persona o entidad que no sean las espec?ficas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicaci?n que haya sido emitida incumpliendo nuestra Pol?tica de Seguridad de la Informaci?n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy. From marc at ena.com Tue Aug 12 18:27:53 2008 From: marc at ena.com (Marc Powell) Date: Tue, 12 Aug 2008 11:27:53 -0500 Subject: [Nagiosplug-devel] check_disk with -e option prints filesystemthat are correct and have no errors after the "|" In-Reply-To: References: <20080812145023.GA31792@mail.babar.us> Message-ID: <19EEAC1C-65C9-4A50-BAFD-6C622F89F234@ena.com> On Aug 12, 2008, at 11:16 AM, wrote: > What we want is to avoid to include the "perform data" in the mail > that is send as an alarm. I don't know if it could be configured at > nagios server, instead of the plugin. I suspect that you are using the $SERVICEPERFDATA$ macro in your notification command. Remove it and the performance data won't be included in the notifications. http://nagios.sourceforge.net/docs/2_0/macros.html -- Marc From ric at Opus1.COM Tue Aug 19 15:59:34 2008 From: ric at Opus1.COM (Ric Anderson) Date: Tue, 19 Aug 2008 06:59:34 -0700 Subject: [Nagiosplug-devel] printf error in check_log plugin Message-ID: <48AAD1C6.9030909@opus1.com> check_log includes utils.sh, which defines ECHO=/usr/bin/printf if /usr/bin/printf exists. However, if the log file contains a % in its data, e.g. Aug 18 22:11:08 gw 271: 000269: Aug 18 22:11:07.451 MST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up and check_log is running with -q UPDOWN, then when check_log tries to display the matching line, it dies with (8) < Aug 18 22:11:08 gw 271: 000269: Aug 18 22:11:07.451 MST: /usr/bin/printf: %LI: invalid conversion specification Maybe check_log needs to over ride the definition of ECHO, or use "echo" in place of $ECHO? Cheers, Ric Anderson (ric at opus1.com) From ton.voon at altinity.com Thu Aug 21 17:27:01 2008 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 21 Aug 2008 16:27:01 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <4899116B.7090908@aei.ca> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> <4899116B.7090908@aei.ca> Message-ID: <744C35BB-3F61-4292-B28E-2EDF3674A3AA@altinity.com> On 6 Aug 2008, at 03:50, Thomas Guyot-Sionnest wrote: > I just tested it on a server without tap... The problem seems to be a > simple dependency - you need to build tap before the actual tests... > Although I doubt the way you did it will use GL libraries... > > The problem with tap is that although it's using gnulib it's missing > some modules to work on some servers. I was thinking of including it > directly with nagiosplug's build system, i.e. in tap/. I am doing what you suggest: tap is in external/tap-1.01. You can tell ./configure to run ./configure in this directory. However, I can't hook this generally because it would also install tap on a system, when we only want it for testing purposes. Anyway, I think it works correctly now. If I take a locally created distribution on a host without libtap, and run ./configure --enable- libtap, it will run the tests correctly. Let me know if I've missed anything. In a few days, I'll switch the tinderbox builds to include --enable-libtap so that we get more coverage from the tap tests. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Fri Aug 22 03:12:31 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 21 Aug 2008 21:12:31 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <744C35BB-3F61-4292-B28E-2EDF3674A3AA@altinity.com> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> <4899116B.7090908@aei.ca> <744C35BB-3F61-4292-B28E-2EDF3674A3AA@altinity.com> Message-ID: <48AE127F.4070007@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/08/08 11:27 AM, Ton Voon wrote: > On 6 Aug 2008, at 03:50, Thomas Guyot-Sionnest wrote: > >> I just tested it on a server without tap... The problem seems to be a >> simple dependency - you need to build tap before the actual tests... >> Although I doubt the way you did it will use GL libraries... >> >> The problem with tap is that although it's using gnulib it's missing >> some modules to work on some servers. I was thinking of including it >> directly with nagiosplug's build system, i.e. in tap/. > > > I am doing what you suggest: tap is in external/tap-1.01. > > You can tell ./configure to run ./configure in this directory. > However, I can't hook this generally because it would also install tap > on a system, when we only want it for testing purposes. I sure we could make it work that way... we aren't installing libnagiosplug.a neither. Don't use tap Makefiles, just tap code. The code could be in /libtap and build after gl, so we could use gl for missing libraries (which is the problem I wanted to solve in the first place). > Anyway, I think it works correctly now. If I take a locally created > distribution on a host without libtap, and run ./configure --enable- > libtap, it will run the tests correctly. You checked with/without extra-opts, right? When you moved the place for the TAP check in configure.in you also broke the optional extra-opts checks as they are defined before. What bite you is that by NOT forcing tap on a non-tap system, it would still try to build the extra-opts tests, and with TAP enabled, it wasn't building them anymore since it was overwriting the EXTRA_CHECKS (or something like that) variable with the base ones! > Let me know if I've missed anything. In a few days, I'll switch the > tinderbox builds to include --enable-libtap so that we get more > coverage from the tap tests. I'll see... I might just do it myself too, as I want something else now. To rewrite one of check_ntp_peer's functions I wrote a TAP check, and I'd like to have tap tests on the plugins/ section as well (linking against the .o files - I guess this should work). It would be nice to move all libs to /lib too, there's a few remaining ones in /plugins. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrhJ+6dZ+Kt5BchYRAtZtAKDn/ESvhRdv8rgCxdCRshmjrBHYVQCfbOXG y+qbFtXlM/7YMP5g4ODzlO8= =BMh9 -----END PGP SIGNATURE----- From ton.voon at altinity.com Fri Aug 22 07:47:42 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Aug 2008 06:47:42 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AE127F.4070007@aei.ca> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> <4899116B.7090908@aei.ca> <744C35BB-3F61-4292-B28E-2EDF3674A3AA@altinity.com> <48AE127F.4070007@aei.ca> Message-ID: <97460B54-8F97-4E44-9E2C-1A445E5BC065@altinity.com> On 22 Aug 2008, at 02:12, Thomas Guyot-Sionnest wrote: > I sure we could make it work that way... we aren't installing > libnagiosplug.a neither. Good point. But we set libnagiosplug.a to be not installed, whereas tap-1.01 does expect to be installed. > Don't use tap Makefiles, just tap code. Don't understand this. You still need the makefiles to compile > The code could be in /libtap and build after gl, so we could use gl > for > missing libraries (which is the problem I wanted to solve in the first > place). And I don't get the gl issues either. I've made a new tarball of tap with the fixes for asprintf so it has its own copy of gl in that tarball. I plan on putting a link to this tap file on the official tap site so people can download our version with the fixes. > You checked with/without extra-opts, right? When you moved the place > for > the TAP check in configure.in you also broke the optional extra-opts > checks as they are defined before. What bite you is that by NOT > forcing > tap on a non-tap system, it would still try to build the extra-opts > tests, and with TAP enabled, it wasn't building them anymore since it > was overwriting the EXTRA_CHECKS (or something like that) variable > with > the base ones! (hands up). I see what you mean here. I noticed this last night when Tinderbox failed for your Solaris server. Hooray for Tinderbox! Fixed now. > I'll see... I might just do it myself too, as I want something else > now. > To rewrite one of check_ntp_peer's functions I wrote a TAP check, and > I'd like to have tap tests on the plugins/ section as well (linking > against the .o files - I guess this should work). At the moment, I've left the tap tests in lib/t. You can still link them to objects in plugins/ if you want. Probably easier from a Makefile point of view to have all the tap tests in the same area. As an aside, the current "internet" tests are just not clever enough because you need to fool around with the variables to setup different test cases. I've started playing with the concept of starting up a HTTP::Simple server with URLs where I expect certain data and then running check_http against it. I'm already seeing issues with check_http (size of a returned page includes the headers - should this?). > It would be nice to move all libs to /lib too, there's a few remaining > ones in /plugins. Agreed. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From waja at cyconet.org Fri Aug 22 15:56:15 2008 From: waja at cyconet.org (Jan Wagner) Date: Fri, 22 Aug 2008 15:56:15 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> Message-ID: <200808221556.18926.waja@cyconet.org> Hi there, On Friday 27 June 2008 00:01, Ton Voon wrote: > Based on a comment made by Thomas, I've added the libtap distribution > into the nagios plugins project. This enables us to run C tests > without a dependency on external code. > > It includes two changes to the libtap project from > http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap including disabling > LIBPTHREAD and asprintf from gnulib > (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 ). > > libtap will only get included if ./configure --enable-libtap is set. > However, compiling will only take effect if a "make test" is run. sorry, but I have to come up with some complaints about that idea. I'm speaking as member of the Debian Nagios Maintainer Group. Do you really think it's an good idea to embedd code copies of other projects? Embedding other software forces you to keep track of (security-)issues of each of these projects and to update your copies at least if there occure any breakerage. The chance you are missing some of them is not less and if upstream of the code copies fixed their code, it will take extra time until you release a new version with the fixed code and even it will add extra work to your project. For Distribution/Packagers this will become a big problem as well. They have to keep track for all versions of these "embedded code copies" and try to backport the fixes to all (various) versions embedded in various software packages. Maybe the Security Team, which is responsible for updating security bugs, is not aware that software "Y" is shipped within software "Z", where software "Y" has an security issue, so software "Z" is also vulnerable. Even as long as you don't modify the upstream code, there is a chance to use the embedded software from external sources (for example the version shipped with the distribution and have the issue allready fixed). If you include your own changes into these code copies, this isn't possible anymore and your project is the single point to get this issue of your code copy fixed, which is quite annoying for all sides. Please think carefully about your idea to ship 3rd party software with yours, hopefully you will reconsider your decision. The Debian Security and the QA-Team did force removal of software with embedded code copies from the distribution in the past, which is not what anybody whats for nagios-plugins, I guess. Thanks and 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ton.voon at altinity.com Fri Aug 22 16:40:17 2008 From: ton.voon at altinity.com (ton.voon at altinity.com) Date: Fri, 22 Aug 2008 15:40:17 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <200808221556.18926.waja@cyconet.org> References: <200808221556.18926.waja@cyconet.org> Message-ID: <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> Hi Jan, On Fri, 22 Aug 2008 15:56:15 +0200, Jan Wagner wrote: > On Friday 27 June 2008 00:01, Ton Voon wrote: >> Based on a comment made by Thomas, I've added the libtap distribution >> into the nagios plugins project. This enables us to run C tests >> without a dependency on external code. >> >> It includes two changes to the libtap project from >> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap including disabling >> LIBPTHREAD and asprintf from gnulib >> (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 ). >> >> libtap will only get included if ./configure --enable-libtap is set. >> However, compiling will only take effect if a "make test" is run. > > sorry, but I have to come up with some complaints about that idea. I'm > speaking as member of the Debian Nagios Maintainer Group. Do you really > think > it's an good idea to embedd code copies of other projects? > > Embedding other software forces you to keep track of (security-)issues of > each > of these projects and to update your copies at least if there occure any > breakerage. The chance you are missing some of them is not less and if > upstream of the code copies fixed their code, it will take extra time > until > you release a new version with the fixed code and even it will add extra > work > to your project. > > For Distribution/Packagers this will become a big problem as well. They > have > to keep track for all versions of these "embedded code copies" and try to > backport the fixes to all (various) versions embedded in various software > packages. Maybe the Security Team, which is responsible for updating > security > bugs, is not aware that software "Y" is shipped within software "Z", where > > software "Y" has an security issue, so software "Z" is also vulnerable. > > Even as long as you don't modify the upstream code, there is a chance to > use > the embedded software from external sources (for example the version > shipped > with the distribution and have the issue allready fixed). If you include > your > own changes into these code copies, this isn't possible anymore and your > project is the single point to get this issue of your code copy fixed, > which > is quite annoying for all sides. > > Please think carefully about your idea to ship 3rd party software with > yours, > hopefully you will reconsider your decision. The Debian Security and the > QA-Team did force removal of software with embedded code copies from the > distribution in the past, which is not what anybody whats for > nagios-plugins, > I guess. The 3rd party code in question here is only for testing purposes. It is only enabled with a configure flag, so, outside of development, will not usually be used. On the general principle of whether to include 3rd party code, I'm not sure I agree with your stance. For instance, we include the Nagios::Plugins perl modules (and dependencies). This is to simplify installation for our users. However, there is a configure option to not include the perl modules, so you can add the appropriate dependencies at the packaging layer instead. A more entrenched example would be GNU lib - we embed their code (at their recommendation). Theoretically, a security exposure could be found there. But we have a very simple process to update their software and cut a new package. There's no way I would want this project, or any others that use gnulib, to have to recode all the functionality they provide. I can't guarantee that we will not include 3rd party software in future. We have to make a judgement on whether a 3rd party piece of code will provide us features or cross platform capabilities we need without re-inventing the wheel. That's a compromise we have to make. However, when possible, we will allow configure options to disable 3rd party code. Ton From ae at op5.se Fri Aug 22 17:09:30 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 Aug 2008 17:09:30 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> Message-ID: <48AED6AA.8020606@op5.se> For some reason your MUA double-wrapped everything. Could you look into your settings, Ton? ton.voon at altinity.com wrote: > > The 3rd party code in question here is only for testing purposes. It is > only enabled with a configure flag, so, outside of development, will not > usually be used. > Then why is it needed? If it's just for tinderbox builds, why not install it on the various tinderboxen? If it's not for tinderbox builds, why ship it at all? If someone needs to test libtap functionality they can jolly well install libtap imo. > A more entrenched example would be GNU lib - we embed their code (at their > recommendation). While we're at it, I'm pretty much against this too. Plugins, weighing in at an average of 555.57 LoC, that can't be made to run without a rather large compatibility library need to be looked over. Especially when the functions gnulib typically provides are along the lines of strndup(), vasnprintf(), full_write() et al. As it is, the compat lib is more than twice the size of the code it's providing compatibility for. > Theoretically, a security exposure could be found there. > But we have a very simple process to update their software and cut a new > package. There's no way I would want this project, or any others that use > gnulib, to have to recode all the functionality they provide. > It'll be even easier when you move to git, as you can then use gnulib as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan and contributor) ;-) > I can't guarantee that we will not include 3rd party software in future. We > have to make a judgement on whether a 3rd party piece of code will provide > us features or cross platform capabilities we need without re-inventing the > wheel. That's a compromise we have to make. However, when possible, we will > allow configure options to disable 3rd party code. > Sometimes, reinventing the wheel (or importing a handful of 10-line functions) is preferrable to including the whole shebang. I should probably shut up though. It's friday and beer is flowing freely within the office walls :-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From holger at CIS.FU-Berlin.DE Fri Aug 22 17:24:43 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 22 Aug 2008 17:24:43 +0200 Subject: [Nagiosplug-devel] Gnulib alternative? (was: Libtap included in distribution) In-Reply-To: <48AED6AA.8020606@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> Message-ID: <20080822152443.GP86162167@CIS.FU-Berlin.DE> * Andreas Ericsson [2008-08-22 17:09]: > ton.voon at altinity.com wrote: > > A more entrenched example would be GNU lib - we embed their code (at their > > recommendation). > > While we're at it, I'm pretty much against this too. Plugins, weighing > in at an average of 555.57 LoC, that can't be made to run without a > rather large compatibility library need to be looked over. Especially > when the functions gnulib typically provides are along the lines of > strndup(), vasnprintf(), full_write() et al. What's your suggestion? Don't use non-essential stuff like asprintf()? Or rewrite everything we need from Gnulib? Or use something else than Gnulib? If so, what (and why)? Or just forget about portability? Holger From ae at op5.se Fri Aug 22 17:34:00 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 Aug 2008 17:34:00 +0200 Subject: [Nagiosplug-devel] Gnulib alternative? In-Reply-To: <20080822152443.GP86162167@CIS.FU-Berlin.DE> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <20080822152443.GP86162167@CIS.FU-Berlin.DE> Message-ID: <48AEDC68.5080800@op5.se> Holger Weiss wrote: > * Andreas Ericsson [2008-08-22 17:09]: >> ton.voon at altinity.com wrote: >>> A more entrenched example would be GNU lib - we embed their code (at their >>> recommendation). >> While we're at it, I'm pretty much against this too. Plugins, weighing >> in at an average of 555.57 LoC, that can't be made to run without a >> rather large compatibility library need to be looked over. Especially >> when the functions gnulib typically provides are along the lines of >> strndup(), vasnprintf(), full_write() et al. > > What's your suggestion? Don't use non-essential stuff like asprintf()? > Or rewrite everything we need from Gnulib? Or use something else than > Gnulib? If so, what (and why)? Or just forget about portability? > My suggestion is a combination of the above Try to work around the asprintf() stuff as much as possible. Since all plugins run single-threaded and only ever output stuff on stdout, most of the functionality can be implemented using multiple printf() calls instead. Everyone has printf(). When you find you repeat the same type of commands lots and lots of times, implement a wrapper. I'd imagine you'd need wrappers for malloc(), calloc(), realloc() et al, fe. For preference called xmalloc(), xcalloc(), xrealloc() etc. The x* calls should all die() with an appropriate error message when they fail. When it's obvious that some functionality from gnulib (or similar) can remove a hundred or so lines of code from all the plugins combined, import that particular function into the plugins. If the function is complex, it's probably too specific. If it's simple, it's most likely obviously correct (it's not hard to implement strndup() in a bugfree manner so long as performance is not an issue). Forgetting about portability is obviously not an option (although I love coding for a system where I know I have gcc-4.1 and glibc-2.8 available everywhere), but adding a library of 1.7MB to 788KB of plugin code (not including tests) is just plain weird. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Fri Aug 22 17:48:31 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Aug 2008 15:48:31 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 16:06 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From ton.voon at altinity.com Fri Aug 22 17:58:33 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Aug 2008 16:58:33 +0100 Subject: [Nagiosplug-devel] Gnulib alternative? In-Reply-To: <48AEDC68.5080800@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <20080822152443.GP86162167@CIS.FU-Berlin.DE> <48AEDC68.5080800@op5.se> Message-ID: Andreas, On 22 Aug 2008, at 16:34, Andreas Ericsson wrote: > Forgetting about portability is obviously not an option (although I > love coding for a system where I know I have gcc-4.1 and glibc-2.8 > available everywhere), but adding a library of 1.7MB to 788KB of > plugin code (not including tests) is just plain weird. Respectfully disagree. If you want to play with the numbers, then moving 1.7MB out (which we don't maintain) to 100KB in (that we will have to), doesn't smack to me of a good decision (btw, fancy writing a regexp library?) It's not about lines of code - the priority is quality. > Then why is [libtap] needed? If it's just for tinderbox builds, why > not install > it on the various tinderboxen? If it's not for tinderbox builds, why > ship > it at all? If someone needs to test libtap functionality they can > jolly > well install libtap imo. That's a fair point. My argument is that I want to reduce the barrier to running tests, not increase them. If you contributed a server to tinderbox for testing, I might even agree with you :P Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Fri Aug 22 18:12:07 2008 From: seanius at seanius.net (sean finney) Date: Fri, 22 Aug 2008 18:12:07 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AED6AA.8020606@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> Message-ID: <200808221812.10825.seanius@seanius.net> hi everyone, figured i would through my 0.02 $LC_MONETARY from the armchair :) on the issue of embedding 3rd-party code, i think the situation is a little more nuanced then "include it or do not include it". my personal recommendation, from having worked in this and other projects that wish to do so, as well as with the debian security team who often have to deal with the problem, is roughly as follows: "embedding code is okay, as long as you do not force users/packages/etc to use your embedded version" providing bundled code is a great way to ensure cross platform / environment consistency. however, as jan mentioned, this has security implications if the bundled code ever has a serious security problem, or otherwise requires an update. for example, PHP typically bundles the gd image library, imap client library, etc with their code. both of these libraries have a long and ugly history security-wise, which in turn resulted in the upstream PHP project needed to release security updates due to their bundled code. also, they bundle stuff like timezone data, which is a major pain in the ass to keep up to date (we recently patched that feature out, but i digress) debian and others choose to build such packages using the distro-provided libraries instead, thus making bundled code unneeded but ultimately harmless. in most/ideal cases it's just a matter of passing --with-foo=/usr or similar to a configure script which will override the default behaviour of using the bundled version. if nagios-plugins could/does provide similar functionality, i think the problem is essentially moot. however, note that "do not force them to use your version" also means you shouldn't make any incompatible changes to the bundled code, as it would prevent others from using their local system versions. i saw some mention earlier of needing to make a change in libtap for example.... though maybe that's not as grave since upstream work for that seems dead (you should email your patch anyway, as well as have it documented for posterity though, i'd say). also, as an aside, i don't think libtap is packaged in debian at the moment (i tried packaging it a year or two back and ran into some problem before losing interest), though i do see gnulib packages. sean On Friday 22 August 2008 05:09:30 pm Andreas Ericsson wrote: > Then why is it needed? If it's just for tinderbox builds, why not install > it on the various tinderboxen? If it's not for tinderbox builds, why ship > it at all? If someone needs to test libtap functionality they can jolly > well install libtap imo. for anyone who wants to write/run tests on their local code. i don't see that as being incredibly problematic. > > Theoretically, a security exposure could be found there. > > But we have a very simple process to update their software and cut a new > > package. There's no way I would want this project, or any others that use > > gnulib, to have to recode all the functionality they provide. > > It'll be even easier when you move to git, as you can then use gnulib > as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan > and contributor) ;-) agreed, though from my experience git submodules are still quite lacking from a usability perspective. > I should probably shut up though. It's friday and beer is flowing > freely within the office walls :-) git clone beer://andreas here sean -------------- 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 holger at CIS.FU-Berlin.DE Fri Aug 22 18:33:59 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 22 Aug 2008 18:33:59 +0200 Subject: [Nagiosplug-devel] Gnulib alternative? In-Reply-To: <48AEDC68.5080800@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <20080822152443.GP86162167@CIS.FU-Berlin.DE> <48AEDC68.5080800@op5.se> Message-ID: <20080822163359.GQ86162167@CIS.FU-Berlin.DE> * Andreas Ericsson [2008-08-22 17:34]: > Holger Weiss wrote: > > * Andreas Ericsson [2008-08-22 17:09]: > >> ton.voon at altinity.com wrote: > >>> A more entrenched example would be GNU lib - we embed their code (at their > >>> recommendation). > >> > >> While we're at it, I'm pretty much against this too. Plugins, weighing > >> in at an average of 555.57 LoC, that can't be made to run without a > >> rather large compatibility library need to be looked over. Especially > >> when the functions gnulib typically provides are along the lines of > >> strndup(), vasnprintf(), full_write() et al. > > > > What's your suggestion? Don't use non-essential stuff like asprintf()? > > Or rewrite everything we need from Gnulib? Or use something else than > > Gnulib? If so, what (and why)? Or just forget about portability? > > My suggestion is a combination of the above > Try to work around the asprintf() stuff as much as possible. Since all > plugins run single-threaded and only ever output stuff on stdout, most > of the functionality can be implemented using multiple printf() calls > instead. Everyone has printf(). In order to get rid of replacement code for asprintf(), we'd have to restrict ourselves to _never_ use asprintf(). I wouldn't want to do that just to get rid of replacement code which won't even be compiled on most systems (since non-ancient Linux and BSD systems provide asprintf() and friends in their libc's). > Forgetting about portability is obviously not an option (although I > love coding for a system where I know I have gcc-4.1 and glibc-2.8 > available everywhere), but adding a library of 1.7MB to 788KB of > plugin code (not including tests) is just plain weird. I have no idea why the plain fact that a library is larger than the code which calls it would be "weird". Most of the Gnulib stuff we use is either replacement code for functions which should really be in libc but unfortunately isn't on some systems we support, or stuff like e.g. portable access to filesystem data which we definitely need but which is non-trivial to rewrite. Maybe we could get rid of some of the libc-replacement functions by abstaining from using them, but I don't see any real benefit in doing so. In any case, I don't agree that we should (or even could) get rid of substantial parts of the code we currently use from Gnulib without rewriting it. And IMO, we have far more important things to do than rewriting Gnulib stuff. Holger From noreply at sourceforge.net Fri Aug 22 19:04:04 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Aug 2008 17:04:04 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 16:06 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-08-22 19:04 Message: Logged In: YES user_id=759506 Originator: NO And here's another version which fixes the memory leak I introduced with my previous version :-) File Added: check_http.extented_status_codes.diff.3 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From waja at cyconet.org Fri Aug 22 21:02:16 2008 From: waja at cyconet.org (Jan Wagner) Date: Fri, 22 Aug 2008 21:02:16 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <200808221812.10825.seanius@seanius.net> References: <200808221556.18926.waja@cyconet.org> <48AED6AA.8020606@op5.se> <200808221812.10825.seanius@seanius.net> Message-ID: <200808222102.20690.waja@cyconet.org> Hi there again, I feel a bit worried about some reactions on my mail. It was not my intention to start any flamewars. Maybe I did not choose the words with the correct nuance. :/ On Friday 22 August 2008 18:12, sean finney wrote: > on the issue of embedding 3rd-party code, i think the situation is a little > more nuanced then "include it or do not include it". my personal > recommendation, from having worked in this and other projects that wish to > do so, as well as with the debian security team who often have to deal with > the problem, is roughly as follows: > > "embedding code is okay, as long as you do not force users/packages/etc to > use your embedded version" > > providing bundled code is a great way to ensure cross platform / > environment consistency. however, as jan mentioned, this has security > implications if the bundled code ever has a serious security problem, or > otherwise requires an update. [...] > debian and others choose to build such packages using the distro-provided > libraries instead, thus making bundled code unneeded but ultimately > harmless. in most/ideal cases it's just a matter of passing --with-foo=/usr > or similar to a configure script which will override the default behaviour > of using the bundled version. > > if nagios-plugins could/does provide similar functionality, i think the > problem is essentially moot. > > however, note that "do not force them to use your version" also means you > shouldn't make any incompatible changes to the bundled code, as it would > prevent others from using their local system versions. i saw some mention > earlier of needing to make a change in libtap for example.... though maybe > that's not as grave since upstream work for that seems dead (you should > email your patch anyway, as well as have it documented for posterity > though, i'd say). Sean, thanks for your wonderfull explanation. It's expressing exactly my opinion about the situation. As far there is no strong depency on the embedded code copies, I think it's just fine. Just after writing my mail I did give latest svn snapshot a try with removed libtap from source tree and I recognized, it compiles fine. So in this case I have the option to avoid using the embedded libtap. Idealy there would be an option to use a external libtap via an option as sean described, but as far as I understand you modified your shipped libtap, so this wouldn't be an equivalent replacement for your version of libtap. > also, as an aside, i don't think libtap is packaged in debian at the moment No it isn't, but as long as it's possible to avoid using the shipped libtap, that would be fine. > (i tried packaging it a year or two back and ran into some problem before > losing interest), though i do see gnulib packages. For gnulib the situation is a way different. You depending heavily on (your shipped) gnulib and there is no way neither to avoid using the shipped gnulib code nor using a external gnulib copy. Is there a possibility that you provide --path-gnulib= or something like that in the future? For example Debian has a package gnulib which can be used for this (if you don't changed anything in your embedded copy or don't rely on this modifications) I guess. 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thomas at zango.com Fri Aug 22 21:21:57 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 22 Aug 2008 15:21:57 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AED6AA.8020606@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> Message-ID: <48AF11D5.20902@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson wrote: | For some reason your MUA double-wrapped everything. | Could you look into your settings, Ton? | | ton.voon at altinity.com wrote: |> The 3rd party code in question here is only for testing purposes. It is |> only enabled with a configure flag, so, outside of development, will not |> usually be used. |> | | Then why is it needed? If it's just for tinderbox builds, why not install | it on the various tinderboxen? If it's not for tinderbox builds, why ship | it at all? If someone needs to test libtap functionality they can jolly | well install libtap imo. The problem is that libtab is pretty much unmaintained, and can be pretty hard to install on some architectures. This is specially on special architecture that testing comes in handy. Also we could encourage users to report failed tests. Most users won't install tap on their system just for the purpose of testing. |> A more entrenched example would be GNU lib - we embed their code (at their |> recommendation). | | While we're at it, I'm pretty much against this too. Plugins, weighing | in at an average of 555.57 LoC, that can't be made to run without a | rather large compatibility library need to be looked over. Especially | when the functions gnulib typically provides are along the lines of | strndup(), vasnprintf(), full_write() et al. As it is, the compat lib | is more than twice the size of the code it's providing compatibility | for. The goal is to provide cross-platform compatibility. Rather than waiting on user to report problems we included a common set of libraries. There's also some GL modules what provide us with useful functions, like getting disk usage in a cross-platform fashion. The build system include only required Gnulib code, so although it's more code than the plugins themselves it's not something that should increase the size of your compiled plugins. |> Theoretically, a security exposure could be found there. |> But we have a very simple process to update their software and cut a new |> package. There's no way I would want this project, or any others that use |> gnulib, to have to recode all the functionality they provide. |> | | It'll be even easier when you move to git, as you can then use gnulib | as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan | and contributor) ;-) I'm not too sure about this way of doing it, because normally you use Gnulib's scripts to update the modules. It's simple and fast. It would also mean we'd end up with the whole Gnulib repository rather than the subset of modules we included. |> I can't guarantee that we will not include 3rd party software in future. We |> have to make a judgement on whether a 3rd party piece of code will provide |> us features or cross platform capabilities we need without re-inventing the |> wheel. That's a compromise we have to make. However, when possible, we will |> allow configure options to disable 3rd party code. |> | | Sometimes, reinventing the wheel (or importing a handful of 10-line | functions) is preferrable to including the whole shebang. And how will you guarantee compatibility across all platform Nagios-plugins get compiled on? I don't want to disappoint you but I don't see any compelling reason to change the way we do regarding Gnulib (I do have enhancements regarding libtap that have been discussed in the #nagios-devel channel this morning though). - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrxHV6dZ+Kt5BchYRAg0AAKCNUEpDS7a2cl0qdn55uFzMy/RbgQCbB9tC BXkx7zHddYl94D2rdtTiQN4= =Qfyf -----END PGP SIGNATURE----- From ae at op5.se Fri Aug 22 21:43:01 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 Aug 2008 21:43:01 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AF11D5.20902@zango.com> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> Message-ID: <48AF16C5.20300@op5.se> Thomas Guyot-Sionnest wrote: > | > | It'll be even easier when you move to git, as you can then use gnulib > | as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan > | and contributor) ;-) > > I'm not too sure about this way of doing it, because normally you use > Gnulib's scripts to update the modules. It's simple and fast. > > It would also mean we'd end up with the whole Gnulib repository rather > than the subset of modules we included. > Only in your upstream repository, where you can choose to clone a submodule with --depth 1 to make it really shallow. For releases it'll make no difference what so ever. > |> I can't guarantee that we will not include 3rd party software in > future. We > |> have to make a judgement on whether a 3rd party piece of code will > provide > |> us features or cross platform capabilities we need without > re-inventing the > |> wheel. That's a compromise we have to make. However, when possible, > we will > |> allow configure options to disable 3rd party code. > |> > | > | Sometimes, reinventing the wheel (or importing a handful of 10-line > | functions) is preferrable to including the whole shebang. > > And how will you guarantee compatibility across all platform > Nagios-plugins get compiled on? I don't want to disappoint you but I > don't see any compelling reason to change the way we do regarding Gnulib I do. If most of it isn't getting used, then get rid of it and import the parts that *are* getting used. It's quite possible that the nagiosplugins gets used on more platforms than gnulib, in which case you'll have to ship patches upstream every now and then. If there are bugs in gnulib, you'll have no part of it if it's not part of the stuff you imported (which, by the sound of it, is unlikely). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From thomas at zango.com Fri Aug 22 21:43:07 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 22 Aug 2008 15:43:07 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <200808222102.20690.waja@cyconet.org> References: <200808221556.18926.waja@cyconet.org> <48AED6AA.8020606@op5.se> <200808221812.10825.seanius@seanius.net> <200808222102.20690.waja@cyconet.org> Message-ID: <48AF16CB.3080306@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Wagner wrote: | Hi there again, | | I feel a bit worried about some reactions on my mail. It was not my intention | to start any flamewars. Maybe I did not choose the words with the correct | nuance. :/ | | On Friday 22 August 2008 18:12, sean finney wrote: |> on the issue of embedding 3rd-party code, i think the situation is a little |> more nuanced then "include it or do not include it". my personal |> recommendation, from having worked in this and other projects that wish to |> do so, as well as with the debian security team who often have to deal with |> the problem, is roughly as follows: |> |> "embedding code is okay, as long as you do not force users/packages/etc to |> use your embedded version" |> |> providing bundled code is a great way to ensure cross platform / |> environment consistency. however, as jan mentioned, this has security |> implications if the bundled code ever has a serious security problem, or |> otherwise requires an update. | | [...] | |> debian and others choose to build such packages using the distro-provided |> libraries instead, thus making bundled code unneeded but ultimately |> harmless. in most/ideal cases it's just a matter of passing - --with-foo=/usr |> or similar to a configure script which will override the default behaviour |> of using the bundled version. |> |> if nagios-plugins could/does provide similar functionality, i think the |> problem is essentially moot. |> |> however, note that "do not force them to use your version" also means you |> shouldn't make any incompatible changes to the bundled code, as it would |> prevent others from using their local system versions. i saw some mention |> earlier of needing to make a change in libtap for example.... though maybe |> that's not as grave since upstream work for that seems dead (you should |> email your patch anyway, as well as have it documented for posterity |> though, i'd say). | | Sean, thanks for your wonderfull explanation. It's expressing exactly my | opinion about the situation. | As far there is no strong depency on the embedded code copies, I think it's | just fine. Just after writing my mail I did give latest svn snapshot a try | with removed libtap from source tree and I recognized, it compiles fine. So | in this case I have the option to avoid using the embedded libtap. | Idealy there would be an option to use a external libtap via an option as sean | described, but as far as I understand you modified your shipped libtap, so | this wouldn't be an equivalent replacement for your version of libtap. | |> also, as an aside, i don't think libtap is packaged in debian at the moment | | No it isn't, but as long as it's possible to avoid using the shipped libtap, | that would be fine. | |> (i tried packaging it a year or two back and ran into some problem before |> losing interest), though i do see gnulib packages. | | For gnulib the situation is a way different. You depending heavily on (your | shipped) gnulib and there is no way neither to avoid using the shipped gnulib | code nor using a external gnulib copy. Is there a possibility that you | provide --path-gnulib= or something like that in the future? For example | Debian has a package gnulib which can be used for this (if you don't changed | anything in your embedded copy or don't rely on this modifications) I guess. Well, gnulib is not meant to be complied and installed as a library, but rather used for compiling programs. Even if you have gnulib installed on your system you would have to update the modules inside Nagios-plugins tree (regarding that, is you were to update Gnulib in Nagios-plugins before compilation on Debian, you should probably use Git HEAD instead of another debian package). There is no way we could directly link to an installed gnulib because it is _not_ compiled! The only thing we could do is use that patch to run gnulib-tool and import that gnulib to the plugin. However considering that the plugins are tested against the specific gnulib version bundled with it that would be a very bad idea. It would also likely running autoheader, automake and autoconf again and many system arett properly set-up for that step. For every other library beside libtab (used for testing only) we just don't build plugins that libraqries that are missing. Regarding Nagios::Plugin Perl module, IIRC the idea is to eventually install it _locally_ in the libexec dir for availability to our own Perl plugins, unless user specify to use the system-wide module OR to install the buldled module system-wide. Again, this is so that we can test and install our plugins against a specific version of the module without interfering with anything on the system. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrxbL6dZ+Kt5BchYRAvOQAJ9BNCKwYdyqZ3DHrHot4ANTvHDfcACcCu74 uNAN7xIN+UhY1DpsZ8wfS3s= =uSg5 -----END PGP SIGNATURE----- From ton.voon at altinity.com Fri Aug 22 22:33:27 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Aug 2008 21:33:27 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AF16C5.20300@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> Message-ID: On 22 Aug 2008, at 20:43, Andreas Ericsson wrote: >> And how will you guarantee compatibility across all platform >> Nagios-plugins get compiled on? I don't want to disappoint you but I >> don't see any compelling reason to change the way we do regarding >> Gnulib > > I do. If most of it isn't getting used, then get rid of it and > import the > parts that *are* getting used. I call "halt" on your participation on this point, Andreas. You clearly don't understand how gnulib is used in Nagios Plugins, because we are doing *precisely* this. I look forward to other points you make where you have some basis of understanding :) Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From thomas at zango.com Fri Aug 22 22:52:22 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 22 Aug 2008 16:52:22 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AF16C5.20300@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> Message-ID: <48AF2706.50904@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson wrote: | Thomas Guyot-Sionnest wrote: |> And how will you guarantee compatibility across all platform |> Nagios-plugins get compiled on? I don't want to disappoint you but I |> don't see any compelling reason to change the way we do regarding Gnulib | | I do. If most of it isn't getting used, then get rid of it and import the | parts that *are* getting used. It's quite possible that the nagiosplugins | gets used on more platforms than gnulib, in which case you'll have to ship | patches upstream every now and then. I'd doubt it. Gnulib is used very widely, and certainly support more architectures than we do. | If there are bugs in gnulib, you'll have no part of it if it's not part of | the stuff you imported (which, by the sound of it, is unlikely). What do you mean?? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrycG6dZ+Kt5BchYRArN9AJ90OAsY/MI9Et+4lPUooTJkLJyDVACfZkfZ y2V9HgL+kkPwTeG2NsMNl/E= =CBdL -----END PGP SIGNATURE----- From ton.voon at altinity.com Fri Aug 22 22:57:19 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Aug 2008 21:57:19 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <200808221812.10825.seanius@seanius.net> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <200808221812.10825.seanius@seanius.net> Message-ID: Hi Sean, On 22 Aug 2008, at 17:12, sean finney wrote: > "embedding code is okay, as long as you do not force users/packages/ > etc to > use your embedded version" That's a good principle. I'll update our dev guidelines (as soon as I get docbook working on my mac again). > for example, PHP typically bundles the gd image library, imap client > library, > etc with their code. both of these libraries have a long and ugly > history > security-wise, which in turn resulted in the upstream PHP project > needed to > release security updates due to their bundled code. also, they > bundle stuff > like timezone data, which is a major pain in the ass to keep up to > date (we > recently patched that feature out, but i digress) Nagios Plugins as a project is very difficult because we need 3rd party frameworks for relatively little functionality (whereas I can see GD would be a big gain for PHP). For instance, we need mysql libraries for check_mysql to work. I guess we could include msqlclient, but we've made a decision that the benefit of including this 3rd party code is very little compared to the risk of changes to the interface. I'm just flagging that this decision may be different for other code in future, but we definitely consider it carefully. > debian and others choose to build such packages using the distro- > provided > libraries instead, thus making bundled code unneeded but ultimately > harmless. > in most/ideal cases it's just a matter of passing --with-foo=/usr or > similar > to a configure script which will override the default behaviour of > using the > bundled version. > > if nagios-plugins could/does provide similar functionality, i think > the > problem is essentially moot. I think this will always be the case. You can hold it to me if not :) > however, note that "do not force them to use your version" also > means you > shouldn't make any incompatible changes to the bundled code, as it > would > prevent others from using their local system versions. i saw some > mention > earlier of needing to make a change in libtap for example.... though > maybe > that's not as grave since upstream work for that seems dead (you > should email > your patch anyway, as well as have it documented for posterity > though, i'd > say). The only patches we made are for http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/25 and http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32, not interface changes. As you say, the upstream project appears dead. But I don't fancy reimplementing the functionality... And how come your email is refers to the project as "you" - you still have commit access, right? :) Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Fri Aug 22 23:21:30 2008 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 22 Aug 2008 22:21:30 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <200808222102.20690.waja@cyconet.org> References: <200808221556.18926.waja@cyconet.org> <48AED6AA.8020606@op5.se> <200808221812.10825.seanius@seanius.net> <200808222102.20690.waja@cyconet.org> Message-ID: On 22 Aug 2008, at 20:02, Jan Wagner wrote: > As far there is no strong depency on the embedded code copies, I > think it's > just fine. Just after writing my mail I did give latest svn snapshot > a try > with removed libtap from source tree and I recognized, it compiles > fine. So > in this case I have the option to avoid using the embedded libtap. > Idealy there would be an option to use a external libtap via an > option as sean > described, but as far as I understand you modified your shipped > libtap, so > this wouldn't be an equivalent replacement for your version of libtap. Just for the record: we haven't modified libtap beyond fixing compile problems on certain platforms; we include libtap for convenience; it is only required for tests; you can ignore libtap and other tests will still work. >> also, as an aside, i don't think libtap is packaged in debian at >> the moment > > No it isn't, but as long as it's possible to avoid using the shipped > libtap, > that would be fine. We won't be linking to any external libtap, because this situation doesn't require it (there's bigger fish for us to fry!). However, you can provide an autoconf patch if you wish. >> (i tried packaging it a year or two back and ran into some problem >> before >> losing interest), though i do see gnulib packages. > > For gnulib the situation is a way different. You depending heavily > on (your > shipped) gnulib and there is no way neither to avoid using the > shipped gnulib > code nor using a external gnulib copy. Is there a possibility that you > provide --path-gnulib= or something like that in the future? I think that is a worthwhile patch. Ton http://www.altinity.com UK: +44 (0)870 787 9243 US: +1 866 879 9184 Fax: +44 (0)845 280 1725 Skype: tonvoon From ae at op5.se Sat Aug 23 00:50:20 2008 From: ae at op5.se (Andreas Ericsson) Date: Sat, 23 Aug 2008 00:50:20 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> Message-ID: <48AF42AC.9070607@op5.se> Ton Voon wrote: > On 22 Aug 2008, at 20:43, Andreas Ericsson wrote: > >>> And how will you guarantee compatibility across all platform >>> Nagios-plugins get compiled on? I don't want to disappoint you but I >>> don't see any compelling reason to change the way we do regarding >>> Gnulib >> I do. If most of it isn't getting used, then get rid of it and >> import the >> parts that *are* getting used. > > I call "halt" on your participation on this point, Andreas. You > clearly don't understand how gnulib is used in Nagios Plugins, because > we are doing *precisely* this. > Except it takes quite a while to figure out which parts are used and which can be deleted. Besides that, it's what happens when you replace cogitation with alcohol ;-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Sat Aug 23 00:56:34 2008 From: ae at op5.se (Andreas Ericsson) Date: Sat, 23 Aug 2008 00:56:34 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AF2706.50904@zango.com> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> <48AF2706.50904@zango.com> Message-ID: <48AF4422.30204@op5.se> Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andreas Ericsson wrote: > | Thomas Guyot-Sionnest wrote: > |> And how will you guarantee compatibility across all platform > |> Nagios-plugins get compiled on? I don't want to disappoint you but I > |> don't see any compelling reason to change the way we do regarding Gnulib > | > | I do. If most of it isn't getting used, then get rid of it and import the > | parts that *are* getting used. It's quite possible that the nagiosplugins > | gets used on more platforms than gnulib, in which case you'll have to ship > | patches upstream every now and then. > > I'd doubt it. Gnulib is used very widely, and certainly support more > architectures than we do. > Quite so, but the nagiosplug project gets installed on all unixy flavours in networks where someone's running Nagios. Personally, I've helped install it on more variants of unix than I even knew existed, and at least 3 major-versions of each variant. gnulib was not much of an option there, to be honest. > | If there are bugs in gnulib, you'll have no part of it if it's not part of > | the stuff you imported (which, by the sound of it, is unlikely). > > What do you mean?? > I mean "remove the unused sourcecode from the repository". Right now there's quite a lot of it, as stated before. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Sun Aug 24 23:53:18 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Aug 2008 21:53:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 15:06 Message generated for change (Comment added) made by svennierlein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: sni (svennierlein) Date: 2008-08-24 21:53 Message: Logged In: YES user_id=1936413 Originator: YES Added 2 tests to plugins/tests/check_http.t ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:04 Message: Logged In: YES user_id=759506 Originator: NO And here's another version which fixes the memory leak I introduced with my previous version :-) File Added: check_http.extented_status_codes.diff.3 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 15:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From noreply at sourceforge.net Sun Aug 24 23:56:30 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Aug 2008 21:56:30 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 15:06 Message generated for change (Comment added) made by svennierlein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: sni (svennierlein) Date: 2008-08-24 21:56 Message: Logged In: YES user_id=1936413 Originator: YES Attached new patch file. ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-24 21:53 Message: Logged In: YES user_id=1936413 Originator: YES Added 2 tests to plugins/tests/check_http.t ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:04 Message: Logged In: YES user_id=759506 Originator: NO And here's another version which fixes the memory leak I introduced with my previous version :-) File Added: check_http.extented_status_codes.diff.3 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 15:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From noreply at sourceforge.net Mon Aug 25 00:00:18 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Aug 2008 22:00:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 15:06 Message generated for change (Comment added) made by svennierlein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: sni (svennierlein) Date: 2008-08-24 22:00 Message: Logged In: YES user_id=1936413 Originator: YES Sry, I'm unable to upload the patch: File Upload: ArtifactFile: Could not open file for writing The patch can be downloaded here: http://www.nierlein.com/check_http.extented_status_codes.diff.4 ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-24 21:56 Message: Logged In: YES user_id=1936413 Originator: YES Attached new patch file. ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-24 21:53 Message: Logged In: YES user_id=1936413 Originator: YES Added 2 tests to plugins/tests/check_http.t ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:04 Message: Logged In: YES user_id=759506 Originator: NO And here's another version which fixes the memory leak I introduced with my previous version :-) File Added: check_http.extented_status_codes.diff.3 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 15:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From dermoth at aei.ca Mon Aug 25 07:19:20 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 25 Aug 2008 01:19:20 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48AF4422.30204@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> <48AF2706.50904@zango.com> <48AF4422.30204@op5.se> Message-ID: <48B240D8.30808@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/08/08 06:56 PM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Andreas Ericsson wrote: >> | Thomas Guyot-Sionnest wrote: >> |> And how will you guarantee compatibility across all platform >> |> Nagios-plugins get compiled on? I don't want to disappoint you but I >> |> don't see any compelling reason to change the way we do regarding Gnulib >> | >> | I do. If most of it isn't getting used, then get rid of it and import the >> | parts that *are* getting used. It's quite possible that the nagiosplugins >> | gets used on more platforms than gnulib, in which case you'll have to ship >> | patches upstream every now and then. >> >> I'd doubt it. Gnulib is used very widely, and certainly support more >> architectures than we do. >> > > Quite so, but the nagiosplug project gets installed on all unixy flavours > in networks where someone's running Nagios. Personally, I've helped > install it on more variants of unix than I even knew existed, and at > least 3 major-versions of each variant. gnulib was not much of an option > there, to be honest. If you managed to compile Nagios-plugins on all those architecture it's *very* likely because there's a bunch of Gnulib modules included in Nagios-plugins. It's not something that you're expected to install beforehand (you can't even compile it alone), it's something that fills in missing C functions that are standard in most recent systems (plus some added functionality that we use in some plugins). That's why it's bundled with Nagios-plugins, and also why we include more modules than we need on our own development systems. >> | If there are bugs in gnulib, you'll have no part of it if it's not part of >> | the stuff you imported (which, by the sound of it, is unlikely). >> >> What do you mean?? >> > > I mean "remove the unused sourcecode from the repository". Right now there's > quite a lot of it, as stated before. I agree with you, we could map out all functions used in Nagios-plugins and remove Gnulib modules (if any) that implement functions we don't use. IIRC I cleaned up the most obvious ones in my last sync, but unless you can give me some automated tools and/or nifty oneliners that can make this a 10-minute job, it's likely that I'll rather work on actual bugfixes and code enhancements that on cleaning up Gnulib modules - at least for the foreseeable future. If you have that little extra time to clean it up your contribution will be more than welcome ;) - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIskDX6dZ+Kt5BchYRAhwkAKCSvp82BdRXHIHs51o4RiOeBzzl6ACg0oGi gG7DQ/LyyVj9qNT/xGsUeZw= =fzsz -----END PGP SIGNATURE----- From ae at op5.se Mon Aug 25 10:57:31 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 25 Aug 2008 10:57:31 +0200 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48B240D8.30808@aei.ca> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> <48AF2706.50904@zango.com> <48AF4422.30204@op5.se> <48B240D8.30808@aei.ca> Message-ID: <48B273FB.3040303@op5.se> Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22/08/08 06:56 PM, Andreas Ericsson wrote: >> Thomas Guyot-Sionnest wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Andreas Ericsson wrote: >>> | Thomas Guyot-Sionnest wrote: >>> |> And how will you guarantee compatibility across all platform >>> |> Nagios-plugins get compiled on? I don't want to disappoint you but I >>> |> don't see any compelling reason to change the way we do regarding Gnulib >>> | >>> | I do. If most of it isn't getting used, then get rid of it and import the >>> | parts that *are* getting used. It's quite possible that the nagiosplugins >>> | gets used on more platforms than gnulib, in which case you'll have to ship >>> | patches upstream every now and then. >>> >>> I'd doubt it. Gnulib is used very widely, and certainly support more >>> architectures than we do. >>> >> Quite so, but the nagiosplug project gets installed on all unixy flavours >> in networks where someone's running Nagios. Personally, I've helped >> install it on more variants of unix than I even knew existed, and at >> least 3 major-versions of each variant. gnulib was not much of an option >> there, to be honest. > > If you managed to compile Nagios-plugins on all those architecture it's > *very* likely because there's a bunch of Gnulib modules included in > Nagios-plugins. It's not something that you're expected to install > beforehand (you can't even compile it alone), it's something that fills > in missing C functions that are standard in most recent systems (plus > some added functionality that we use in some plugins). That's why it's > bundled with Nagios-plugins, and also why we include more modules than > we need on our own development systems. > Actually no. Most of the installations I did was with the 1.3.1 release of the plugins which, for quite a long time, was the most portable release available. >>> | If there are bugs in gnulib, you'll have no part of it if it's not part of >>> | the stuff you imported (which, by the sound of it, is unlikely). >>> >>> What do you mean?? >>> >> I mean "remove the unused sourcecode from the repository". Right now there's >> quite a lot of it, as stated before. > > I agree with you, we could map out all functions used in Nagios-plugins > and remove Gnulib modules (if any) that implement functions we don't > use. IIRC I cleaned up the most obvious ones in my last sync, but unless > you can give me some automated tools and/or nifty oneliners that can > make this a 10-minute job, it's likely that I'll rather work on actual > bugfixes and code enhancements that on cleaning up Gnulib modules - at > least for the foreseeable future. > Letting cleanup wait means it'll get bigger. Todays enhancements are the cruft of tomorrow ;-) > If you have that little extra time to clean it up your contribution will > be more than welcome ;) > I'll see what I can do. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Mon Aug 25 13:43:24 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Aug 2008 11:43:24 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1894496 ] check_http: more than one status code Message-ID: Patches item #1894496, was opened at 2008-02-15 16:06 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&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: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: more than one status code Initial Comment: This patch enhances the check_http plugin to accecpt more than one status code. Example.: check_http -e 200,300,301,302,304,401,403,404 If the webserver returns any of these codes, the check is ok, otherwise critical. This patch further changes the output if a not expected status code occurs, ex.: Invalid HTTP response received from host on port 9452 "HTTP/1.1 500 Internal Server Error" Patch has been tested on Linux. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-08-25 13:43 Message: Logged In: YES user_id=759506 Originator: NO Committed to SVN, thanks a lot for the patch. ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-25 00:00 Message: Logged In: YES user_id=1936413 Originator: YES Sry, I'm unable to upload the patch: File Upload: ArtifactFile: Could not open file for writing The patch can be downloaded here: http://www.nierlein.com/check_http.extented_status_codes.diff.4 ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-24 23:56 Message: Logged In: YES user_id=1936413 Originator: YES Attached new patch file. ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-08-24 23:53 Message: Logged In: YES user_id=1936413 Originator: YES Added 2 tests to plugins/tests/check_http.t ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 19:04 Message: Logged In: YES user_id=759506 Originator: NO And here's another version which fixes the memory leak I introduced with my previous version :-) File Added: check_http.extented_status_codes.diff.3 ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-08-22 17:48 Message: Logged In: YES user_id=759506 Originator: NO This feature sounds useful to me. I attached a modified version of the patch which allows for specifying strings which are longer or shorter than 3 characters via "-e" (this is required for backward compatibility), updates the "--help" output as well as the NEWS file, and uses check_http.c's coding/indentation style. Thanks a lot! File Added: check_http.extented_status_codes.diff.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1894496&group_id=29880 From thomas at zango.com Mon Aug 25 21:23:54 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 25 Aug 2008 15:23:54 -0400 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48B273FB.3040303@op5.se> References: <200808221556.18926.waja@cyconet.org> <2d87d51a4cce2da242adce8aca2c4ecf@altinity.com> <48AED6AA.8020606@op5.se> <48AF11D5.20902@zango.com> <48AF16C5.20300@op5.se> <48AF2706.50904@zango.com> <48AF4422.30204@op5.se> <48B240D8.30808@aei.ca> <48B273FB.3040303@op5.se> Message-ID: <48B306CA.9020906@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson wrote: | Thomas Guyot-Sionnest wrote: |> I agree with you, we could map out all functions used in Nagios-plugins |> and remove Gnulib modules (if any) that implement functions we don't |> use. IIRC I cleaned up the most obvious ones in my last sync, but unless |> you can give me some automated tools and/or nifty oneliners that can |> make this a 10-minute job, it's likely that I'll rather work on actual |> bugfixes and code enhancements that on cleaning up Gnulib modules - at |> least for the foreseeable future. |> | | Letting cleanup wait means it'll get bigger. Todays enhancements are the | cruft of tomorrow ;-) Not really... Keep in mind that unneeded code just won't be used during the build process. Almost everything regarding gnulib is automated. when we want to add/remove/update gnulib modules we just run the gnulib-tool script and it does the job. It will make no difference if we remove unneeded code now or later FYI we only use a (relatively) tiny subset of available Gnulib modules and I'm confident most of them are there for a reason. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIswbK6dZ+Kt5BchYRAsf1AKDu0yFqucXsJgI72mpXJjqygXAOUgCfZy0j 6WY0dkwX6rqGoSGCOWXo+K0= =8PJ8 -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Aug 26 15:47:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Aug 2008 13:47:48 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2075933 ] check_disk segfault on freebsd 7 if using -p option Message-ID: Bugs item #2075933, was opened at 2008-08-26 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Coletta (creatore) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk segfault on freebsd 7 if using -p option Initial Comment: By using check_disk plugin on FreeBSD 7 with -p option it causes a segfault. The latest head CVS does not fix the problem. [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382811, available_to_root=1503833, used=8942, fsp.fsu_files=400382, fsp.fsu_ffree=398157 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Segmentation fault: 11 (core dumped) I've found that the segfault happens at this line on t he check_disk.c: 359: temp_result = get_status(dfree_inodes_percent, path->freeinodes_percent); [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -V check_disk v1991 (nagios-plugins 1.4.12) [root at server /]# uname -a FreeBSD server.***.** 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root at server /]# gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 From noreply at sourceforge.net Wed Aug 27 03:31:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Aug 2008 01:31:15 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2075933 ] check_disk segfault on freebsd 7 if using -p option Message-ID: Bugs item #2075933, was opened at 2008-08-26 09:47 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Coletta (creatore) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk segfault on freebsd 7 if using -p option Initial Comment: By using check_disk plugin on FreeBSD 7 with -p option it causes a segfault. The latest head CVS does not fix the problem. [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382811, available_to_root=1503833, used=8942, fsp.fsu_files=400382, fsp.fsu_ffree=398157 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Segmentation fault: 11 (core dumped) I've found that the segfault happens at this line on t he check_disk.c: 359: temp_result = get_status(dfree_inodes_percent, path->freeinodes_percent); [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -V check_disk v1991 (nagios-plugins 1.4.12) [root at server /]# uname -a FreeBSD server.***.** 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root at server /]# gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-08-26 21:31 Message: Logged In: YES user_id=375623 Originator: NO Hi, Given the line you mentioned, it looks more like the segfault happened inside the get_status() function because temp_result is an integer. Could you try getting a backtrace from gdb? Run it from the source tree of nagios-plugins if possible. i.e.: $ gdb plugins/check_disk (gdb) run -w 20% -c 10% -vvv -p /var (gdb) bt And sent the full output of gdb. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 From noreply at sourceforge.net Wed Aug 27 11:00:56 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Aug 2008 09:00:56 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2075933 ] check_disk segfault on freebsd 7 if using -p option Message-ID: Bugs item #2075933, was opened at 2008-08-26 15:47 Message generated for change (Comment added) made by creatore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: snapshot tarball Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefano Coletta (creatore) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk segfault on freebsd 7 if using -p option Initial Comment: By using check_disk plugin on FreeBSD 7 with -p option it causes a segfault. The latest head CVS does not fix the problem. [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382811, available_to_root=1503833, used=8942, fsp.fsu_files=400382, fsp.fsu_ffree=398157 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Segmentation fault: 11 (core dumped) I've found that the segfault happens at this line on t he check_disk.c: 359: temp_result = get_status(dfree_inodes_percent, path->freeinodes_percent); [root at server /usr/local/nagios/libexec]# /usr/local/nagios/libexec/check_disk -V check_disk v1991 (nagios-plugins 1.4.12) [root at server /]# uname -a FreeBSD server.***.** 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root at server /]# gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ---------------------------------------------------------------------- >Comment By: Stefano Coletta (creatore) Date: 2008-08-27 11:00 Message: Logged In: YES user_id=327996 Originator: YES rtp# gdb plugins/check_disk GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run -w 20% -c 10% -vvv -p /var Starting program: /usr/home/*******/nagios-plugins-1.4.12/plugins/check_disk -w 20% -c 10% -vvv -p /var For /var, total=1512775, available=1382783, available_to_root=1503805, used=8970, fsp.fsu_files=400382, fsp.fsu_ffree=398149 For /var, used_pct=1 free_pct=99 used_units=17 free_units=2700 total_units=2954 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=2048 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Program received signal SIGSEGV, Segmentation fault. check_range (value=99, my_range=0x424d) at utils_base.c:168 168 if (my_range->alert_on == INSIDE) { (gdb) bt #0 check_range (value=99, my_range=0x424d) at utils_base.c:168 #1 0x0804cf83 in get_status (value=99, my_thresholds=0x2820b0ac) at utils_base.c:201 #2 0x0804b405 in main (argc=Error accessing memory address 0x0: Bad address. ) at check_disk.c:359 ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-27 03:31 Message: Logged In: YES user_id=375623 Originator: NO Hi, Given the line you mentioned, it looks more like the segfault happened inside the get_status() function because temp_result is an integer. Could you try getting a backtrace from gdb? Run it from the source tree of nagios-plugins if possible. i.e.: $ gdb plugins/check_disk (gdb) run -w 20% -c 10% -vvv -p /var (gdb) bt And sent the full output of gdb. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2075933&group_id=29880 From hrpoliveira at gmail.com Thu Aug 28 15:45:06 2008 From: hrpoliveira at gmail.com (Helder Oliveira) Date: Thu, 28 Aug 2008 14:45:06 +0100 Subject: [Nagiosplug-devel] Got a direction for me ? Message-ID: Hi all, I'm starting working with nagios, i am a experienced Linux user and i feel very comfortable with perl, i have googledded a lot and found some stuff how to start developing plugins for nagios but im asking this list if someone got recomendations for me, maybe some interesting links that can save some hours around possible problems, im refering to the little hacks and tricks that each technology has. Without more i leave you all. Regars Helder Oliveira -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at ena.com Thu Aug 28 16:13:17 2008 From: marc at ena.com (Marc Powell) Date: Thu, 28 Aug 2008 09:13:17 -0500 Subject: [Nagiosplug-devel] Got a direction for me ? In-Reply-To: References: Message-ID: <4527CEDB-9738-4457-A412-8D959567D482@ena.com> On Aug 28, 2008, at 8:45 AM, Helder Oliveira wrote: > Hi all, > > I'm starting working with nagios, i am a experienced Linux user and > i feel very comfortable with perl, i have googledded a lot and found > some stuff how to start developing plugins for nagios but im asking > this list if someone got recomendations for me, maybe some > interesting links that can save some hours around possible problems, > im refering to the little hacks and tricks that each technology has. Have you seen the Developer Guidelines? http://nagiosplug.sourceforge.net/developer-guidelines.html -- Marc From hrpoliveira at gmail.com Thu Aug 28 16:52:57 2008 From: hrpoliveira at gmail.com (Helder Oliveira) Date: Thu, 28 Aug 2008 15:52:57 +0100 Subject: [Nagiosplug-devel] Got a direction for me ? In-Reply-To: <4527CEDB-9738-4457-A412-8D959567D482@ena.com> References: <4527CEDB-9738-4457-A412-8D959567D482@ena.com> Message-ID: Yes i did read it already, i have also found some good documentation on ibm but now i have another question. I have a background in C, Python, Perl etc etc, what would be the best language for writing plugins since both 3 can be used for it.Note Thanks On Thu, Aug 28, 2008 at 3:13 PM, Marc Powell wrote: > > On Aug 28, 2008, at 8:45 AM, Helder Oliveira wrote: > > > Hi all, > > > > I'm starting working with nagios, i am a experienced Linux user and > > i feel very comfortable with perl, i have googledded a lot and found > > some stuff how to start developing plugins for nagios but im asking > > this list if someone got recomendations for me, maybe some > > interesting links that can save some hours around possible problems, > > im refering to the little hacks and tricks that each technology has. > > Have you seen the Developer Guidelines? > http://nagiosplug.sourceforge.net/developer-guidelines.html > > -- > Marc > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at richhorner.com Thu Aug 28 17:55:21 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Thu, 28 Aug 2008 11:55:21 -0400 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins Message-ID: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> Hi, I'm having problems implementing a timeout in a BASH plugin. I know how to implement a timeout in BASH. Basically, you setup a trap for the USR1 signal and then start a backgrounded process in a subshell that sleeps for $TIMEOUT seconds and then checks if the parent process is still running. If it is, it sends the USR1 signal which is caught and the script cleans itself up. Here is the code to do that: function cleanup { exit $1 } function timeout { echo "UNKNOWN - script timed out after $MAXTIME seconds." cleanup $STATE_UNKNOWN } # since we've processed the options which potentially set the timeout limit, we can setup a timeout trap now trap timeout USR1 ( sleep $TIMELIMIT; if [ `pgrep -U $USER -f "$SCRIPT" | grep -c ^$$$` -gt 0 ] ; then kill -USR1 $$ ; fi; ) & # do script work here trap - USR1 This works fine locally. I've used this in a number of scripts. However, it doesn't work over NRPE. When I put this in a plugin script, the subshell won't run in a background when invoked by NRPE. I'll give a simpler example to show exactly the problem: trap timeout USR1 ( sleep 6 ; ) & trap - USR1 If I run that chunk of code locally, its runtime is less than a second. If I run it over NRPE, it's runtime is over 6 seconds because it is not backgrounding the sleep call. It's as if there's a wait somewhere (there's not). So, my questions are: 1) Is this no-backgrounding thing an NRPE thing or is it some BASH thing that's occurring because there's already no controlling terminal or ??? 2) Can this be made to work in BASH or do I need to use C or Perl (both of which I know, just not nearly as well as I know BASH)? Thanks, Rich(ard) -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso http://richhorner.com From nagios at babar.us Thu Aug 28 19:11:27 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Thu, 28 Aug 2008 19:11:27 +0200 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> Message-ID: <20080828171127.GA29651@mail.babar.us> On Thu, Aug 28, 2008 at 11:55:21AM -0400, Richard Edward Horner wrote: > ( sleep $TIMELIMIT; if [ `pgrep -U $USER -f "$SCRIPT" | grep -c ^$$$` > -gt 0 ] ; then kill -USR1 $$ ; fi; ) & Did you try to simply "nohup" it, so something like: ( exec >/dev/null;exec 2>&1;exec <&1;sleep $TIMELIMIT; if ... > So, my questions are: > > 1) Is this no-backgrounding thing an NRPE thing or is it some BASH > thing that's occurring because there's already no controlling terminal > or ??? > > 2) Can this be made to work in BASH or do I need to use C or Perl > (both of which I know, just not nearly as well as I know BASH)? Because I'd think NRPE waits for the tty to be freed, and your background process locks it. Or play with huponexit, but I'm not sure it will work here. By the way, it works exactly like that in ssh: $ ssh some.host "(sleep 6)&date" Takes 6 seconds after date. $ ssh babar.us "(exec >/dev/null;exec 2>&1;exec <&1;sleep 6)&date" Returns after date -- Babar. From webknowledge at gmail.com Fri Aug 29 02:29:22 2008 From: webknowledge at gmail.com (Marcel) Date: Thu, 28 Aug 2008 21:29:22 -0300 Subject: [Nagiosplug-devel] Got a direction for me ? In-Reply-To: References: <4527CEDB-9738-4457-A412-8D959567D482@ena.com> Message-ID: <2dfcbd1b0808281729p21d4496bna69d13144a2d2c67@mail.gmail.com> The basics of the plugin engine is that it should run and complete probing as fast as it could. So the better the code, the better would be for nagios. So i think my answer is: You can do with whatever language you can. I only use perl, since it's development cycle is very short and because I have no low end hardware concerning performance issues. Even have bash scripts that act as plugins. Have some perl plugins, and all I have of C plugins are from the standard distribution. Again, if you will be monitoring tens of thousands of objects and have little budget for high-end servers, consider writing plugins that does not have overheads like interpreting the script, generating bytecode, executing and finishing, the fast it ends, the better it'll be to nagios. On Thu, Aug 28, 2008 at 11:52 AM, Helder Oliveira wrote: > Yes i did read it already, i have also found some good documentation on ibm > but now i have another question. > I have a background in C, Python, Perl etc etc, what would be the best > language for writing plugins since both 3 can be used for it.Note > > Thanks > > > On Thu, Aug 28, 2008 at 3:13 PM, Marc Powell wrote: > >> >> On Aug 28, 2008, at 8:45 AM, Helder Oliveira wrote: >> >> > Hi all, >> > >> > I'm starting working with nagios, i am a experienced Linux user and >> > i feel very comfortable with perl, i have googledded a lot and found >> > some stuff how to start developing plugins for nagios but im asking >> > this list if someone got recomendations for me, maybe some >> > interesting links that can save some hours around possible problems, >> > im refering to the little hacks and tricks that each technology has. >> >> Have you seen the Developer Guidelines? >> http://nagiosplug.sourceforge.net/developer-guidelines.html >> >> -- >> Marc >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________________ >> 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 >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Fri Aug 29 04:04:29 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 28 Aug 2008 22:04:29 -0400 Subject: [Nagiosplug-devel] Got a direction for me ? In-Reply-To: <2dfcbd1b0808281729p21d4496bna69d13144a2d2c67@mail.gmail.com> References: <4527CEDB-9738-4457-A412-8D959567D482@ena.com> <2dfcbd1b0808281729p21d4496bna69d13144a2d2c67@mail.gmail.com> Message-ID: <48B7592D.5080206@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/08/08 08:29 PM, Marcel wrote: > The basics of the plugin engine is that it should run and complete > probing as fast as it could. So the better the code, the better would be > for nagios. So i think my answer is: You can do with whatever language > you can. I only use perl, since it's development cycle is very short and > because I have no low end hardware concerning performance issues. Even > have bash scripts that act as plugins. Have some perl plugins, and all I > have of C plugins are from the standard distribution. Again, if you will > be monitoring tens of thousands of objects and have little budget for > high-end servers, consider writing plugins that does not have overheads > like interpreting the script, generating bytecode, executing and > finishing, the fast it ends, the better it'll be to nagios. I will add that regarding Perl, you can get enormous performance boost by using ePN (embedded Perl interpreter) and perlcache, but your plugins will need very strict programming style to work well (In an extreme case I had to comment out "use strict and "use warnings", although it did not complain with them on the command line). It should also be noted that some people have uncontrollable memory leaks with ePN. It is not known whenever these leaks are caused by the system/perl/library versions of by poor plugin code, but on my system although by looking closely I did notice small leaks (most notably on HUPs, but you can kill and restart instead). They are not significant enough to even worry about them (Nagios can run for months with >250 Perl checks per minute without loosing much memory, i did not even notice before looking really closely). I'm not a Python coder (just started reading some manuals two weeks ago) but I'm wondering how pre-compiled Python bytecode would compare to Perl ePN. If you ever have the opportunity to swap a highly used Perl plugin (with ePN and perlcache) with a Python plugin doing the same job (and of comparable quality) and compare the load, I would be glad to see the difference. If you're interested, see this post (by me) about difference in cpu time between ePN and non-ePN plugins: http://mersenne.org/gimps/mprime256-linux64.tar.gz - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIt1kt6dZ+Kt5BchYRApavAKCMGu9TtMUFnQTGuytk343eBHJ+iACgwRmO Smgm0suB3cv19S+3sqiViOA= =MyVn -----END PGP SIGNATURE----- From noreply at sourceforge.net Fri Aug 29 06:12:59 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 04:12:59 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-08-29 00:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 04:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Fri Aug 29 07:45:40 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 05:45:40 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2081810 ] check_rpc return code on false libpath Message-ID: Bugs item #2081810, was opened at 2008-08-29 05:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2081810&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: Volker (neuntoeter) Assigned to: Nobody/Anonymous (nobody) Summary: check_rpc return code on false libpath Initial Comment: Hi, I noticed a problem with check_rpc. If check_rpc can't find the utils.pm package in the given libpath (e.g. the utils.pm is not in lib "/usr/local/nagios/libexec";) and check_rpc is executed in nagios, the return code in Nagios is 2 -> Critical and the Plugin Output shown in Nagios only shows (null). The correct behaviour should be: Status: Unknown (3) Output: Can't find utils.pm in lib path. I spent nearly a whole day finding the reason why check_rpc did not work. It took so long to find out, because I didn't get any error when executing it manually in the shell (the utils.pm was in the working directory). A perl error message an a status Unknown could have saved me a lot of time. PS: I used version from 1.4.9 regards, Volker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2081810&group_id=29880 From noreply at sourceforge.net Fri Aug 29 10:53:32 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 08:53:32 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2082067 ] check_mailq: allow arbitrary command for mailq Message-ID: Patches item #2082067, was opened at 2008-08-29 10:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2082067&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: uspoerlein (uspoerlein) Assigned to: Nobody/Anonymous (nobody) Summary: check_mailq: allow arbitrary command for mailq Initial Comment: Hi, the current approach in check_mailq is severly limitting, if you want to get mailq output from different MTA instances or use 'sudo mailq' for example. The fix, IMHO, is to let the user override the path+arguments to the mailq call. The attached patch solves this, although I had to remove the "-x $MAILQ" check, which is rather crude, anyway. This patch should be a solution to the bugs #1878144 (use sudo mail), #1773779 (write a postfix mailq wrapper script, just like we do), and #880904. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2082067&group_id=29880 From noreply at sourceforge.net Fri Aug 29 16:10:15 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 14:10:15 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2082501 ] check_http redirect sporadically endless in version 1.4.12 Message-ID: Bugs item #2082501, was opened at 2008-08-29 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Wasser (ewasser) Assigned to: Nobody/Anonymous (nobody) Summary: check_http redirect sporadically endless in version 1.4.12 Initial Comment: The check_http plugin in version 1.4.12 is brocken. Version 1.4.11 works fine. The plugin messes up the redirection url. The redirection doesn't end and it will result in a "WARNING". Here's the sample output, the binarys were taken from DAG http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/ but I also recompiled the version 1.4.12 from the official sources. Plugin Version (-V output): check_http v1991 (nagios-plugins 1.4.12) Plugin Name: check_http Plugin Commandline showing issues: see down below Operating System: Linux Architecture: i386, x86_64 Compiler: gcc WORKING VERSION 1.4.11: % ./check_http-1.4.11-1 --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.552 second response time |time=0.551658s;;;0.000000 size=61131B;;;0 This is working everytime. DEFECT VERSION 1.4.12: The error itself is not consistent: B-( % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 1.525 second response time |time=1.525200s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.173 second response time |time=0.172721s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 2.788 second response time |time=2.788378s;;;0.000000 size=61217B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.169 second response time |time=0.168843s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ As you can see the error messages shows a messed up error message (a missing '/'). I think it depends on the header structure/size/order of the HTTP response message. Others URLs are failing too with the version 1.4.12 so I think it's not an apache problem on the other side. Greetings and thanks for the good work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 From noreply at sourceforge.net Fri Aug 29 16:15:54 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 14:15:54 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2082501 ] check_http redirects sporadically endless in version 1.4.12s Message-ID: Bugs item #2082501, was opened at 2008-08-29 16:10 Message generated for change (Settings changed) made by ewasser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Wasser (ewasser) Assigned to: Nobody/Anonymous (nobody) >Summary: check_http redirects sporadically endless in version 1.4.12s Initial Comment: The check_http plugin in version 1.4.12 is brocken. Version 1.4.11 works fine. The plugin messes up the redirection url. The redirection doesn't end and it will result in a "WARNING". Here's the sample output, the binarys were taken from DAG http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/ but I also recompiled the version 1.4.12 from the official sources. Plugin Version (-V output): check_http v1991 (nagios-plugins 1.4.12) Plugin Name: check_http Plugin Commandline showing issues: see down below Operating System: Linux Architecture: i386, x86_64 Compiler: gcc WORKING VERSION 1.4.11: % ./check_http-1.4.11-1 --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.552 second response time |time=0.551658s;;;0.000000 size=61131B;;;0 This is working everytime. DEFECT VERSION 1.4.12: The error itself is not consistent: B-( % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 1.525 second response time |time=1.525200s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.173 second response time |time=0.172721s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 2.788 second response time |time=2.788378s;;;0.000000 size=61217B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.169 second response time |time=0.168843s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ As you can see the error messages shows a messed up error message (a missing '/'). I think it depends on the header structure/size/order of the HTTP response message. Others URLs are failing too with the version 1.4.12 so I think it's not an apache problem on the other side. Greetings and thanks for the good work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 From noreply at sourceforge.net Fri Aug 29 16:17:16 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 14:17:16 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2082501 ] check_http redirects sporadically endless in version 1.4.12 Message-ID: Bugs item #2082501, was opened at 2008-08-29 16:10 Message generated for change (Settings changed) made by ewasser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Wasser (ewasser) Assigned to: Nobody/Anonymous (nobody) >Summary: check_http redirects sporadically endless in version 1.4.12 Initial Comment: The check_http plugin in version 1.4.12 is brocken. Version 1.4.11 works fine. The plugin messes up the redirection url. The redirection doesn't end and it will result in a "WARNING". Here's the sample output, the binarys were taken from DAG http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/ but I also recompiled the version 1.4.12 from the official sources. Plugin Version (-V output): check_http v1991 (nagios-plugins 1.4.12) Plugin Name: check_http Plugin Commandline showing issues: see down below Operating System: Linux Architecture: i386, x86_64 Compiler: gcc WORKING VERSION 1.4.11: % ./check_http-1.4.11-1 --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.552 second response time |time=0.551658s;;;0.000000 size=61131B;;;0 This is working everytime. DEFECT VERSION 1.4.12: The error itself is not consistent: B-( % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 1.525 second response time |time=1.525200s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.173 second response time |time=0.172721s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 2.788 second response time |time=2.788378s;;;0.000000 size=61217B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.169 second response time |time=0.168843s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ As you can see the error messages shows a messed up error message (a missing '/'). I think it depends on the header structure/size/order of the HTTP response message. Others URLs are failing too with the version 1.4.12 so I think it's not an apache problem on the other side. Greetings and thanks for the good work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 From noreply at sourceforge.net Fri Aug 29 18:25:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 16:25:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2081810 ] check_rpc return code on false libpath Message-ID: Bugs item #2081810, was opened at 2008-08-29 01:45 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2081810&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Volker (neuntoeter) Assigned to: Nobody/Anonymous (nobody) Summary: check_rpc return code on false libpath Initial Comment: Hi, I noticed a problem with check_rpc. If check_rpc can't find the utils.pm package in the given libpath (e.g. the utils.pm is not in lib "/usr/local/nagios/libexec";) and check_rpc is executed in nagios, the return code in Nagios is 2 -> Critical and the Plugin Output shown in Nagios only shows (null). The correct behaviour should be: Status: Unknown (3) Output: Can't find utils.pm in lib path. I spent nearly a whole day finding the reason why check_rpc did not work. It took so long to find out, because I didn't get any error when executing it manually in the shell (the utils.pm was in the working directory). A perl error message an a status Unknown could have saved me a lot of time. PS: I used version from 1.4.9 regards, Volker ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2008-08-29 12:25 Message: Logged In: YES user_id=375623 Originator: NO Did you try running the plugin by hands? It should print a clear error about missing utils.pm. This is Perl's error code and message, not the plugin's. IMO it make absolutely no sense to add an eval in there to catch this error, especially since it shouldn't happen under normal circumstances and the error message is clear from the command line. It's also the job of utils.pm to define Nagios error codes, so handling that would also require duplicate "fallback" definitions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2081810&group_id=29880 From rich at richhorner.com Fri Aug 29 18:27:22 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Fri, 29 Aug 2008 12:27:22 -0400 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <20080828171127.GA29651@mail.babar.us> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> <20080828171127.GA29651@mail.babar.us> Message-ID: <7a65a83a0808290927k5fe99889nc2047cd5e2548022@mail.gmail.com> Babar, Thanks for the response. I wasn't able to make any headway on this. I'll guess I'll just rewrite my checks in Perl. Thanks, Rich(ard) On Thu, Aug 28, 2008 at 1:11 PM, Olivier 'Babar' Raginel wrote: > On Thu, Aug 28, 2008 at 11:55:21AM -0400, Richard Edward Horner wrote: >> ( sleep $TIMELIMIT; if [ `pgrep -U $USER -f "$SCRIPT" | grep -c ^$$$` >> -gt 0 ] ; then kill -USR1 $$ ; fi; ) & > > > Did you try to simply "nohup" it, so something like: > > ( exec >/dev/null;exec 2>&1;exec <&1;sleep $TIMELIMIT; if ... > >> So, my questions are: >> >> 1) Is this no-backgrounding thing an NRPE thing or is it some BASH >> thing that's occurring because there's already no controlling terminal >> or ??? >> >> 2) Can this be made to work in BASH or do I need to use C or Perl >> (both of which I know, just not nearly as well as I know BASH)? > > Because I'd think NRPE waits for the tty to be freed, and your > background process locks it. > Or play with huponexit, but I'm not sure it will work here. > > By the way, it works exactly like that in ssh: > $ ssh some.host "(sleep 6)&date" > Takes 6 seconds after date. > $ ssh babar.us "(exec >/dev/null;exec 2>&1;exec <&1;sleep 6)&date" > Returns after date > > -- > Babar. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > 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 http://richhorner.com From noreply at sourceforge.net Fri Aug 29 17:43:34 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Aug 2008 15:43:34 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2082501 ] check_http redirects sporadically endless in version 1.4.12 Message-ID: Bugs item #2082501, was opened at 2008-08-29 16:10 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Wasser (ewasser) Assigned to: Nobody/Anonymous (nobody) Summary: check_http redirects sporadically endless in version 1.4.12 Initial Comment: The check_http plugin in version 1.4.12 is brocken. Version 1.4.11 works fine. The plugin messes up the redirection url. The redirection doesn't end and it will result in a "WARNING". Here's the sample output, the binarys were taken from DAG http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/ but I also recompiled the version 1.4.12 from the official sources. Plugin Version (-V output): check_http v1991 (nagios-plugins 1.4.12) Plugin Name: check_http Plugin Commandline showing issues: see down below Operating System: Linux Architecture: i386, x86_64 Compiler: gcc WORKING VERSION 1.4.11: % ./check_http-1.4.11-1 --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.552 second response time |time=0.551658s;;;0.000000 size=61131B;;;0 This is working everytime. DEFECT VERSION 1.4.12: The error itself is not consistent: B-( % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 1.525 second response time |time=1.525200s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.173 second response time |time=0.172721s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 2.788 second response time |time=2.788378s;;;0.000000 size=61217B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.169 second response time |time=0.168843s;;;0.000000 size=61216B;;;0 % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ % ./plugins/check_http --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP WARNING - maximum redirection depth 15 exceeded - http://www.taxi-blog.de:80wordpress/ As you can see the error messages shows a messed up error message (a missing '/'). I think it depends on the header structure/size/order of the HTTP response message. Others URLs are failing too with the version 1.4.12 so I think it's not an apache problem on the other side. Greetings and thanks for the good work. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-08-29 17:43 Message: Logged In: YES user_id=759506 Originator: NO There's no obvious change in the code between 1.4.11 and 1.4.12 which could cause this, and so far, I can't reproduce the problem: % check_http --onredirect=critical -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.591 second response time |time=0.590834s;;;0.000000 size=61229B;;;0 That is, the server doesn't actually redirect this URL. Using "-u /wordpress" without a trailing slash redirects to /wordpress/, though. I tried the following call 100 times in a loop and always got an OK: % check_http -H www.taxi-blog.de --onredirect=follow -H www.taxi-blog.de -u /wordpress/ -s Impressum -t 30 HTTP OK HTTP/1.1 200 OK - 0.761 second response time |time=0.760912s;;;0.000000 size=61229B;;;0 So, could you please try to reproduce the problem using "--verbose" and post the output (up to the **** CONTENT **** part)? (It would be nice if you could use the version compiled from the official sources for this.) Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2082501&group_id=29880 From thomas at zango.com Fri Aug 29 19:26:00 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 29 Aug 2008 13:26:00 -0400 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <7a65a83a0808290927k5fe99889nc2047cd5e2548022@mail.gmail.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> <20080828171127.GA29651@mail.babar.us> <7a65a83a0808290927k5fe99889nc2047cd5e2548022@mail.gmail.com> Message-ID: <48B83128.3070802@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Edward Horner wrote: > Babar, > > Thanks for the response. I wasn't able to make any headway on this. > I'll guess I'll just rewrite my checks in Perl. You could probably use this (I didn't tested), but it may leave stall processes behind: #!/usr/bin/perl use strict; use warnings; $SIG{'ALRM'} = sub { print "CRITICAL: foo\n"; exit 2; }; alarm(60); my $text = `/bin/bash /path/to/plugin.sh`; my $result = $?>>8; alarm(0); print $text; return $result; __END__ If you need to kill stale processes, it's a bit more complicated - look at my check_rsync v1.02 plugin for an example. http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2094.html;d=1 - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuDEo6dZ+Kt5BchYRAnAeAJ4vFtPdukgoDqfdHgzKM7PW702kVwCePFLI ENJCFwf3+ZHv9YbR90G7YNk= =iXQd -----END PGP SIGNATURE----- From rich at richhorner.com Fri Aug 29 19:34:17 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Fri, 29 Aug 2008 13:34:17 -0400 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <48B83128.3070802@zango.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> <20080828171127.GA29651@mail.babar.us> <7a65a83a0808290927k5fe99889nc2047cd5e2548022@mail.gmail.com> <48B83128.3070802@zango.com> Message-ID: <7a65a83a0808291034m74892ees3e1d34723119d33b@mail.gmail.com> Thanks for the tip, Thomas. I'll check it out. Rich(ard) On Fri, Aug 29, 2008 at 1:26 PM, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Richard Edward Horner wrote: >> Babar, >> >> Thanks for the response. I wasn't able to make any headway on this. >> I'll guess I'll just rewrite my checks in Perl. > > You could probably use this (I didn't tested), but it may leave stall > processes behind: > > #!/usr/bin/perl > > use strict; > use warnings; > > $SIG{'ALRM'} = sub { > print "CRITICAL: foo\n"; > exit 2; > }; > > alarm(60); > my $text = `/bin/bash /path/to/plugin.sh`; > my $result = $?>>8; > alarm(0); > > print $text; > return $result; > __END__ > > If you need to kill stale processes, it's a bit more complicated - look > at my check_rsync v1.02 plugin for an example. > > http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2094.html;d=1 > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIuDEo6dZ+Kt5BchYRAnAeAJ4vFtPdukgoDqfdHgzKM7PW702kVwCePFLI > ENJCFwf3+ZHv9YbR90G7YNk= > =iXQd > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > 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 http://richhorner.com From frimik at gmail.com Sat Aug 30 03:25:25 2008 From: frimik at gmail.com (Mikael Fridh) Date: Sat, 30 Aug 2008 03:25:25 +0200 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> Message-ID: <323f67830808291825s9ca07acn919a12e53ffe6df1@mail.gmail.com> On Thu, Aug 28, 2008 at 5:55 PM, Richard Edward Horner wrote: > > trap timeout USR1 > ( sleep 6 ; ) & > trap - USR1 > > If I run that chunk of code locally, its runtime is less than a > second. If I run it over NRPE, it's runtime is over 6 seconds because > it is not backgrounding the sleep call. It's as if there's a wait > somewhere (there's not). A process won't fully detach unless you redirect all input and output, like this: ( sleep 6 ; ) /dev/null -- Mike From rich at richhorner.com Sat Aug 30 04:01:15 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Fri, 29 Aug 2008 22:01:15 -0400 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <323f67830808291825s9ca07acn919a12e53ffe6df1@mail.gmail.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> <323f67830808291825s9ca07acn919a12e53ffe6df1@mail.gmail.com> Message-ID: <7a65a83a0808291901u53398e74qad30d118c4fd1390@mail.gmail.com> Ahh! Mike, you're right! Problem solved! Thank you! But I think you meant: ( sleep 6 ; ) /dev/null & not ( sleep 6 ; ) /dev/null Thanks, Rich(ard) On Fri, Aug 29, 2008 at 9:25 PM, Mikael Fridh wrote: > On Thu, Aug 28, 2008 at 5:55 PM, Richard Edward Horner > wrote: >> >> trap timeout USR1 >> ( sleep 6 ; ) & >> trap - USR1 >> >> If I run that chunk of code locally, its runtime is less than a >> second. If I run it over NRPE, it's runtime is over 6 seconds because >> it is not backgrounding the sleep call. It's as if there's a wait >> somewhere (there's not). > > A process won't fully detach unless you redirect all input and output, > like this: > ( sleep 6 ; ) /dev/null > > -- > Mike > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > 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 http://richhorner.com From nagios at babar.us Sat Aug 30 13:25:25 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Sat, 30 Aug 2008 13:25:25 +0200 Subject: [Nagiosplug-devel] Timeouts in BASH Plugins In-Reply-To: <7a65a83a0808291901u53398e74qad30d118c4fd1390@mail.gmail.com> References: <7a65a83a0808280855m6423967t7aab04bf0e7bb269@mail.gmail.com> <323f67830808291825s9ca07acn919a12e53ffe6df1@mail.gmail.com> <7a65a83a0808291901u53398e74qad30d118c4fd1390@mail.gmail.com> Message-ID: <20080830112525.GA29137@mail.babar.us> On Fri, Aug 29, 2008 at 10:01:15PM -0400, Richard Edward Horner wrote: > Ahh! Mike, you're right! Problem solved! Thank you! But I think you meant: > > ( sleep 6 ; ) /dev/null & Which is exactly what I suggested. Ok, I didn't use the &> shortcut, but... Anyway, problem solved you said, so all is well. -- Babar.