From noreply at sourceforge.net Fri Jun 1 04:20:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 19:20:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1117643 ] Problems compiling 1.4 on Solaris 8 x86 Message-ID: Bugs item #1117643, was opened at 2005-02-06 18:52 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117643&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jeremy Russell (ellipses) Assigned to: M. Sean Finney (seanius) Summary: Problems compiling 1.4 on Solaris 8 x86 Initial Comment: make errored on compling check_icmp. ---------------------------------------------- gcc -g -O2 -L. -R/usr/local/ssl/lib -L/usr/local/ssl/lib -o check_icmp check_icmp.o ../intl/libintl.a -liconv -lgen - lsocket -I/usr/local/ssl/include Undefined first referenced symbol in file gethostbyname check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) inet_addr check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) inet_ntoa check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) ld: fatal: Symbol referencing errors. No output written to check_icmp collect2: ld returned 1 exit status make[2]: *** [check_icmp] Error 1 make[2]: Leaving directory `/usr/local/support/src/monitor/nagios-plugins- 1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/support/src/monitor/nagios-plugins-1.4' make: *** [all] Error 2 ------------------------------------------ gcc -v Reading specs from /usr/local/lib/gcc-lib/i386-pc- solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) edited plugins/Makefile # diff Makefile Makefile.orig 419c419 < check_icmp_LDADD = -lnsl --- > check_icmp_LDADD = attaching config.log ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-31 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-17 07:24 Message: Logged In: YES user_id=1694341 Originator: NO Hi Jeremy, Have you tried the cvs that time? I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 13:24 Message: Logged In: YES user_id=226838 hi, there exists code in the configure script which should find cases where -lnsl/-lsocket is needed, so i'm wondering why it's not working for you. could you try compiling from the latest cvs? if you still have the problem, could you post your config.log? ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-02-07 15:02 Message: Logged In: YES user_id=395628 Dear Jeremy, I am writing to thank you for opening a tracker about this problem, which appears to be Solaris specific. The developers advice is to add _both_ -lnsl and -lsocket for Solaris compiles. Since all the Makefiles for the plugins are generated by autoconf/automake, there needs to be Solaris specific mods made to configure.in and perhaps plugin/Makefile.am for this to please everyone. In the meantime, others should do as you have and manually add the extra libraries for Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117643&group_id=29880 From noreply at sourceforge.net Fri Jun 1 04:20:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 19:20:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-822662 ] check_tcp does not return " TCP CRITICAL" Message-ID: Bugs item #822662, was opened at 2003-10-13 04:00 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=822662&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Hugo Monteiro (hvm_pt) Assigned to: Ton Voon (tonvoon) Summary: check_tcp does not return "TCP CRITICAL" Initial Comment: check_tcp plugin should return a "TCP CRITICAL: Connection refused by host" when the tcp service port checked is down. example: "check_tcp server1 -p 3128" (SQUID Port) If the squid service is down we get a "Connection refused by host" but we should get a "TCP CRITICAL: etc.." since this service is down. Because of this, Nagios puts this service in the critical services group, but we can't get any availability report because services checked by this plugin (using check_tcp xxx -p xxxx) are not returning valid exit codes/echoes: "TCP OK", "TCP WARNING" or "TCP CRITICAL". This service check not even appear has unknown!?!! ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-31 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-17 07:37 Message: Logged In: YES user_id=1694341 Originator: NO Hi Hugo, can you confirm that this problem still exists? I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: Chris Funderburg (funderburg) Date: 2005-05-19 05:54 Message: Logged In: YES user_id=10827 This still appears to not work even in CVS code. Is Nagios not being maintained anymore ? ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-10-13 09:23 Message: Logged In: YES user_id=10485 I believe if you check the contents of nagios-10-10-2003-00.log thru nagios-10-10-2003-23.log you would find that all the entries are for the same day but the logs have been truncated because they grew to be too long... What you need to do when doing reports is to tell it that it can go back through more logs by setting the "Backtracked Archives" to higher than the default (which for me is 2)... ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-10-13 08:48 Message: Logged In: YES user_id=664364 I had a problem with extra nagios logs being created (with - 23). It turned out to be an NTP problem on the server I was using. See http://www.nagios.org/faqs/viewfaq.php? faq_id=93 for the resolution. ---------------------------------------------------------------------- Comment By: Hugo Monteiro (hvm_pt) Date: 2003-10-13 08:37 Message: Logged In: YES user_id=12156 Additional notes: The exit code seems to be valid to NAGIOS process, it can process it well. The problem was that something broke the archived LOG, it appeared "nagios-10-10-2003-23.log" (notice the -23) instead of "nagios-10-10-2003-00.log". That was why this services didn't appear in the Availability Report. (I'm still searching what caused this.) Besides this, i've added the following lines to 'netutils.c' starting line 309: -- cut here -- printf ("CONNECTION CRITICAL: "); --- end cut --- So, if we cannot make a connection it will print something like CONNECTION CRITICAL: "+"Error message from the 'switch/case on the line below"' example: "CONNECTION CRITICAL: Connection refused by host." PS: Check all information i sent and see if this really is an check_tcp plugin issue, and something needs to be modified, or if this bug report can be closed. ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-10-13 06:28 Message: Logged In: YES user_id=10485 As I've done quite a few changes in the current CVS HEAD version of the check_tcp code I believe I know where this problem lies. It seems to be in the actual connection code and not in the processing of the reply as it never gets the connection socket to open. I'll look into it and see if this is possible to preface with "TCP CRITICAL" however the code to my knowledge DOES return the proper exit code it is just the human readable details that is failing to display. ---------------------------------------------------------------------- Comment By: Hugo Monteiro (hvm_pt) Date: 2003-10-13 04:46 Message: Logged In: YES user_id=12156 The problem seems to be in "netutils.c" file between line 308 and 320. Even if this errors are not known, a plugin should always return a known error (OK, WARNING, CRITICAL or UNKNOWN) if it sends anything besides this, it will break Nagios service information (reports, stats, etc.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=822662&group_id=29880 From noreply at sourceforge.net Fri Jun 1 04:20:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 19:20:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1144727 ] check_disk fails on Solaris with large available space Message-ID: Bugs item #1144727, was opened at 2005-02-20 02:44 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1144727&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: John-David Childs (diskmuncher) Assigned to: Ton Voon (tonvoon) Summary: check_disk fails on Solaris with large available space Initial Comment: check_disk returns a CRITICAL on Solaris (test 5.7 and 5.9) if a checked_filesystem actually has > 1TB of free space. This does NOT happen on Linux. Verifying functionality on IRIX. controldev [10:21am] plugins 69% df -k Filesystem kbytes used avail capacity Mounted on /proc 0 0 0 0% /proc /dev/dsk/c0t0d0s0 9075677 6666149 2318772 75% / fd 0 0 0 0% /dev/fd /dev/dsk/c0t0d0s4 482455 138924 295286 32% /var swap 1757696 79080 1678616 5% /tmp /dev/dsk/c0t0d0s6 6196234 6161 6128111 1% /ewrt /dev/dsk/c0t1d0s0 20652353 13923398 6522432 69% /bronze /dev/dsk/c0t1d0s1 20652353 4633312 15812518 23% /tools /dev/dsk/c0t1d0s4 29281179 23773695 5214673 83% /home opsnas1:/vol/home 1767421352 653768396 1113652956 37% /mnt controldev [10:23am] plugins 70% ./check_disk -w 10% -c 5% -e DISK CRITICAL - free space: /mnt 9007199254740993 MB (521854746624%);| /=6598MB;7975;8418;0;8862 /var=183MB;423;447;0;471 /tmp=77MB;1544;1630;0;1716 /ewrt=67MB;5445;5748;0;6051 /bronze=13799MB;18151;19159;0;20168 /tools=4727MB;18151;19159;0;20168 /home=23502MB;25734;27164;0;28594 /mnt=2735598MB;1553397;1639697;0;1725997 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-31 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-17 09:36 Message: Logged In: YES user_id=1694341 Originator: NO Hi John-David, have you tried newer versions of the plugins which don't rely on df any more? Please post a comment if the problem persists. I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-19 16:20 Message: Logged In: YES user_id=664364 John, Can you try this out with the latest snapshot at http://nagiosplug.sf.net/ snapshot please? There have been major changes to check_disk to sync it with coreutils' df command. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 19:23 Message: Logged In: YES user_id=226838 hi john, have you had the chance to look into this more? unfortunately i don't have access to a solaris system with > 1TB storage so my powers to debug are a bit diminished. i suspect some number may be truncated somewhere, either in check_disk.c (most likely) or fsusage.c (harder to read, but also less likely the source). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1144727&group_id=29880 From elliott at commscope.com Fri Jun 1 16:21:53 2007 From: elliott at commscope.com (elliott at commscope.com) Date: Fri, 1 Jun 2007 09:21:53 -0500 Subject: [Nagiosplug-devel] Idea to change nagios to accept xml output from plugins Message-ID: to all: This is more of a theorhetical question, but i am going to ask anyway. I believe that there would be a benefit to changing the standard plugin interface, and by default nrpe and associated programs to use xml as a communications standard. You would be able to intelligently send more differing types of data back from the plugin. The plugin would also be able to safely return html code (or xml code) that would allow you to offer more clickable information. Please let me know what you think of this idea. - keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Fri Jun 1 19:09:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 10:09:00 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1729581 ] check_ntp - fix for out of order associations Message-ID: Patches item #1729581, was opened at 2007-06-01 17:09 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=1729581&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clint Byrum (cbyrum) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp - fix for out of order associations Initial Comment: If ntpq returns associations after the sys.peer, it overwrites the jitter with (not parsed) [root at talk etc]# ntpq -np newskip remote refid st t when poll reach delay offset jitter ============================================================================== +10.10.1.237 132.239.1.6 2 - 15 64 36 0.001 2.005 0.114 +10.10.1.33 60.56.119.79 2 - 50 64 17 0.001 -12.981 2.129 *10.10.1.233 132.239.1.6 2 - 48 64 16 0.001 2.273 0.115 127.127.1.0 LOCAL(0) 10 l 62 64 377 0.000 0.000 0.001 [root at talk etc]# ../libexec/check_ntp -H newskip Argument "(not parsed)" isn't numeric in abs at ../libexec/check_ntp line 408. NTP OK: Offset 0.021792 secs, jitter (not parsed) msec, peer is stratum 2|offset=0.021792, jitter=0,peer_stratum=2 This patch does not address the fact that if there's no match, you'll still get the isn't numeric problem. However if there is a sys peer, it will record a numeric jitter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 From noreply at sourceforge.net Fri Jun 1 19:17:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 10:17:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1729581 ] check_ntp - fix for out of order associations Message-ID: Patches item #1729581, was opened at 2007-06-01 13:09 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Clint Byrum (cbyrum) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp - fix for out of order associations Initial Comment: If ntpq returns associations after the sys.peer, it overwrites the jitter with (not parsed) [root at talk etc]# ntpq -np newskip remote refid st t when poll reach delay offset jitter ============================================================================== +10.10.1.237 132.239.1.6 2 - 15 64 36 0.001 2.005 0.114 +10.10.1.33 60.56.119.79 2 - 50 64 17 0.001 -12.981 2.129 *10.10.1.233 132.239.1.6 2 - 48 64 16 0.001 2.273 0.115 127.127.1.0 LOCAL(0) 10 l 62 64 377 0.000 0.000 0.001 [root at talk etc]# ../libexec/check_ntp -H newskip Argument "(not parsed)" isn't numeric in abs at ../libexec/check_ntp line 408. NTP OK: Offset 0.021792 secs, jitter (not parsed) msec, peer is stratum 2|offset=0.021792, jitter=0,peer_stratum=2 This patch does not address the fact that if there's no match, you'll still get the isn't numeric problem. However if there is a sys peer, it will record a numeric jitter. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-06-01 13:17 Message: Logged In: YES user_id=375623 Originator: NO Which version of Nagios-plugins is that? We're installing a C-based plugin since a few releases now, so either you're using a very old release or you manually installing the Perl plugin which has many bugs and is unmaintained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 From noreply at sourceforge.net Fri Jun 1 19:43:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 10:43:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1729581 ] check_ntp - fix for out of order associations Message-ID: Patches item #1729581, was opened at 2007-06-01 17:09 Message generated for change (Comment added) made by cbyrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clint Byrum (cbyrum) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp - fix for out of order associations Initial Comment: If ntpq returns associations after the sys.peer, it overwrites the jitter with (not parsed) [root at talk etc]# ntpq -np newskip remote refid st t when poll reach delay offset jitter ============================================================================== +10.10.1.237 132.239.1.6 2 - 15 64 36 0.001 2.005 0.114 +10.10.1.33 60.56.119.79 2 - 50 64 17 0.001 -12.981 2.129 *10.10.1.233 132.239.1.6 2 - 48 64 16 0.001 2.273 0.115 127.127.1.0 LOCAL(0) 10 l 62 64 377 0.000 0.000 0.001 [root at talk etc]# ../libexec/check_ntp -H newskip Argument "(not parsed)" isn't numeric in abs at ../libexec/check_ntp line 408. NTP OK: Offset 0.021792 secs, jitter (not parsed) msec, peer is stratum 2|offset=0.021792, jitter=0,peer_stratum=2 This patch does not address the fact that if there's no match, you'll still get the isn't numeric problem. However if there is a sys peer, it will record a numeric jitter. ---------------------------------------------------------------------- >Comment By: Clint Byrum (cbyrum) Date: 2007-06-01 17:43 Message: Logged In: YES user_id=11247 Originator: YES I was using v1.4.3 of the plugins. I checked the perl file in CVS, but I didn't realize there was a C version in the latest plugins! Upgrading now. Thanks for the quick response! ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-06-01 17:17 Message: Logged In: YES user_id=375623 Originator: NO Which version of Nagios-plugins is that? We're installing a C-based plugin since a few releases now, so either you're using a very old release or you manually installing the Perl plugin which has many bugs and is unmaintained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Fri Jun 1 20:37:30 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 01 Jun 2007 20:37:30 +0200 Subject: [Nagiosplug-devel] Idea to change nagios to accept xml output from plugins In-Reply-To: References: Message-ID: <4660676A.9010109@mailing.kaufland-informationssysteme.com> elliott at commscope.com schrieb: > > to all: > This is more of a theorhetical question, but i am going to ask > anyway. > I believe that there would be a benefit to changing the standard plugin > interface, and by default nrpe and associated programs to use xml as a > communications standard. > You would be able to intelligently send more differing types of data > back from the plugin. The plugin would also be able to safely return > html code (or xml code) that would allow you to offer more clickable > information. > > Please let me know what you think of this idea. - keith Hi Keith, we already discussed on xml in performance data. The problem is, that nagios prior to version 3 can only process a couple of bytes (i guess it was sth < 512) of plugin output. So XML would be to bloat for now. Matthias From noreply at sourceforge.net Fri Jun 1 22:07:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 13:07:38 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1729581 ] check_ntp - fix for out of order associations Message-ID: Patches item #1729581, was opened at 2007-06-01 13:09 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Clint Byrum (cbyrum) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp - fix for out of order associations Initial Comment: If ntpq returns associations after the sys.peer, it overwrites the jitter with (not parsed) [root at talk etc]# ntpq -np newskip remote refid st t when poll reach delay offset jitter ============================================================================== +10.10.1.237 132.239.1.6 2 - 15 64 36 0.001 2.005 0.114 +10.10.1.33 60.56.119.79 2 - 50 64 17 0.001 -12.981 2.129 *10.10.1.233 132.239.1.6 2 - 48 64 16 0.001 2.273 0.115 127.127.1.0 LOCAL(0) 10 l 62 64 377 0.000 0.000 0.001 [root at talk etc]# ../libexec/check_ntp -H newskip Argument "(not parsed)" isn't numeric in abs at ../libexec/check_ntp line 408. NTP OK: Offset 0.021792 secs, jitter (not parsed) msec, peer is stratum 2|offset=0.021792, jitter=0,peer_stratum=2 This patch does not address the fact that if there's no match, you'll still get the isn't numeric problem. However if there is a sys peer, it will record a numeric jitter. ---------------------------------------------------------------------- Comment By: Clint Byrum (cbyrum) Date: 2007-06-01 13:43 Message: Logged In: YES user_id=11247 Originator: YES I was using v1.4.3 of the plugins. I checked the perl file in CVS, but I didn't realize there was a C version in the latest plugins! Upgrading now. Thanks for the quick response! ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-06-01 13:17 Message: Logged In: YES user_id=375623 Originator: NO Which version of Nagios-plugins is that? We're installing a C-based plugin since a few releases now, so either you're using a very old release or you manually installing the Perl plugin which has many bugs and is unmaintained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1729581&group_id=29880 From noreply at sourceforge.net Fri Jun 1 23:05:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 14:05:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1729692 ] segfault when following multiple redirects Message-ID: Bugs item #1729692, was opened at 2007-06-01 16:05 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=1729692&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: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aravind Gottipati (gottipati) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when following multiple redirects Initial Comment: check_http crashes when following multiple http redirects. As an example, this crashes for me consistently check_http -v -H en-us.add-ons.mozilla.com -f follow -u /en-US/firefox/2.0.0.4pre/extensions I am pasting the backtrace from it below. This happens for both the CVS version and the 1.4.8 release. Program received signal SIGSEGV, Segmentation fault. 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x00993918 in _int_malloc () from /lib/tls/libc.so.6 #2 0x009956e1 in malloc () from /lib/tls/libc.so.6 #3 0x003984be in CRYPTO_get_new_dynlockid () from /lib/libcrypto.so.4 #4 0x00398a6f in CRYPTO_malloc () from /lib/libcrypto.so.4 #5 0x004f8c7d in ssl_create_cipher_list () from /lib/libssl.so.4 #6 0x004f440c in SSL_CTX_new () from /lib/libssl.so.4 #7 0x0804c8d0 in np_net_ssl_init (sd=6) at sslutils.c:49 #8 0x0804a4a9 in check_http () at check_http.c:770 #9 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #10 0x0804af80 in check_http () at check_http.c:951 #11 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #12 0x0804af80 in check_http () at check_http.c:951 #13 0x0804c851 in main (argc=7, argv=0xbff753a4) at check_http.c:159 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1729692&group_id=29880 From noreply at sourceforge.net Fri Jun 1 23:08:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 14:08:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1729692 ] check_http: segfault when following multiple redirects Message-ID: Bugs item #1729692, was opened at 2007-06-01 16:05 Message generated for change (Settings changed) made by gottipati You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1729692&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: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aravind Gottipati (gottipati) Assigned to: Nobody/Anonymous (nobody) >Summary: check_http: segfault when following multiple redirects Initial Comment: check_http crashes when following multiple http redirects. As an example, this crashes for me consistently check_http -v -H en-us.add-ons.mozilla.com -f follow -u /en-US/firefox/2.0.0.4pre/extensions I am pasting the backtrace from it below. This happens for both the CVS version and the 1.4.8 release. Program received signal SIGSEGV, Segmentation fault. 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x00993918 in _int_malloc () from /lib/tls/libc.so.6 #2 0x009956e1 in malloc () from /lib/tls/libc.so.6 #3 0x003984be in CRYPTO_get_new_dynlockid () from /lib/libcrypto.so.4 #4 0x00398a6f in CRYPTO_malloc () from /lib/libcrypto.so.4 #5 0x004f8c7d in ssl_create_cipher_list () from /lib/libssl.so.4 #6 0x004f440c in SSL_CTX_new () from /lib/libssl.so.4 #7 0x0804c8d0 in np_net_ssl_init (sd=6) at sslutils.c:49 #8 0x0804a4a9 in check_http () at check_http.c:770 #9 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #10 0x0804af80 in check_http () at check_http.c:951 #11 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #12 0x0804af80 in check_http () at check_http.c:951 #13 0x0804c851 in main (argc=7, argv=0xbff753a4) at check_http.c:159 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1729692&group_id=29880 From jhmartin at toger.us Sat Jun 2 00:51:03 2007 From: jhmartin at toger.us (jhmartin at toger.us) Date: Fri, 1 Jun 2007 15:51:03 -0700 (PDT) Subject: [Nagiosplug-devel] Idea to change nagios to accept xml output from plugins In-Reply-To: <4660676A.9010109@mailing.kaufland-informationssysteme.com> References: <4660676A.9010109@mailing.kaufland-informationssysteme.com> Message-ID: <48919.135.214.40.162.1180738263.squirrel@sqmail.toger.us> > we already discussed on xml in performance data. > The problem is, that nagios prior to version 3 can only process > a couple of bytes (i guess it was sth < 512) of plugin output. So XML > would be to bloat for now. One should also consider if going to XML will raise the bar for someone to write their own plug-in. The current interface is very easy to implement, while an XML interface would make it more difficult. -Jason Martin From noreply at sourceforge.net Sat Jun 2 01:16:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 16:16:11 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1729692 ] check_http: segfault when following multiple redirects Message-ID: Bugs item #1729692, was opened at 2007-06-01 23:05 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1729692&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: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Aravind Gottipati (gottipati) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: segfault when following multiple redirects Initial Comment: check_http crashes when following multiple http redirects. As an example, this crashes for me consistently check_http -v -H en-us.add-ons.mozilla.com -f follow -u /en-US/firefox/2.0.0.4pre/extensions I am pasting the backtrace from it below. This happens for both the CVS version and the 1.4.8 release. Program received signal SIGSEGV, Segmentation fault. 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 (gdb) bt #0 0x0099297a in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x00993918 in _int_malloc () from /lib/tls/libc.so.6 #2 0x009956e1 in malloc () from /lib/tls/libc.so.6 #3 0x003984be in CRYPTO_get_new_dynlockid () from /lib/libcrypto.so.4 #4 0x00398a6f in CRYPTO_malloc () from /lib/libcrypto.so.4 #5 0x004f8c7d in ssl_create_cipher_list () from /lib/libssl.so.4 #6 0x004f440c in SSL_CTX_new () from /lib/libssl.so.4 #7 0x0804c8d0 in np_net_ssl_init (sd=6) at sslutils.c:49 #8 0x0804a4a9 in check_http () at check_http.c:770 #9 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #10 0x0804af80 in check_http () at check_http.c:951 #11 0x0804b302 in redir (pos=Variable "pos" is not available. ) at check_http.c:1182 #12 0x0804af80 in check_http () at check_http.c:951 #13 0x0804c851 in main (argc=7, argv=0xbff753a4) at check_http.c:159 ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-02 01:16 Message: Logged In: YES user_id=759506 Originator: NO This is fixed in CVS (Aravind confirmed the fix via IRC). Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1729692&group_id=29880 From noreply at sourceforge.net Sat Jun 2 01:16:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 16:16:49 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1506121 ] check_http Problem with protocol change in redirect Message-ID: Bugs item #1506121, was opened at 2006-06-14 17:09 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1506121&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jedrzej (jedrzejj) Assigned to: Nobody/Anonymous (nobody) Summary: check_http Problem with protocol change in redirect Initial Comment: Doing 'http_check -f follow' on an http:// url which returns an HTTP 302 redirect to an https:// SSL site, which in turn gives another redirect to an http:// url results in segmentation fault. Suppose we have 3 pages: test1.php: test2.php: test3.php: Doing 'check_http -H my.test.host -u "http://my.test.host/test1.php" -f follow' will cause a segmentation fault. It wouldn't happen if test2.php returned HTTP 200 code nor if test2.php returned another https:// link. It always seems to happen in HTTP -> HTTPS -> HTTP request chains. The problem occurs on Solaris 9 with gcc-4.1.1 and Solaris 10 with gcc-4.0.2, both have openssl 0.9.8. I haven't yet tested any other configurations. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-02 01:16 Message: Logged In: YES user_id=759506 Originator: NO I'm pretty sure I fixed this problem in CVS today. Feel free to test the current snapshot and to re-open this tracker item if you still encounter problems: http://nagiosplug.sourceforge.net/snapshot/ Thanks for your report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1506121&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Sat Jun 2 14:10:39 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sat, 02 Jun 2007 14:10:39 +0200 Subject: [Nagiosplug-devel] usage of the bool type Message-ID: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> Hi all, I was just wondering, why the bool type is never used in the plugin code. The only occurrence is in changes I made (two flags in check_disk). I've already heard, that int is actually faster to process despite the larger size, and that stdbool.h is not available on all platforms is that the reason? Matthias From noreply at sourceforge.net Sun Jun 3 18:13:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 09:13:21 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1475899 ] check_tcp segfaults with mutliple -s or -e args. Message-ID: Bugs item #1475899, was opened at 2006-04-25 03:48 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1475899&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: check_tcp segfaults with mutliple -s or -e args. Initial Comment: Plugins 1.4.3 running on FC3 or centos 4.2 redhat linux. The following command coredumps against netcat running as "nc -p 2525 -l": check_tcp -H localhost -p 2525 -s send1 -e receive1 \ -s send2 -e receive2 -v Using service TCP Port: 2525 flags: 0x2 Send string: send2 server_expect_count: 2 0: (null) 1: receive2 received 9 bytes from host #-raw-recv-------# receive2 #-raw-recv-------# looking for [(null)] anywhere in [receive2] Segmentation fault Note that the second send string is sent first. It should work as presented on the command line and send "send1" look for "receive1" then send "send2" and look for 'receive2". -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-03 18:13 Message: Logged In: YES user_id=1694341 Originator: NO segfault with multiple -e is fixed and -A/--all is now in cvs ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 22:11 Message: Logged In: YES user_id=1694341 Originator: NO hi all, thanks to ralph for this great analysis. Your explanation describes exactly what happens/ed. I removed the line in cvs and added a notice that -e can be repeated to the --help output. I'll let this item open since to me, there should be a new flag to let check_tcp require ALL instead of ANY of the expect strings. This flag can then be used to split XML expect strings (like in check_jabber), where a single string could cause a false positive, since ordering doesn't matter. ---------------------------------------------------------------------- Comment By: Christoph Maser (cmaser) Date: 2006-10-23 17:41 Message: Logged In: YES user_id=127006 i tried with 1.4.4 and this problem is still there. ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-10-23 17:30 Message: Logged In: YES user_id=1515003 Hi, i've stumbled over the "double -e means SEGV" thing myself. Here is a short analysis that should help fix it. First: these are two unrelated problems. -s is not meant to be specified several times, and only the latest one is effective. Maybe this needs to be clarified in the description, maybe not. For the -e switch things are different. There is a meaning of specifying this argument several time, and it is this: The returned response must match ANY of the -e arguments. So there is no order imposed here, nor must the response match all the arguments you give. Now for the segfault: This is caused by writing a NULL into the structure holding the expected response strings in check_tcp.c line 510. This line is redundant at best (if only one -e argument is given) and desastrous in all other cases. Resolution: Remove line 510. Long version: The EXPECT that is written to is a macro that resolves to server_expect[0]. You will notice two cases: Either the first -e argument is being processed. In that case server_expect itself is overwritten with a pointer to freshly allocated memory. In this case, NULLing its first component string is redundant. Or the second, third, ... -e argument is being processed. In that case, the first argument string is overwritten with the NULL, and the server_expect struct is enlarged (realloc'd) afterwards, keeping the NULL mine in place. Hence the SEGV later. In the hope that this helps, Ralph R??ner ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1475899&group_id=29880 From noreply at sourceforge.net Sun Jun 3 19:49:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 10:49:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1252285 ] check_ssh reports critical for some SSH servers Message-ID: Bugs item #1252285, was opened at 2005-08-05 01:59 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: TexasDavid (daupperle) Assigned to: Nobody/Anonymous (nobody) Summary: check_ssh reports critical for some SSH servers Initial Comment: The check_ssh plugin reports STATE_CRITICAL for certain SSH servers. As a result some valid SSH servers are reported down. For example, the following is a valid response for a working SSH server: sshd2: SSH Secure Shell 2.4.0 (non-commercial version) on hppa2.0n-hp-hpux11.00 The problem lies on line 216 of check_ssh.c (Version 1.27). THe function strncmp should be replaced with strncasecmp. Note: this change will not return the version properly, but it will return the state information. The following changes will properly evaluate the above SSH server in more detail and probably should be applied to the patch. 216c216 < if (strncmp (output, "SSH", 3)) { --- > if (strncasecmp (output, "SSH", 3)) { 224,227c224,237 < ssh_proto = output + 4; < ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); < ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; < --- > if (strncmp(output,"sshd2",5)==0) { > // Output(one line): sshd2: SSH Secure > // Shell 2.4.0 (non-commercial version) > // on hppa2.0n-hp-hpux11.00 > ssh_server = output + 7; > ssh_server[strcspn (ssh_server, "0123456789")-1] = 0; > ssh_proto = ssh_server + strlen (ssh_server)+1; > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } > else { // Standard servers > ssh_proto = output + 4; > ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-03 19:49 Message: Logged In: YES user_id=1694341 Originator: NO Hi David, I looked at the rfc (http://tools.ietf.org/html/rfc4253#section-4.2) and this claims that there must be a line like SSH-... but there MAY be other lines before that one that specifies the version. could you send the whole text the server offers (eg using netcat 127.0.0.1 22)? The patch you specified is a bit too specific to me. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 From noreply at sourceforge.net Sun Jun 3 19:50:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 10:50:49 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1252285 ] check_ssh reports critical for some SSH servers Message-ID: Bugs item #1252285, was opened at 2005-08-05 01:59 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: TexasDavid (daupperle) >Assigned to: Matthias Eble (psychotrahe) Summary: check_ssh reports critical for some SSH servers Initial Comment: The check_ssh plugin reports STATE_CRITICAL for certain SSH servers. As a result some valid SSH servers are reported down. For example, the following is a valid response for a working SSH server: sshd2: SSH Secure Shell 2.4.0 (non-commercial version) on hppa2.0n-hp-hpux11.00 The problem lies on line 216 of check_ssh.c (Version 1.27). THe function strncmp should be replaced with strncasecmp. Note: this change will not return the version properly, but it will return the state information. The following changes will properly evaluate the above SSH server in more detail and probably should be applied to the patch. 216c216 < if (strncmp (output, "SSH", 3)) { --- > if (strncasecmp (output, "SSH", 3)) { 224,227c224,237 < ssh_proto = output + 4; < ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); < ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; < --- > if (strncmp(output,"sshd2",5)==0) { > // Output(one line): sshd2: SSH Secure > // Shell 2.4.0 (non-commercial version) > // on hppa2.0n-hp-hpux11.00 > ssh_server = output + 7; > ssh_server[strcspn (ssh_server, "0123456789")-1] = 0; > ssh_proto = ssh_server + strlen (ssh_server)+1; > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } > else { // Standard servers > ssh_proto = output + 4; > ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-03 19:49 Message: Logged In: YES user_id=1694341 Originator: NO Hi David, I looked at the rfc (http://tools.ietf.org/html/rfc4253#section-4.2) and this claims that there must be a line like SSH-... but there MAY be other lines before that one that specifies the version. could you send the whole text the server offers (eg using netcat 127.0.0.1 22)? The patch you specified is a bit too specific to me. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 From holger at CIS.FU-Berlin.DE Sun Jun 3 20:01:16 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Sun, 3 Jun 2007 20:01:16 +0200 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> Message-ID: <20070603180116.GK8296755@CIS.FU-Berlin.DE> * Matthias Eble [2007-06-02 14:10]: > I was just wondering, why the bool type is never used in the plugin > code. The "bool" type was introduced with C99, so it doesn't (necessarily) exist on older platforms. > The only occurrence is in changes I made (two flags in check_disk). I don't really care whether or not we use the "bool" type, but IMO we should either use it everywhere or nowhere for consistency. If we use it, we must check for the existence of via Autoconf (which we do already) and make sure to #include code such as the following in every file which uses "bool", "true" or "false" (see gl/stdbool_.h): --------------- 8< -------------------- #if HAVE_STDBOOL_H #include #else #if !HAVE__BOOL #ifdef __cplusplus typedef bool _Bool; #else typedef unsigned char _Bool; #endif /* __cplusplus */ #endif /* not HAVE__BOOL */ #define bool _Bool #define false 0 #define true 1 #define __bool_true_false_are_defined 1 #endif /* HAVE_STDBOOL_H */ --------------- 8< -------------------- Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Mon Jun 4 10:33:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 01:33:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1119903 ] check_snmp_storage.pl 1.1 fails with AIX Message-ID: Bugs item #1119903, was opened at 2005-02-10 09:56 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1119903&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Vincent Cuirassier (vcuirassier) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp_storage.pl 1.1 fails with AIX Initial Comment: I'm using the nagios-plugins-1.3.1-5mdk Mandrake RPM, which includes version 1.1 of check_snmp_storage.pl. I can make successful requests to the Linux SNMP agent (net-snmp-5.1-7mdk), but the following command fails to query the AIX SNMP agent : # check_snmp_storage.pl -H aixhost -C public -m /home -w 60 -c 80 Alarm at 15 + 5 ERROR: Description table : Requested table is empty or does not exist. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 10:33 Message: Logged In: YES user_id=1694341 Originator: NO Hi Vincent, I have searched the mailing list archive but could not find any further posts on this topic. Could you resolve this problem in the meantime? However, according to the posts, this seems to be a problem with your SNMP deamon rather than a bug of check_snmp_storage. I'm setting this item to pending. The Item will get deleted if you won't reply in the next 14 days. Thanks for your report, Matthias ---------------------------------------------------------------------- Comment By: Patrick Proy (patrickproy) Date: 2005-02-24 00:38 Message: Logged In: YES user_id=124902 To linguafr : The mib FILE is here, but ir doesn't mean the snmp daemon handles it. On linux, it should work : just try with the snmpwalk command instead (snmpget on this oid will always fail) or get the latest net-snmp version. To vcuirassier : I don't know much about the AIX snmp agent. The aim is to have the snmpwalk command give some output for the oid, but I have no idea how. If IBM says it's OK, ask them... Did you give net-snmp a try ? Note : Please continue this thread in the nagiosplug mailling list : I can just put comments here, and I hate writing in this small comment box... Patrick nagios AT proy. org ---------------------------------------------------------------------- Comment By: Bill F (linguafr) Date: 2005-02-24 00:08 Message: Logged In: YES user_id=1080464 turns out HOST-RESOURCES-MIB is an optional mib that needed to be compiled in as a configure option. It now works ---------------------------------------------------------------------- Comment By: Bill F (linguafr) Date: 2005-02-23 21:59 Message: Logged In: YES user_id=1080464 I'm having the same problem on the following system Linux earth.epd.com 2.4.21-20.0.1.ELsmp #1 SMP Wed Nov 24 20:34:01 EST 2004 i686 i686 i386 GNU/Linux [root at earth root]# /usr/local/sbin/snmpd -v NET-SNMP version: 5.2.1 Web: http://www.net-snmp.org/ Email: net-snmp-coders at lists.sourceforge.net ps -ef|grep snmpd root 5368 1 0 Feb22 ? 00:00:03 /usr/local/sbin/snmpd -c /usr/local/share/snmp/snmpd.conf -M /usr/local/share/snmp/mibs -d -Lf /var/log/snmpd.log -p /var/run/snmpd -a [root at centauri etc]# snmpget -v 1 earth -c ****** 1.3.6.1.2.1.25.2.3.1 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: HOST-RESOURCES-MIB::hrStorageEntry ....but the mib is here [root at earth root]# ls /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB* /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB.txt ---------------------------------------------------------------------- Comment By: Vincent Cuirassier (vcuirassier) Date: 2005-02-18 12:47 Message: Logged In: YES user_id=1216109 According to IBM docs, the AIX SNMP agent implements the HOST-RESOURCES-MIB. But the snmpwalk command that you provided did not produce any output. ---------------------------------------------------------------------- Comment By: Patrick Proy (patrickproy) Date: 2005-02-11 22:42 Message: Logged In: YES user_id=124902 This plugin was never tested on AIX, but it can work on any plaforms with MIBII compliance. Does AIX snmp daemon implements the HOST-RESOURCES-MIB ? Try an snmpwalk on the oid "1.3.6.1.2.1.25.2.3.1" . Patrick Proy nagios at proy.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1119903&group_id=29880 From noreply at sourceforge.net Mon Jun 4 10:45:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 01:45:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1447642 ] check_ping segmentation fault on Solaris 10 Message-ID: Bugs item #1447642, was opened at 2006-03-11 01:11 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1447642&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: None Priority: 5 Private: No Submitted By: Matisse Enzer (matisse) Assigned to: Ton Voon (tonvoon) Summary: check_ping segmentation fault on Solaris 10 Initial Comment: Hmmm. The check_ping plugin dumps core.... Is this a known issue? ~/nagios/libexec: uname -a SunOS rdcuxsrv143 5.10 Generic_118822-20 sun4u sparc SUNW,Sun-Fire-V890 Solaris ~/nagios/libexec: ./check_ping -H localhost -w "99,5%" -c "100,20%" -p 1 Segmentation fault (core dumped) ~/nagios/libexec: And here's the tailend of truss output: 3980: open64("/var/run/name_service_door", O_RDONLY) = 3 3980: fcntl(3, F_SETFD, 0x00000001) = 0 3980: door_info(3, 0xFEBEF7E8) = 0 3980: door_call(3, 0xFFBFC1F8) = 0 3980: brk(0x0002B7E8) = 0 3980: brk(0x0002D7E8) = 0 3980: sigaction(SIGALRM, 0xFFBFE778, 0xFFBFE818) = 0 3980: alarm(10) = 0 3980: fstat64(63, 0xFFBFD978) Err#9 EBADF 3980: fstat64(63, 0xFFBFD820) Err#9 EBADF 3980: ioctl(63, TCGETA, 0xFFBFD904) Err#9 EBADF 3980: Incurred fault #6, FLTBOUNDS %pc = 0xFF1D099C 3980: siginfo: SIGSEGV SEGV_MAPERR addr=0x0002E000 3980: Received signal #11, SIGSEGV [default] 3980: sigi ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 10:45 Message: Logged In: YES user_id=1694341 Originator: NO Hi Matisse, could you try a later version of check_ping? We have a solaris 10 system in our buildfarm and check_ping currently shows no issues there. Will set this item to pending, so it will be automatically closed if you won't reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-03-11 09:16 Message: Logged In: YES user_id=664364 Matisse, There was a reported coredump on check_ping a few weeks back which has been fixed in CVS. Please try the snapshot at http://nagiosplug.sf.net/ snapshot. Alternatively, please try check_icmp which checks network connectivity natively. The snapshot will install with suid if make install is run as root. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1447642&group_id=29880 From ton.voon at altinity.com Mon Jun 4 11:36:00 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 4 Jun 2007 10:36:00 +0100 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <20070603180116.GK8296755@CIS.FU-Berlin.DE> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> <20070603180116.GK8296755@CIS.FU-Berlin.DE> Message-ID: <8185D2BF-7DD8-4B07-A746-893C0B926E79@altinity.com> On 3 Jun 2007, at 19:01, Holger Weiss wrote: > * Matthias Eble informationssysteme.com> [2007-06-02 14:10]: >> I was just wondering, why the bool type is never used in the plugin >> code. > > The "bool" type was introduced with C99, so it doesn't (necessarily) > exist on older platforms. > >> The only occurrence is in changes I made (two flags in check_disk). > > I don't really care whether or not we use the "bool" type, but IMO we > should either use it everywhere or nowhere for consistency. If we use > it, we must check for the existence of via Autoconf (which > we do already) and make sure to #include code such as the following in > every file which uses "bool", "true" or "false" (see gl/stdbool_.h): > > [snipped] Since bool is available from gnulibs, support on all platforms should be possible, so that shouldn't be a deciding factor. I don't have an opinion on whether we should use it, but I agree with Holger that we should be consistent. However, if we choose to use bool, that doesn't mean we have to do it all at once - I'm happy if you want to prove it works in one plugin, change a few more and we make a note in the dev guidelines to use bool when possible. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Jun 4 12:05:44 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 4 Jun 2007 11:05:44 +0100 Subject: [Nagiosplug-devel] Switching to svn Message-ID: Hi! The plugins team have expressed a desire to switch to using subversion instead of CVS for our source code management from Sourceforge. I'll be handling this work over the next few weeks as we create some SVN test repositories to make sure things work before switching over permanently. We want to retain the current release tags in CVS, but not necessarily the individual commits. I'd be interested to know if there are any tools that can do this, otherwise I'll use cvs2svn which will import everything. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jun 4 15:57:42 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 04 Jun 2007 15:57:42 +0200 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <8185D2BF-7DD8-4B07-A746-893C0B926E79@altinity.com> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> <20070603180116.GK8296755@CIS.FU-Berlin.DE> <8185D2BF-7DD8-4B07-A746-893C0B926E79@altinity.com> Message-ID: <46641A56.5040102@mailing.kaufland-informationssysteme.com> > Since bool is available from gnulibs, support on all platforms should > be possible, so that shouldn't be a deciding factor. > > I don't have an opinion on whether we should use it, but I agree with > Holger that we should be consistent. However, if we choose to use > bool, that doesn't mean we have to do it all at once - I'm happy if > you want to prove it works in one plugin, change a few more and we > make a note in the dev guidelines to use bool when possible. Yes, we should be consistent. I'm totally fine with using ints, just wanted to know if there is a reason why they are not used. I think the bools in check disk only work because the gnu libs are already included. I'll move them to int tonight. But we could add a hint to the guidelines to avoid bools/true/false for consistency purposes and instead use int/TRUE/FALSE. Matthias From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jun 4 16:04:40 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 04 Jun 2007 16:04:40 +0200 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: References: Message-ID: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> Ton Voon schrieb: > Hi! > > The plugins team have expressed a desire to switch to using > subversion instead of CVS for our source code management from > Sourceforge. I'll be handling this work over the next few weeks as we > create some SVN test repositories to make sure things work before > switching over permanently. To avoid any conflicts: Should we consider this as a request to stop checking in changes in cvs for now? But I guess you would have said this explicitly :) Matthias From ton.voon at altinity.com Mon Jun 4 16:24:51 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 4 Jun 2007 15:24:51 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> Message-ID: <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> On 4 Jun 2007, at 15:04, Matthias Eble wrote: > Ton Voon schrieb: >> The plugins team have expressed a desire to switch to using >> subversion instead of CVS for our source code management from >> Sourceforge. I'll be handling this work over the next few weeks as we >> create some SVN test repositories to make sure things work before >> switching over permanently. > > To avoid any conflicts: Should we consider this as a request to stop > checking in changes in cvs for now? > But I guess you would have said this explicitly :) Sorry, should have been more explicit. I need to do some work to create the SVN repositories and I'll inform this list that the test repos are available (hopefully within the week). That will give time to change any tools that rely on CVS (snapshots, automatic dev guidelines creation, tinderbox - I'll take care of these) to migrate over to SVN. Meanwhile, CVS is the official master code and can still be used. Then at some date in the future (probably 2 or 3 weeks away), I'll give some notice on this list before I re-create the new svn repo from the latest CVS and that will be the official master. Then the tools can be switched over and we can disable CVS. That's the "back of envelope plan"... Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Mon Jun 4 18:00:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 09:00:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1478287 ] check_dns fails with CNAMEs Message-ID: Bugs item #1478287, was opened at 2006-04-28 11:43 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James (jfidell) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns fails with CNAMEs Initial Comment: check_dns gives an error if the hostname being checked is a CNAME instead of an A record: DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address This patch may be sub-optimal, but corrects the problem for me: --- check_dns.c~ Fri Apr 28 10:35:45 2006 +++ check_dns.c Fri Apr 28 10:35:52 2006 @@ -136,6 +136,13 @@ non_authoritative = TRUE; } + else if ( strstr ( chld_out.line[i], query_address ) && !address ) { + if (( temp_buffer = strstr ( chld_out.line[i] + strlen ( query_address ), + _("canonical name = ")))) { + address = strdup ( temp_buffer ); + } + } + result = error_scan (chld_out.line[i]); if (result != STATE_OK) { msg = strchr (chld_out.line[i], ':'); James ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 18:00 Message: Logged In: YES user_id=1694341 Originator: NO Which OS version/nslookup version are you running? On Ubuntu Linux (6.06) everything is fine with cnames, too. nslookup output looks like this: ... foo.de.tld canonical name = bar.tld. Name: bar.tld Address: x.x.x.x Could you post your output, too? Thanks Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 From ae at op5.se Tue Jun 5 11:13:00 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 05 Jun 2007 11:13:00 +0200 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> Message-ID: <4665291C.1050804@op5.se> Matthias Eble wrote: > Hi all, > > I was just wondering, why the bool type is never used in the plugin > code. The only occurrence is in changes I made (two flags in > check_disk). I've already heard, that int is actually faster to process > despite the larger size, and that stdbool.h is not available on all > platforms is that the reason? > int is always the fastest to process because it's defined to be the same size as the registers on the CPU. bool is a C++-ism that got pulled into C with C99. A C-program gains nothing, but loses portability by using bool instead of int. Only if you compile a program with -Os (optimize for size, not speed), will you stand a chance at losing performance by using bool instead of int, as you can get several bool's contained in one int. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From chiel at gmx.net Tue Jun 5 11:23:32 2007 From: chiel at gmx.net (chiel) Date: Tue, 5 Jun 2007 11:23:32 +0200 Subject: [Nagiosplug-devel] Suggestion about SNMP errors Message-ID: <085001c7a753$2fa3da20$570010ac@michiel> Hello, I got a couple of scripts that use snmp for service cheking. The thing is that all these script will send a diferent error code if there is a problem with the communtication with the snmp-agent. So scripts will trigger a critical, warning or unknown message. Woudn't it be better if all script use the same error code? This would be much better for sending and processing notifications. I think the best option is "unknown" with these kind of errors. like to know your thoughts on this chiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Jun 5 13:25:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 04:25:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 15:33 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 13:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Tue Jun 5 14:07:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 05:07:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 13:53 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I have tried to reproduce this case on freebsd 6.2. But the lines were substituted correctly. use lib PREFIX/libexec use utils (... I tried 1.4.1, 1.4.3 and 1.4.5. Could you please test if this issue perstists with the latest version (1.4.9 or cvs snapshot)? Matthias ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 20:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From noreply at sourceforge.net Tue Jun 5 14:28:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 05:28:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1386144 ] Bug in check_mrtg plug-in Message-ID: Bugs item #1386144, was opened at 2005-12-20 14:16 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&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: James Turnbull (kartar) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in check_mrtg plug-in Initial Comment: I get a segmentation fault when I run the check_mrtg plugin on Red Hat Linux Enterprise 4. The plug-in version is 1.4.2. I poked into the code of the plug-in and noticed this line: int expire_minutes = 0; I changed it to: int expire_minutes = -1; I recompiled the code and the segementation fault was corrected. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, could you please tell us if this problem persists in the latest version (1.4.9 or cvs snapshot)? If so, we need the command line you used (i guess verbose output isn't possible with check_mrtg). I watched the source and can, up to now, hardly imagine how setting expire_minutes to -1 can prevent the plugin from segfaulting. We'll see.. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 From noreply at sourceforge.net Tue Jun 5 16:07:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 07:07:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 15:33 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-05 16:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 13:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Tue Jun 5 17:04:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 08:04:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 15:33 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 17:04 Message: Logged In: YES user_id=1694341 Originator: NO sbin is in $PATH by default at least on my freebsd 6.2 box. Should we consider to add the common pathes like /bin, /usr/bin, /sbin, and /usr/sbin to the configure script (after searching $PATH)? Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 16:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 13:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Tue Jun 5 17:05:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 08:05:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 15:33 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-05 17:05 Message: Logged In: YES user_id=759506 Originator: NO Good idea IMO. Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 17:04 Message: Logged In: YES user_id=1694341 Originator: NO sbin is in $PATH by default at least on my freebsd 6.2 box. Should we consider to add the common pathes like /bin, /usr/bin, /sbin, and /usr/sbin to the configure script (after searching $PATH)? Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 16:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 13:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Tue Jun 5 17:19:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 08:19:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 17:33 Message generated for change (Comment added) made by pentarh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Pentarh Udi (pentarh) Date: 2007-06-05 19:19 Message: Logged In: YES user_id=1694463 Originator: YES There is a configure option --with-ping-command or something similar. You can check it via "./configure --help". Also I suggest to install it from FreeBSD ports - there are no problems. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 19:05 Message: Logged In: YES user_id=759506 Originator: NO Good idea IMO. Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 19:04 Message: Logged In: YES user_id=1694341 Originator: NO sbin is in $PATH by default at least on my freebsd 6.2 box. Should we consider to add the common pathes like /bin, /usr/bin, /sbin, and /usr/sbin to the configure script (after searching $PATH)? Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 18:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 15:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Tue Jun 5 17:29:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 08:29:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 15:33 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&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: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-05 17:29 Message: Logged In: YES user_id=759506 Originator: NO Errm, we are aware of "--with-ping-command", but we were trying to fix a problem you reported! :-) PING_COMMAND should be set correctly out-of-the-box. If this doesn't happen, that would be a bug. And it definitely makes sense to fix bugs not only within some OS-specific package/port, but also upstream in order to make life easier for the package/port maintainer and for people who install the plugins manually for some reason. I set the status back to 'pending'. Holger ---------------------------------------------------------------------- Comment By: Pentarh Udi (pentarh) Date: 2007-06-05 17:19 Message: Logged In: YES user_id=1694463 Originator: YES There is a configure option --with-ping-command or something similar. You can check it via "./configure --help". Also I suggest to install it from FreeBSD ports - there are no problems. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 17:05 Message: Logged In: YES user_id=759506 Originator: NO Good idea IMO. Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 17:04 Message: Logged In: YES user_id=1694341 Originator: NO sbin is in $PATH by default at least on my freebsd 6.2 box. Should we consider to add the common pathes like /bin, /usr/bin, /sbin, and /usr/sbin to the configure script (after searching $PATH)? Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 16:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 13:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jun 5 19:28:21 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 05 Jun 2007 19:28:21 +0200 Subject: [Nagiosplug-devel] EXTRA Plugins / check_ide_smart Message-ID: <46659D35.40109@mailing.kaufland-informationssysteme.com> Hi list, up to now I thought extra plugins are for those plugins requiring special configure detections. While looking around, i saw this: if test -f plugins/check_nt.c ; then EXTRAS="$EXTRAS check_nt" elif test -f ../plugins/check_nt.c ; then EXTRAS="$EXTRAS check_nt" fi Could someone give me a hint what this actually detects? check_ide_smart has not built automatically up to now. But it seems to be Linux specific which makes me think about if it should be included anyway. It would need some small fixes and a configure line to be automatically compiled (in case of a linux system) again. What do you think? Matthias From holger at CIS.FU-Berlin.DE Tue Jun 5 20:30:11 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 5 Jun 2007 20:30:11 +0200 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <4665291C.1050804@op5.se> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> <4665291C.1050804@op5.se> Message-ID: <20070605183011.GO8296755@CIS.FU-Berlin.DE> * Andreas Ericsson [2007-06-05 11:13]: > Matthias Eble wrote: > > I was just wondering, why the bool type is never used in the plugin > > code. The only occurrence is in changes I made (two flags in > > check_disk). I've already heard, that int is actually faster to process > > despite the larger size, and that stdbool.h is not available on all > > platforms is that the reason? > > int is always the fastest to process because it's defined to be the same > size as the registers on the CPU. Neither is "int" defined that way nor does this assumption necessarily hold in practice. More importantly, "bool" is not defined to be of any specific size (as long as it can hold the values "0" and "1"), so compilers are free to use the size they deem most efficient or to provide switches to let the user decide on the size/performance trade-off. In practice, sizeof(bool) equals 4 or even 8 on quite a few platforms[*] and some compilers actually do provide such a switch. If all else fails, you can always "#define bool int", but as this is an implementation-specific compiler issue, it's IMO nothing an application programmer should care about. > bool is a C++-ism that got pulled into C with C99. So? > A C-program gains nothing, It could be argued that the program gains readability. > but loses portability by using bool instead of int. Not at all (if done correctly). Don't get me wrong, I don't really care whether or not we use "bool". I just think the decision whether or not to use it should neither be based on implementation-specific performance issues nor on the non-issue "portability"; IMO it should be based purely on syntactic preference. Holger [*] IIRC sizeof(bool) actually was 8 while sizeof(int) was 4 at least with some GCC version on Alpha, precisely for this reason. -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From ton.voon at altinity.com Fri Jun 8 09:20:32 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 8 Jun 2007 08:20:32 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> Message-ID: On 4 Jun 2007, at 15:24, Ton Voon wrote: > I need to do some work to create the SVN repositories and I'll inform > this list that the test repos are available (hopefully within the > week). That will give time to change any tools that rely on CVS > (snapshots, automatic dev guidelines creation, tinderbox - I'll take > care of these) to migrate over to SVN. Meanwhile, CVS is the official > master code and can still be used. Test svn repo is now available. I've put up an intro to SVN on our site: http://nagiosplugins.org/ index.php?option=com_easyfaq&task=view&id=11&Itemid=29 All SF devs should have full commit rights - I will be fine tuning that so the permissions match the current CVS setup. I also haven't switched on email notifications yet. Feel free to have a play - I have the import from CVS scripted and I can remove the whole svn repository, so don't be afraid of making some dummy commits before this goes live. If there are any real commits you want to do to CVS, that should continue to work as normal. I'll spend some time next week working through some of the ancillary tools and will let you know when those work. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From sebastian at wolfgarten.com Thu Jun 7 16:51:03 2007 From: sebastian at wolfgarten.com (Sebastian Wolfgarten) Date: Thu, 07 Jun 2007 16:51:03 +0200 Subject: [Nagiosplug-devel] Potential bug in nagios plugin check_by_ssh 1.39 Message-ID: <46681B57.5030005@wolfgarten.com> Hi, I think I have bug a bug in the nagios plugin check_by_ssh v1.39. I have successfully configured SSH public key-based logins between two of my servers and on the command-line it works absolutely fine: nagios at db01:~$ /usr/lib/nagios/plugins/check_by_ssh -l nagcheck -H 10.0.0.30 -C id uid=10001(nagcheck) gid=100(users) groups=100(users) As you can see, the plugin successfully shows the output of the "id" command. However when I try to cat a file I do not get any output at all: nagios at db01:~$ /usr/lib/nagios/plugins/check_by_ssh -l nagcheck -H 10.0.0.30 -C '/bin/cat /tmp/tw_cli.txt' I think this is rather strange, because when I use ssh to manually perform this operation I don't get any error at all (the cat command is run without any problems): nagios at db01:~$ ssh -l nagcheck 10.0.0.30 "/bin/cat /tmp/tw_cli.txt" Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-1 OK - - - 74.5294 ON - Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 74.53 GB 156301488 9QZ07S6M p1 OK u0 74.53 GB 156301488 9QZ08CRC Any ideas on this? Did I maybe discover a bug in the script? Thank you very much. Best regards, Sebastian Wolfgarten From noreply at sourceforge.net Mon Jun 11 09:46:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 00:46:39 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291987 ] nagios-plugins 1.4.1: urlize --useragent does not work Message-ID: Bugs item #1291987, was opened at 2005-09-15 15:42 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Bimschas (bimschas) Assigned to: Nobody/Anonymous (nobody) Summary: nagios-plugins 1.4.1: urlize --useragent does not work Initial Comment: running ./urlize http://www.google.de "./check_http -H www.google.de --useragent='not working'" returns: Name or service not known Unable to open TCP socket while the same command without "=" works: ./urlize http://www.google.de "./check_http -H allianz.phase4.de --useragent 'not working'" returns the correct output ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 09:46 Message: Logged In: YES user_id=1694341 Originator: NO Hi Daniel, you are right, there is a problem in popen.c where only simple quoting is supported up to now. I have a solution for that but it needs some further testing. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:13:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:13:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 13:53 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:13 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I have tried to reproduce this case on freebsd 6.2. But the lines were substituted correctly. use lib PREFIX/libexec use utils (... I tried 1.4.1, 1.4.3 and 1.4.5. Could you please test if this issue perstists with the latest version (1.4.9 or cvs snapshot)? Matthias ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 20:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:14:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:14:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 13:53 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:13 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I have tried to reproduce this case on freebsd 6.2. But the lines were substituted correctly. use lib PREFIX/libexec use utils (... I tried 1.4.1, 1.4.3 and 1.4.5. Could you please test if this issue perstists with the latest version (1.4.9 or cvs snapshot)? Matthias ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 20:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:15:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:15:19 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1252285 ] check_ssh reports critical for some SSH servers Message-ID: Bugs item #1252285, was opened at 2005-08-05 01:59 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: TexasDavid (daupperle) Assigned to: Matthias Eble (psychotrahe) Summary: check_ssh reports critical for some SSH servers Initial Comment: The check_ssh plugin reports STATE_CRITICAL for certain SSH servers. As a result some valid SSH servers are reported down. For example, the following is a valid response for a working SSH server: sshd2: SSH Secure Shell 2.4.0 (non-commercial version) on hppa2.0n-hp-hpux11.00 The problem lies on line 216 of check_ssh.c (Version 1.27). THe function strncmp should be replaced with strncasecmp. Note: this change will not return the version properly, but it will return the state information. The following changes will properly evaluate the above SSH server in more detail and probably should be applied to the patch. 216c216 < if (strncmp (output, "SSH", 3)) { --- > if (strncasecmp (output, "SSH", 3)) { 224,227c224,237 < ssh_proto = output + 4; < ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); < ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; < --- > if (strncmp(output,"sshd2",5)==0) { > // Output(one line): sshd2: SSH Secure > // Shell 2.4.0 (non-commercial version) > // on hppa2.0n-hp-hpux11.00 > ssh_server = output + 7; > ssh_server[strcspn (ssh_server, "0123456789")-1] = 0; > ssh_proto = ssh_server + strlen (ssh_server)+1; > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } > else { // Standard servers > ssh_proto = output + 4; > ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:15 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-03 19:49 Message: Logged In: YES user_id=1694341 Originator: NO Hi David, I looked at the rfc (http://tools.ietf.org/html/rfc4253#section-4.2) and this claims that there must be a line like SSH-... but there MAY be other lines before that one that specifies the version. could you send the whole text the server offers (eg using netcat 127.0.0.1 22)? The patch you specified is a bit too specific to me. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:16:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:16:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1386144 ] Bug in check_mrtg plug-in Message-ID: Bugs item #1386144, was opened at 2005-12-20 14:16 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&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: None Priority: 5 Private: No Submitted By: James Turnbull (kartar) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in check_mrtg plug-in Initial Comment: I get a segmentation fault when I run the check_mrtg plugin on Red Hat Linux Enterprise 4. The plug-in version is 1.4.2. I poked into the code of the plug-in and noticed this line: int expire_minutes = 0; I changed it to: int expire_minutes = -1; I recompiled the code and the segementation fault was corrected. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:16 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, could you please tell us if this problem persists in the latest version (1.4.9 or cvs snapshot)? If so, we need the command line you used (i guess verbose output isn't possible with check_mrtg). I watched the source and can, up to now, hardly imagine how setting expire_minutes to -1 can prevent the plugin from segfaulting. We'll see.. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:17:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:17:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1478287 ] check_dns fails with CNAMEs Message-ID: Bugs item #1478287, was opened at 2006-04-28 11:43 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: James (jfidell) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns fails with CNAMEs Initial Comment: check_dns gives an error if the hostname being checked is a CNAME instead of an A record: DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address This patch may be sub-optimal, but corrects the problem for me: --- check_dns.c~ Fri Apr 28 10:35:45 2006 +++ check_dns.c Fri Apr 28 10:35:52 2006 @@ -136,6 +136,13 @@ non_authoritative = TRUE; } + else if ( strstr ( chld_out.line[i], query_address ) && !address ) { + if (( temp_buffer = strstr ( chld_out.line[i] + strlen ( query_address ), + _("canonical name = ")))) { + address = strdup ( temp_buffer ); + } + } + result = error_scan (chld_out.line[i]); if (result != STATE_OK) { msg = strchr (chld_out.line[i], ':'); James ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:17 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 18:00 Message: Logged In: YES user_id=1694341 Originator: NO Which OS version/nslookup version are you running? On Ubuntu Linux (6.06) everything is fine with cnames, too. nslookup output looks like this: ... foo.de.tld canonical name = bar.tld. Name: bar.tld Address: x.x.x.x Could you post your output, too? Thanks Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:19:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:19:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 18:31 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&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: Compilation Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ton Voon (tonvoon) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:19 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2007-02-02 20:46 Message: Logged In: YES user_id=865292 Originator: YES Thanks. However, since I have just changed job I am unable to test. This one is down to bubbafat. Duncs ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-02-02 18:05 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan and bubbafat, Hi Duncan, I think this is fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 07:25 Message: Logged In: YES user_id=1495257 Same thing happens on Solaris 7 with gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release). source='check_smtp.c' object='check_smtp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/local/include -I/usr/local/include -Wall -g -O2 -c check_smtp.c check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3' make: *** [all] Error 2 A lame fix is: --- nagios-plugins-1.4.3/plugins/check_smtp.c Wed Nov 2 03:47:26 2005 +++ nagios-plugins-1.4.3m/plugins/check_smtp.c Mon Apr 24 22:52:01 2006 @@ -26,6 +26,7 @@ #include "common.h" #include "netutils.h" #include "utils.h" +#include #ifdef HAVE_SSL int check_cert = FALSE; However, on Solaris 8 with gcc version 3.3.2, this is not needed. netdb.h gets included somehow. Haven't been able to trace it down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From noreply at sourceforge.net Mon Jun 11 10:21:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 01:21:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1523748 ] check_disk should error if warn range is subset of critical Message-ID: Bugs item #1523748, was opened at 2006-07-17 11:37 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_disk should error if warn range is subset of critical Initial Comment: the new se->w_idfp and se->c_idfp in version 1.4.3 are not initialized resulting in the following error (on HP-UX 11.23) check_disk -c 5% -w 10% -p /dev/vg00/lvol1 INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (64768802081573470261722606760322190900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /dev/vg00/lvol1 check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [-v] [-q] The following patch corrects this *** check_disk.c Mon Jul 17 11:32:26 2006 --- check_disk.c.good Mon Jul 17 11:32:03 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:21 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to vandenburgd. Unfortunately the mail couldn't be delivered. Yet setting to pending. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-10 18:52 Message: Logged In: YES user_id=1694341 Originator: NO what do you mean with "consistency check"? matthias ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-07-17 17:46 Message: Logged In: YES user_id=780242 As the changes in CURRENT deleted every reference to w_idfp and c_idfp the error also disappears. Unfortunately the consistency check also dispappeared. Dick ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-17 12:27 Message: Logged In: YES user_id=664364 Dick, Can you try the snapshot at http://nagiosplug.sourceforge.net/snapshot. There have been fixes to check_disk recently. Please update if there is still a problem. I've marked the call in pending so it will autoclose in 7 days. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 From noreply at sourceforge.net Mon Jun 11 11:05:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 02:05:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1478287 ] check_dns fails with CNAMEs Message-ID: Bugs item #1478287, was opened at 2006-04-28 09:43 Message generated for change (Comment added) made by jfidell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: James (jfidell) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns fails with CNAMEs Initial Comment: check_dns gives an error if the hostname being checked is a CNAME instead of an A record: DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address This patch may be sub-optimal, but corrects the problem for me: --- check_dns.c~ Fri Apr 28 10:35:45 2006 +++ check_dns.c Fri Apr 28 10:35:52 2006 @@ -136,6 +136,13 @@ non_authoritative = TRUE; } + else if ( strstr ( chld_out.line[i], query_address ) && !address ) { + if (( temp_buffer = strstr ( chld_out.line[i] + strlen ( query_address ), + _("canonical name = ")))) { + address = strdup ( temp_buffer ); + } + } + result = error_scan (chld_out.line[i]); if (result != STATE_OK) { msg = strchr (chld_out.line[i], ':'); James ---------------------------------------------------------------------- >Comment By: James (jfidell) Date: 2007-06-11 09:05 Message: Logged In: YES user_id=1510516 Originator: YES OS is FreeBSD 6.0. Not sure about the nslookup version as it seems to defy my attempts to find out. IIRC correctly (as this was some time ago), the problem is not specifically that the format of output of nslookup is different, but that in same circumstances check_dns mis-handles the output. I *think* the problem is that for some configurations (could be where the CNAME is in a different domain, or where it is served by a different nameserver, or perhaps just depending on the nameserver implementation), nslookup may not return a "Name:" or "Address:" line at all, even though the nameserver being queried can and does answer properly that the queried hostname is a canonical name. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 08:17 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 16:00 Message: Logged In: YES user_id=1694341 Originator: NO Which OS version/nslookup version are you running? On Ubuntu Linux (6.06) everything is fine with cnames, too. nslookup output looks like this: ... foo.de.tld canonical name = bar.tld. Name: bar.tld Address: x.x.x.x Could you post your output, too? Thanks Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1478287&group_id=29880 From noreply at sourceforge.net Mon Jun 11 11:13:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 02:13:18 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1523748 ] check_disk should error if warn range is subset of critical Message-ID: Bugs item #1523748, was opened at 2006-07-17 10:37 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_disk should error if warn range is subset of critical Initial Comment: the new se->w_idfp and se->c_idfp in version 1.4.3 are not initialized resulting in the following error (on HP-UX 11.23) check_disk -c 5% -w 10% -p /dev/vg00/lvol1 INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (64768802081573470261722606760322190900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /dev/vg00/lvol1 check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [-v] [-q] The following patch corrects this *** check_disk.c Mon Jul 17 11:32:26 2006 --- check_disk.c.good Mon Jul 17 11:32:03 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-06-11 10:13 Message: Logged In: YES user_id=664364 Originator: NO Matthias, Sorry, I should have put some more details in here. Dick's original query was because check_disk used to give an error if the range values did not "make sense" - ie, "./check_disk 0 200" (200% free?) and "./check_disk -w 10% -c 15%" (warn if less than 10%, but critical if less than 15% means warn will neven happen). The changes I made a few months ago for range values does not do any validation for the input values. There are some TODO tests in check_disk.t for invalid values and invalid percent figures - I think these are what Dick would like fixed. I'm unsure how general these cases are. Should you always flag an UNKNOWN state if the warning range is completely within the critical range? Should you check values for data types such as percentages (of course, it is possible to get something as 200% of a previous value...). Matthias, this is probably a good conversation for the mailing list if you want to drive. Ton ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 09:21 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to vandenburgd. Unfortunately the mail couldn't be delivered. Yet setting to pending. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-10 17:52 Message: Logged In: YES user_id=1694341 Originator: NO what do you mean with "consistency check"? matthias ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-07-17 16:46 Message: Logged In: YES user_id=780242 As the changes in CURRENT deleted every reference to w_idfp and c_idfp the error also disappears. Unfortunately the consistency check also dispappeared. Dick ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-17 11:27 Message: Logged In: YES user_id=664364 Dick, Can you try the snapshot at http://nagiosplug.sourceforge.net/snapshot. There have been fixes to check_disk recently. Please update if there is still a problem. I've marked the call in pending so it will autoclose in 7 days. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 From ae at op5.se Mon Jun 11 11:49:39 2007 From: ae at op5.se (Andreas Ericsson) Date: Mon, 11 Jun 2007 11:49:39 +0200 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> References: <465453CE.3070609@op5.se> <429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> Message-ID: <466D1AB3.1060101@op5.se> Ton Voon wrote: > Hi Andreas, > > On 23 May 2007, at 15:46, Andreas Ericsson wrote: > >> This patch lets the user specify how to translate the various return >> codes from the commands the negate plugin runs, rather than just >> having >> the hardcoded option to go with. >> >> This is specified as such: >> --critical=warning (to make critical translate to warning) >> --warning=ok >> > > This looks interesting and I wrote some tests to try this out, but I > don't appear to be getting the right results. Could have a look at it? > Oh gawds, this went dormant for a long time. Higher prio projects, illness and vacations came in between. I happened to build the patch from the wrong branch. The correct one is attached. > The tests are in plugins/t/negate.pl. To run them you have to run: > > cd plugins > NPTEST_DEBUG=1 perl t/negate.pl > > Have I misunderstood how your options are meant to be used? > > Ton > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > 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 -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -------------- next part -------------- A non-text attachment was scrubbed... Name: negate-status-select.patch Type: text/x-patch Size: 11380 bytes Desc: not available URL: From noreply at sourceforge.net Mon Jun 11 15:44:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 06:44:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1614554 ] no perf-data check_swap Message-ID: Patches item #1614554, was opened at 2006-12-13 08:17 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614554&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_swap Initial Comment: The plugin check_swap doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614554&group_id=29880 From noreply at sourceforge.net Mon Jun 11 15:45:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 06:45:27 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1614553 ] no perf-data check_apt Message-ID: Patches item #1614553, was opened at 2006-12-13 08:16 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614553&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_apt Initial Comment: The plugin check_apt doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614553&group_id=29880 From noreply at sourceforge.net Mon Jun 11 15:45:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 06:45:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1614552 ] no perf-data check_procs Message-ID: Patches item #1614552, was opened at 2006-12-13 08:14 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614552&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_procs Initial Comment: The plugincheck_procs doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614552&group_id=29880 From noreply at sourceforge.net Mon Jun 11 15:46:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 06:46:34 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1386144 ] Bug in check_mrtg plug-in Message-ID: Bugs item #1386144, was opened at 2005-12-21 00:16 Message generated for change (Comment added) made by kartar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&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: James Turnbull (kartar) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in check_mrtg plug-in Initial Comment: I get a segmentation fault when I run the check_mrtg plugin on Red Hat Linux Enterprise 4. The plug-in version is 1.4.2. I poked into the code of the plug-in and noticed this line: int expire_minutes = 0; I changed it to: int expire_minutes = -1; I recompiled the code and the segementation fault was corrected. ---------------------------------------------------------------------- >Comment By: James Turnbull (kartar) Date: 2007-06-11 23:46 Message: Logged In: YES user_id=1364759 Originator: YES Matthias Doesn't seem to but I only have RHEL 5 to test it on - may behave differently on RHEL 4. I know it's odd - I have no idea why the change impacted it either - but it worked after that change. I could find nothing else in the compile environment to explain it working. I am trying to rack my brains as to what triggered me to change expire_minutes but *shrugs* it was over a year ago. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 18:16 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 22:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, could you please tell us if this problem persists in the latest version (1.4.9 or cvs snapshot)? If so, we need the command line you used (i guess verbose output isn't possible with check_mrtg). I watched the source and can, up to now, hardly imagine how setting expire_minutes to -1 can prevent the plugin from segfaulting. We'll see.. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 From noreply at sourceforge.net Mon Jun 11 21:29:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 12:29:21 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1386144 ] Bug in check_mrtg plug-in Message-ID: Bugs item #1386144, was opened at 2005-12-20 14:16 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&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: James Turnbull (kartar) >Assigned to: Matthias Eble (psychotrahe) Summary: Bug in check_mrtg plug-in Initial Comment: I get a segmentation fault when I run the check_mrtg plugin on Red Hat Linux Enterprise 4. The plug-in version is 1.4.2. I poked into the code of the plug-in and noticed this line: int expire_minutes = 0; I changed it to: int expire_minutes = -1; I recompiled the code and the segementation fault was corrected. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 21:29 Message: Logged In: YES user_id=1694341 Originator: NO Thanks for your reply James, it has really long time gone. Is anyone of the devs running a rhel4 server with mrtg to check this? If there are any other bugs concerning rhel4, i'll probably set up a vmware image. If not, i'll close it in the next days. Again, thanks for your report. ---------------------------------------------------------------------- Comment By: James Turnbull (kartar) Date: 2007-06-11 15:46 Message: Logged In: YES user_id=1364759 Originator: YES Matthias Doesn't seem to but I only have RHEL 5 to test it on - may behave differently on RHEL 4. I know it's odd - I have no idea why the change impacted it either - but it worked after that change. I could find nothing else in the compile environment to explain it working. I am trying to rack my brains as to what triggered me to change expire_minutes but *shrugs* it was over a year ago. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:16 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, could you please tell us if this problem persists in the latest version (1.4.9 or cvs snapshot)? If so, we need the command line you used (i guess verbose output isn't possible with check_mrtg). I watched the source and can, up to now, hardly imagine how setting expire_minutes to -1 can prevent the plugin from segfaulting. We'll see.. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 From noreply at sourceforge.net Mon Jun 11 22:56:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 13:56:49 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291987 ] nagios-plugins 1.4.1: urlize --useragent does not work Message-ID: Bugs item #1291987, was opened at 2005-09-15 15:42 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Daniel Bimschas (bimschas) >Assigned to: Matthias Eble (psychotrahe) Summary: nagios-plugins 1.4.1: urlize --useragent does not work Initial Comment: running ./urlize http://www.google.de "./check_http -H www.google.de --useragent='not working'" returns: Name or service not known Unable to open TCP socket while the same command without "=" works: ./urlize http://www.google.de "./check_http -H allianz.phase4.de --useragent 'not working'" returns the correct output ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 22:56 Message: Logged In: YES user_id=1694341 Originator: NO Daniel, the problem should be fixed in cvs now. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 09:46 Message: Logged In: YES user_id=1694341 Originator: NO Hi Daniel, you are right, there is a problem in popen.c where only simple quoting is supported up to now. I have a solution for that but it needs some further testing. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291987&group_id=29880 From dermoth at aei.ca Tue Jun 12 04:30:24 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 11 Jun 2007 22:30:24 -0400 Subject: [Nagiosplug-devel] check_time UNKNOWNs Message-ID: <466E0540.50803@aei.ca> Hi there, I was investigating the issue with my tinderbox that fails very often the udp time check. I'm not sure what's going on but this seems pretty strange: $ time ./check_time -H time-a.nist.gov -w 999999 -W 59 -c 999999 -C 59 -t 60 TIME UNKNOWN - no data received from server time-a.nist.gov, port 37 real 0m0.134s user 0m0.006s sys 0m0.013s 0m0.134s is pretty fast to determine that no data was received. Looks like either somethings wrong with the timeout or the the output is unclear. I'll be very busy for the next two months so I don't think I'll have time to look into this very soon... It'll be on my todo list unless someone wants to take a look. Thanks, Thomas From dermoth at aei.ca Tue Jun 12 05:27:11 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 11 Jun 2007 23:27:11 -0400 Subject: [Nagiosplug-devel] check_time UNKNOWNs In-Reply-To: <466E0540.50803@aei.ca> References: <466E0540.50803@aei.ca> Message-ID: <466E128F.40302@aei.ca> On 11/06/07 10:30 PM, Thomas Guyot-Sionnest wrote: > Hi there, > > I was investigating the issue with my tinderbox that fails very often > the udp time check. Well, nevermind. Despite the fact that the test variable is named "$host_udp_time" it's actually using tcp, so it makes sense to receive no data and that can probably be blamed on the remote time server. Thomas From noreply at sourceforge.net Tue Jun 12 20:09:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 11:09:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1460312 ] check_http doesn't check response time on 300's Message-ID: Bugs item #1460312, was opened at 2006-03-29 00:40 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&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: Thomas Guyot (dermoth) Assigned to: Nobody/Anonymous (nobody) Summary: check_http doesn't check response time on 300's Initial Comment: 300's return codes are accepted as OK by default, but some checks, notably warning/critical time, aren't done on 300 return codes. I didn't had time to rewrite this correctly and test it troughfully, but this simple patch will go on with other tests when 300's are accepted as OK. Ideally, response time should be checked when 300!=CRITICAL, and I also on when expecting a string. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-12 20:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi Thomas, I looked over the patch and i guess, this would prevent the actual redirect. We should also take care of changes to the time measuring behaviour and mention changes in NEWS or similar so that people don't wonder why their performance got worse :) Could you bring up some time look at this? Matthias ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2006-03-29 00:41 Message: Logged In: YES user_id=375623 Forgot the check_box ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&group_id=29880 From noreply at sourceforge.net Wed Jun 13 01:55:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 16:55:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1460312 ] check_http doesn't check response time on 300's Message-ID: Bugs item #1460312, was opened at 2006-03-28 17:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&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: Thomas Guyot (dermoth) >Assigned to: Thomas Guyot (dermoth) Summary: check_http doesn't check response time on 300's Initial Comment: 300's return codes are accepted as OK by default, but some checks, notably warning/critical time, aren't done on 300 return codes. I didn't had time to rewrite this correctly and test it troughfully, but this simple patch will go on with other tests when 300's are accepted as OK. Ideally, response time should be checked when 300!=CRITICAL, and I also on when expecting a string. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-06-12 19:55 Message: Logged In: YES user_id=375623 Originator: YES Indeed this patch looks strange... It was not necessarily intended for inclusion (just a hack), I don't use it anymore and it's been so long I don't even remember why it wasn't "right"... I wasn't a NP developer when I submitted it... I'll assign it to myself and will look over it when I have time (Certainly not until august unfortunately). Thomas ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-12 14:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi Thomas, I looked over the patch and i guess, this would prevent the actual redirect. We should also take care of changes to the time measuring behaviour and mention changes in NEWS or similar so that people don't wonder why their performance got worse :) Could you bring up some time look at this? Matthias ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2006-03-28 17:41 Message: Logged In: YES user_id=375623 Forgot the check_box ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1460312&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Thu Jun 14 23:18:59 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Thu, 14 Jun 2007 23:18:59 +0200 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> Message-ID: <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> Hi Ton, hi list, don't know if you or some other dev already recognized that the $Id$ and $Revision$ Keywords are not substituted in the svn repository. There is a problem since this setting cannot be stored on the server side by default. It seems that this has to be enabled locally after every checkout. I also read about a possibility to enable the substitution permanently - before the file is actually added. Here described how to add substitution in the local way. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.keywords And here with the autoprop feature (only for add and import commands) http://svn.haxx.se/users/archive-2003-11/0265.shtml Could you take a look at this? To me it's a very important point that needs to be tested before switching. What do you think? Matthias From ton.voon at altinity.com Fri Jun 15 01:48:23 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 15 Jun 2007 00:48:23 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> Message-ID: <50A77A27-1CCF-4668-98D0-D4453EEE5255@altinity.com> Hi Matthias, On 14 Jun 2007, at 22:18, Matthias Eble wrote: > don't know if you or some other dev already recognized that the $Id > $ and > $Revision$ Keywords are not substituted in the svn repository. Where are you seeing this? It looks okay to me. A checkout of svn code followed by a look at plugins/check_tcp.c shows $Date$ and $Id$ are expanded out in the comment section at the top. However, the version number when you run check_tcp --version only shows Subversion's four digit number, 1729. Currently it says: $ ./check_tcp --version check_tcp (nagios-plugins 1.4.9) 1729 Would it make sense to append a v to the beginning of 1729? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From dermoth at aei.ca Fri Jun 15 02:32:30 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 14 Jun 2007 20:32:30 -0400 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> Message-ID: <4671DE1E.6010203@aei.ca> On 14/06/07 05:18 PM, Matthias Eble wrote: > Hi Ton, hi list, > > don't know if you or some other dev already recognized that the $Id$ and > $Revision$ Keywords are not substituted in the svn repository. > > There is a problem since this setting cannot be stored on the server > side by default. It seems that this has to be enabled locally after > every checkout. I also read about a possibility to enable the > substitution permanently - before the file is actually added. > > Here described how to add substitution in the local way. > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.keywords > > And here with the autoprop feature (only for add and import commands) > http://svn.haxx.se/users/archive-2003-11/0265.shtml > > Could you take a look at this? To me it's a very important point that > needs to be tested before switching. > What do you think? We've been using SVN for many years... AFAIK the keywords property needs to be set only once. To avoid missing them we have a script that runs every night to add that property. All you have to do is: cd /path/to/some_local_copy svn cleanup svn update svn propset svn:keywords "Author Date Id Revision" -R . svn commit -m "Adding Keywords property" And you'll never miss a keyword again Thomas From matthias.eble at mailing.kaufland-informationssysteme.com Fri Jun 15 09:18:09 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 15 Jun 2007 09:18:09 +0200 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <50A77A27-1CCF-4668-98D0-D4453EEE5255@altinity.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> <50A77A27-1CCF-4668-98D0-D4453EEE5255@altinity.com> Message-ID: <46723D31.9050105@mailing.kaufland-informationssysteme.com> Ton Voon schrieb: > Hi Matthias, > > On 14 Jun 2007, at 22:18, Matthias Eble wrote: > >> don't know if you or some other dev already recognized that the $Id >> $ and >> $Revision$ Keywords are not substituted in the svn repository. > > Where are you seeing this? It looks okay to me. A checkout of svn > code followed by a look at plugins/check_tcp.c shows $Date$ and $Id$ > are expanded out in the comment section at the top. okay.. I was a bit too fast. I had this problem with a svn server in my company, so I looked at the sf.net viewcvs page where keywords are substituted for cvs, but not for svn. Unfortunately I didn't test this with the checked out copy of the np-repository. It works with a real svn checkout. I guess the properties have been added by cvs2svn automatically. For every source file, there is a properties file containing the keywords in the .svn directory. Maybe activation has to be considered when adding new files. > > However, the version number when you run check_tcp --version only > shows Subversion's four digit number, 1729. Currently it says: > > $ ./check_tcp --version > check_tcp (nagios-plugins 1.4.9) 1729 > > Would it make sense to append a v to the beginning of 1729? I'd say that would make sense. I could also imagine this order: check_tcp v1729 (nagios-plugins 1.4.9) Matthias From ae at op5.se Fri Jun 15 10:29:07 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 15 Jun 2007 10:29:07 +0200 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: References: Message-ID: <46724DD3.3050700@op5.se> Ton Voon wrote: > Hi! > > The plugins team have expressed a desire to switch to using > subversion instead of CVS for our source code management from > Sourceforge. I'll be handling this work over the next few weeks as we > create some SVN test repositories to make sure things work before > switching over permanently. > > We want to retain the current release tags in CVS, but not > necessarily the individual commits. I'd be interested to know if > there are any tools that can do this, otherwise I'll use cvs2svn > which will import everything. > git-cvsimport will handle it, and it can later be committed to an svn repo of your choice with git-svn. Some scripting might be needed, or some minor hacking on git-svn to let it accept ranges of commits. The easiest way is most likely to use a loop such as this: git rev-list HEAD | sed '1!G;h;$!d' | while read commit; do git svn dcommit --no-rebase $commit done If you want all release-tags in CVS to be committed to SVN as one commit each, that's doable too, but you'd need a bit of manual labour to make it fly. -- 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 Jun 15 21:44:06 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 15 Jun 2007 21:44:06 +0200 Subject: [Nagiosplug-devel] Potential bug in nagios plugin check_by_ssh 1.39 In-Reply-To: <46681B57.5030005@wolfgarten.com> References: <46681B57.5030005@wolfgarten.com> Message-ID: <20070615194405.GG4705358@CIS.FU-Berlin.DE> * Sebastian Wolfgarten [2007-06-07 16:51]: > nagios at db01:~$ /usr/lib/nagios/plugins/check_by_ssh -l nagcheck -H 10.0.0.30 -C id > uid=10001(nagcheck) gid=100(users) groups=100(users) > > As you can see, the plugin successfully shows the output of the "id" > command. However when I try to cat a file I do not get any output at all: check_by_ssh doesn't write more than one line as Nagios 2.x doesn't support multiple lines of plugin output. By default, the first line read from the remote command is used as the plugin output. I guess this line is empty in your file. If you want a different line, you can use "check_by_ssh -Sn" (where "n" is a positive integer) to spit out the n+1'th line read from the remote command's stdout output[*]. Holger [*] Note that it works this way both with revision 1.39 of check_by_ssh and with the current version, despite the help output of revision 1.39 incorrectly talking about stderr. (This has been fixed by now, and the "-E" flag has been added for supressing output to stderr.) -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Sat Jun 16 20:35:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Jun 2007 11:35:02 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1687867 ] check_http: buffer overflow vulnerability Message-ID: Bugs item #1687867, was opened at 2007-03-26 01:37 Message generated for change (Comment added) made by ban_nobuhiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1687867&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: 7 >Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: buffer overflow vulnerability Initial Comment: Description: Buffer overflows within the redir() function of check_http.c potentially allow remote attackers to execute arbitrary code via crafted ``Location:'' responses. This vulnerability is caused by passing insufficient length buffers to sscanf(). Example of crafted ``Location:'' response: o Location: htttttttttttttttttttttttttttttttttttttttttttp://example.com/ o Location: http://example.com:1234567890123456789012345678901234567890/ o Location: http://tooooooooooooooooooooooooooooooooooooooooooooooooooo.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.host-name.example.com/ Workaround: Do not check untrusted web server with ``-f follow'' option. ---------------------------------------------------------------------- >Comment By: Nobuhiro Ban (ban_nobuhiro) Date: 2007-06-17 03:35 Message: Logged In: YES user_id=1699577 Originator: YES Because this contains some vulnerability information, I marked this report as confidential (private), Over 80 days have passed, and the vulnerability exist still now. So I open this to public. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1687867&group_id=29880 From noreply at sourceforge.net Sun Jun 17 21:24:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jun 2007 12:24:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1687867 ] check_http: buffer overflow vulnerability Message-ID: Bugs item #1687867, was opened at 2007-03-25 18:37 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1687867&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: buffer overflow vulnerability Initial Comment: Description: Buffer overflows within the redir() function of check_http.c potentially allow remote attackers to execute arbitrary code via crafted ``Location:'' responses. This vulnerability is caused by passing insufficient length buffers to sscanf(). Example of crafted ``Location:'' response: o Location: htttttttttttttttttttttttttttttttttttttttttttp://example.com/ o Location: http://example.com:1234567890123456789012345678901234567890/ o Location: http://tooooooooooooooooooooooooooooooooooooooooooooooooooo.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong.host-name.example.com/ Workaround: Do not check untrusted web server with ``-f follow'' option. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-17 21:24 Message: Logged In: YES user_id=759506 Originator: NO This is now fixed in CVS. Thank you very much! ---------------------------------------------------------------------- Comment By: Nobuhiro Ban (ban_nobuhiro) Date: 2007-06-16 20:35 Message: Logged In: YES user_id=1699577 Originator: YES Because this contains some vulnerability information, I marked this report as confidential (private), Over 80 days have passed, and the vulnerability exist still now. So I open this to public. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1687867&group_id=29880 From ton.voon at altinity.com Mon Jun 18 11:22:45 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 18 Jun 2007 10:22:45 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <46723D31.9050105@mailing.kaufland-informationssysteme.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> <50A77A27-1CCF-4668-98D0-D4453EEE5255@altinity.com> <46723D31.9050105@mailing.kaufland-informationssysteme.com> Message-ID: <3D13A3EB-D7E0-4B50-8284-EE3548217963@altinity.com> On 15 Jun 2007, at 08:18, Matthias Eble wrote: > Ton Voon schrieb: >> $ ./check_tcp --version >> check_tcp (nagios-plugins 1.4.9) 1729 >> >> Would it make sense to append a v to the beginning of 1729? > I'd say that would make sense. I could also imagine this order: > check_tcp v1729 (nagios-plugins 1.4.9) > I'm happy with that. Do you want to make the change? Of course, you'll need to save your changes for applying to svn when it goes live, but feel free to commit to the test svn now - it might show up some other peculiarities. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Jun 18 11:29:04 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 18 Jun 2007 10:29:04 +0100 Subject: [Nagiosplug-devel] usage of the bool type In-Reply-To: <46641A56.5040102@mailing.kaufland-informationssysteme.com> References: <46615E3F.8080308@mailing.kaufland-informationssysteme.com> <20070603180116.GK8296755@CIS.FU-Berlin.DE> <8185D2BF-7DD8-4B07-A746-893C0B926E79@altinity.com> <46641A56.5040102@mailing.kaufland-informationssysteme.com> Message-ID: <517B98EF-1D27-411A-BBAE-3B0F903AD5F5@altinity.com> On 4 Jun 2007, at 14:57, Matthias Eble wrote: > But we could add a hint to the guidelines to avoid bools/true/false > for > consistency purposes and instead use int/TRUE/FALSE. Matthias, Could you add this into the dev guidelines? My plans for the dev guidelines is that, as others have suggested on the list, it should be split into two documents, say, Nagios Plugins specification guidelines, and a Nagios Plugins team guidelines. The spec guideline describes what should be done for a plugin (return codes, output, command line options, etc), whereas the team guidelines describes best working practice (such as the bools issue). I'd like both hosted on http://nagiosplugins.org, but I don't like the editing facilities on the web site - I've asked Benoit to try and get a different module installed. In the meantime, the CVS is still the master copy. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Tue Jun 19 04:20:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 19:20:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1447642 ] check_ping segmentation fault on Solaris 10 Message-ID: Bugs item #1447642, was opened at 2006-03-10 16:11 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1447642&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Matisse Enzer (matisse) Assigned to: Ton Voon (tonvoon) Summary: check_ping segmentation fault on Solaris 10 Initial Comment: Hmmm. The check_ping plugin dumps core.... Is this a known issue? ~/nagios/libexec: uname -a SunOS rdcuxsrv143 5.10 Generic_118822-20 sun4u sparc SUNW,Sun-Fire-V890 Solaris ~/nagios/libexec: ./check_ping -H localhost -w "99,5%" -c "100,20%" -p 1 Segmentation fault (core dumped) ~/nagios/libexec: And here's the tailend of truss output: 3980: open64("/var/run/name_service_door", O_RDONLY) = 3 3980: fcntl(3, F_SETFD, 0x00000001) = 0 3980: door_info(3, 0xFEBEF7E8) = 0 3980: door_call(3, 0xFFBFC1F8) = 0 3980: brk(0x0002B7E8) = 0 3980: brk(0x0002D7E8) = 0 3980: sigaction(SIGALRM, 0xFFBFE778, 0xFFBFE818) = 0 3980: alarm(10) = 0 3980: fstat64(63, 0xFFBFD978) Err#9 EBADF 3980: fstat64(63, 0xFFBFD820) Err#9 EBADF 3980: ioctl(63, TCGETA, 0xFFBFD904) Err#9 EBADF 3980: Incurred fault #6, FLTBOUNDS %pc = 0xFF1D099C 3980: siginfo: SIGSEGV SEGV_MAPERR addr=0x0002E000 3980: Received signal #11, SIGSEGV [default] 3980: sigi ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-18 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 01:45 Message: Logged In: YES user_id=1694341 Originator: NO Hi Matisse, could you try a later version of check_ping? We have a solaris 10 system in our buildfarm and check_ping currently shows no issues there. Will set this item to pending, so it will be automatically closed if you won't reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-03-11 00:16 Message: Logged In: YES user_id=664364 Matisse, There was a reported coredump on check_ping a few weeks back which has been fixed in CVS. Please try the snapshot at http://nagiosplug.sf.net/ snapshot. Alternatively, please try check_icmp which checks network connectivity natively. The snapshot will install with suid if make install is run as root. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1447642&group_id=29880 From noreply at sourceforge.net Tue Jun 19 04:20:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 19:20:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1119903 ] check_snmp_storage.pl 1.1 fails with AIX Message-ID: Bugs item #1119903, was opened at 2005-02-10 00:56 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1119903&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Vincent Cuirassier (vcuirassier) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp_storage.pl 1.1 fails with AIX Initial Comment: I'm using the nagios-plugins-1.3.1-5mdk Mandrake RPM, which includes version 1.1 of check_snmp_storage.pl. I can make successful requests to the Linux SNMP agent (net-snmp-5.1-7mdk), but the following command fails to query the AIX SNMP agent : # check_snmp_storage.pl -H aixhost -C public -m /home -w 60 -c 80 Alarm at 15 + 5 ERROR: Description table : Requested table is empty or does not exist. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-18 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-04 01:33 Message: Logged In: YES user_id=1694341 Originator: NO Hi Vincent, I have searched the mailing list archive but could not find any further posts on this topic. Could you resolve this problem in the meantime? However, according to the posts, this seems to be a problem with your SNMP deamon rather than a bug of check_snmp_storage. I'm setting this item to pending. The Item will get deleted if you won't reply in the next 14 days. Thanks for your report, Matthias ---------------------------------------------------------------------- Comment By: Patrick Proy (patrickproy) Date: 2005-02-23 15:38 Message: Logged In: YES user_id=124902 To linguafr : The mib FILE is here, but ir doesn't mean the snmp daemon handles it. On linux, it should work : just try with the snmpwalk command instead (snmpget on this oid will always fail) or get the latest net-snmp version. To vcuirassier : I don't know much about the AIX snmp agent. The aim is to have the snmpwalk command give some output for the oid, but I have no idea how. If IBM says it's OK, ask them... Did you give net-snmp a try ? Note : Please continue this thread in the nagiosplug mailling list : I can just put comments here, and I hate writing in this small comment box... Patrick nagios AT proy. org ---------------------------------------------------------------------- Comment By: Bill F (linguafr) Date: 2005-02-23 15:08 Message: Logged In: YES user_id=1080464 turns out HOST-RESOURCES-MIB is an optional mib that needed to be compiled in as a configure option. It now works ---------------------------------------------------------------------- Comment By: Bill F (linguafr) Date: 2005-02-23 12:59 Message: Logged In: YES user_id=1080464 I'm having the same problem on the following system Linux earth.epd.com 2.4.21-20.0.1.ELsmp #1 SMP Wed Nov 24 20:34:01 EST 2004 i686 i686 i386 GNU/Linux [root at earth root]# /usr/local/sbin/snmpd -v NET-SNMP version: 5.2.1 Web: http://www.net-snmp.org/ Email: net-snmp-coders at lists.sourceforge.net ps -ef|grep snmpd root 5368 1 0 Feb22 ? 00:00:03 /usr/local/sbin/snmpd -c /usr/local/share/snmp/snmpd.conf -M /usr/local/share/snmp/mibs -d -Lf /var/log/snmpd.log -p /var/run/snmpd -a [root at centauri etc]# snmpget -v 1 earth -c ****** 1.3.6.1.2.1.25.2.3.1 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: HOST-RESOURCES-MIB::hrStorageEntry ....but the mib is here [root at earth root]# ls /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB* /usr/local/share/snmp/mibs/HOST-RESOURCES-MIB.txt ---------------------------------------------------------------------- Comment By: Vincent Cuirassier (vcuirassier) Date: 2005-02-18 03:47 Message: Logged In: YES user_id=1216109 According to IBM docs, the AIX SNMP agent implements the HOST-RESOURCES-MIB. But the snmpwalk command that you provided did not produce any output. ---------------------------------------------------------------------- Comment By: Patrick Proy (patrickproy) Date: 2005-02-11 13:42 Message: Logged In: YES user_id=124902 This plugin was never tested on AIX, but it can work on any plaforms with MIBII compliance. Does AIX snmp daemon implements the HOST-RESOURCES-MIB ? Try an snmpwalk on the oid "1.3.6.1.2.1.25.2.3.1" . Patrick Proy nagios at proy.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1119903&group_id=29880 From noreply at sourceforge.net Tue Jun 19 08:26:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 23:26:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1094326 ] check-ide-smart does not build Message-ID: Bugs item #1094326, was opened at 2005-01-02 04:53 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Reuben Farrelly (reuben) Assigned to: Benoit Mortier (opensides) Summary: check-ide-smart does not build Initial Comment: The .c file remains unbuilt in the plugins directory, after a build run: -rw-r--r-- 1 root root 11217 Dec 26 22:43 check_ide_smart.c Upon invoking 'make check_ide_smart', I then get a compile failure: [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:452: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:452: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:491: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here check_ide_smart.c: In function `print_usage': check_ide_smart.c:518: error: syntax error before ')' token make: *** [check_ide_smart.o] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 08:26 Message: Logged In: YES user_id=1694341 Originator: NO Update: In CVS I fixed the syntax errors and added some hopefully appropriate configure conditions to so that the plugin will actually build. I don't have a sata disk here so I cannot test the described problems with them. Can someone else test if this is a general problem? ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 14:08 Message: Logged In: YES user_id=1694341 Originator: NO This plugin still/again does not build properly, beside the sata problem. make check_ide_smart works after some small changes.. will look at this later.. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-05 07:34 Message: Logged In: YES user_id=26209 Compiles clearly now, some other little problems, but this is progress ;-) 1. Does not get installed when running 'make install'. 2. Running without arguments just silently fails, it ought to output something, perhaps the output of ./check_ide_smart -h 3. Seems to be failing when run: [root at tornado plugins]# ./check_ide_smart -d /dev/sda CRITICAL - SMART_ENABLE: Inappropriate ioctl for device CRITICAL - SMART_CMD_ENABLE [root at tornado plugins]# [root at tornado plugins]# ./check_ide_smart -d /dev/sda -n CRITICAL - Couldn't open device: No such file or directory [root at tornado plugins]# I'm using SATA drives. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-04 01:18 Message: Logged In: YES user_id=388184 Hi, i just committed another fix in the cvs please try..and tell me..;-) ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-03 23:47 Message: Logged In: YES user_id=26209 Better, but still not quite there: [root at tornado plugins]# make check_ide_smart gcc -g -O2 -L. -L/usr/lib -o check_ide_smart check_ide_smart.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -I/usr/include check_ide_smart.o(.text+0x87e): In function `main': /usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:222: undefined reference to `show_help' check_ide_smart.o(.text+0x883):/usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:223: undefined reference to `show_version' collect2: ld returned 1 exit status make: *** [check_ide_smart] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 02:38 Message: Logged In: YES user_id=388184 hi, i have corrected some more problems ;-) Could you just check this version out of cvs ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 21:29 Message: Logged In: YES user_id=26209 Still fails to build (but looks slightly better now) [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:451: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:451: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:490: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here make: *** [check_ide_smart.o] Error 1 [root at tornado plugins] I'm using GCC 3.4.3 (Fedora Core 3) FWIW. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 19:37 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 15:04 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jun 19 09:23:36 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 19 Jun 2007 09:23:36 +0200 Subject: [Nagiosplug-devel] check_ide_smart [Fwd: nagiosplug configure.in, 1.218, 1.219 REQUIREMENTS, 1.13, 1.14] Message-ID: <46778478.3080100@mailing.kaufland-informationssysteme.com> Hi all, I made some changes to configure.in to get check_ide_smart to work again (see #1094326). I'd be really glad if somebody could review if checking the headers for availability is sufficient. Am I right, that the check_ide_smart needs root privileges? If yes, it needs to be moved to plugins-root (after another review?). Additionally #1094326 claims there is an issue with sata disks. Can somebody verify this? Matthias -------- Original-Nachricht -------- Betreff: [Nagiosplug-checkins] nagiosplug configure.in, 1.218, 1.219 REQUIREMENTS, 1.13, 1.14 Datum: Mon, 18 Jun 2007 20:20:59 +0000 Von: Matthias Eble Antwort an: nagiosplug-devel at lists.sourceforge.net An: nagiosplug-checkins at lists.sourceforge.net Update of /cvsroot/nagiosplug/nagiosplug In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv25431 Modified Files: configure.in REQUIREMENTS Log Message: Make Linux specific plugin check_ide_smart build if appropriate headers are found Index: REQUIREMENTS =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/REQUIREMENTS,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 --- REQUIREMENTS 23 Jan 2007 18:20:49 -0000 1.13 +++ REQUIREMENTS 18 Jun 2007 20:20:55 -0000 1.14 @@ -67,6 +67,9 @@ - Requires Network UPS Tools (>= 1.4) to run on the server to monitor http://www.networkupstools.org/ +check_ide_smart: + - Uses the Linux specific SMART interface [http://smartlinux.sourceforge.net/smart/index.php]. + OS Specific Issues ------------------ Index: configure.in =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/configure.in,v retrieving revision 1.218 retrieving revision 1.219 diff -u -d -r1.218 -r1.219 --- configure.in 4 Jun 2007 08:58:13 -0000 1.218 +++ configure.in 18 Jun 2007 20:20:55 -0000 1.219 @@ -240,6 +240,19 @@ fi LIBS="$_SAVEDLIBS" +dnl Check for headers used by check_ide_smart +AC_CHECK_HEADER(linux/hdreg.h, FOUNDINCLUDE=yes, FOUNDINCLUDE=no) +if test "$FOUNDINCLUDE" = "yes" ; then + AC_CHECK_HEADER(linux/types.h, FOUNDINCLUDE=yes, FOUNDINCLUDE=no) +fi + +if test "$FOUNDINCLUDE" = "yes" ; then + EXTRAS="$EXTRAS check_ide_smart" +else + AC_MSG_WARN([Skipping check_ide_smart plugin.]) + AC_MSG_WARN([check_ide_smart is linux specific. It requires linux/hdreg.h and linux/types.h.]) +fi + dnl Check for mysql libraries np_mysqlclient if test $with_mysql = "no" ; then ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Nagiosplug-checkins mailing list Nagiosplug-checkins at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-checkins From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jun 19 09:30:29 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 19 Jun 2007 09:30:29 +0200 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <3D13A3EB-D7E0-4B50-8284-EE3548217963@altinity.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <4671B0C3.8070903@mailing.kaufland-informationssysteme.com> <50A77A27-1CCF-4668-98D0-D4453EEE5255@altinity.com> <46723D31.9050105@mailing.kaufland-informationssysteme.com> <3D13A3EB-D7E0-4B50-8284-EE3548217963@altinity.com> Message-ID: <46778615.2020804@mailing.kaufland-informationssysteme.com> Ton Voon schrieb: > On 15 Jun 2007, at 08:18, Matthias Eble wrote: > >> Ton Voon schrieb: >>> $ ./check_tcp --version >>> check_tcp (nagios-plugins 1.4.9) 1729 >>> >>> Would it make sense to append a v to the beginning of 1729? >> I'd say that would make sense. I could also imagine this order: >> check_tcp v1729 (nagios-plugins 1.4.9) >> > > I'm happy with that. Do you want to make the change? > > Of course, you'll need to save your changes for applying to svn when > it goes live, but feel free to commit to the test svn now - it might > show up some other peculiarities. I'm fine with doing this. I guess moving the revision number to the front can be done before switching. After then only the 'v' needs to be added. matthias From noreply at sourceforge.net Tue Jun 19 11:02:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 02:02:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1094326 ] check-ide-smart does not build Message-ID: Bugs item #1094326, was opened at 2005-01-02 14:53 Message generated for change (Comment added) made by reuben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Reuben Farrelly (reuben) Assigned to: Benoit Mortier (opensides) Summary: check-ide-smart does not build Initial Comment: The .c file remains unbuilt in the plugins directory, after a build run: -rw-r--r-- 1 root root 11217 Dec 26 22:43 check_ide_smart.c Upon invoking 'make check_ide_smart', I then get a compile failure: [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:452: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:452: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:491: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here check_ide_smart.c: In function `print_usage': check_ide_smart.c:518: error: syntax error before ')' token make: *** [check_ide_smart.o] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- >Comment By: Reuben Farrelly (reuben) Date: 2007-06-19 19:02 Message: Logged In: YES user_id=26209 Originator: YES Builds fine on Gentoo and seems to function good with a SATA drive: tornado plugins # ./check_ide_smart -d /dev/sda Id= 1, Status=15 {PreFailure , OnLine }, Value=114, Threshold= 6, Passed Id= 3, Status= 3 {PreFailure , OnLine }, Value= 98, Threshold= 0, Passed Id= 4, Status=50 {Advisory , OnLine }, Value=100, Threshold= 20, Passed Id= 5, Status=51 {PreFailure , OnLine }, Value=100, Threshold= 36, Passed Id= 7, Status=15 {PreFailure , OnLine }, Value= 84, Threshold= 30, Passed Id= 9, Status=50 {Advisory , OnLine }, Value= 91, Threshold= 0, Passed Id= 10, Status=19 {PreFailure , OnLine }, Value=100, Threshold= 97, Passed Id= 12, Status=50 {Advisory , OnLine }, Value=100, Threshold= 20, Passed Id=187, Status=50 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=189, Status=58 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=190, Status=34 {Advisory , OnLine }, Value= 74, Threshold= 45, Passed Id=194, Status=34 {Advisory , OnLine }, Value= 26, Threshold= 0, Passed Id=195, Status=26 {Advisory , OnLine }, Value= 63, Threshold= 0, Passed Id=197, Status=18 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=198, Status=16 {Advisory , OffLine}, Value=100, Threshold= 0, Passed Id=199, Status=62 {Advisory , OnLine }, Value=200, Threshold= 0, Passed Id=200, Status= 0 {Advisory , OffLine}, Value=100, Threshold= 0, Passed Id=202, Status=50 {Advisory , OnLine }, Value=100, Threshold= 0, Passed OffLineStatus=130 {Completed}, AutoOffLine=Yes, OffLineTimeout=7 minutes OffLineCapability=91 {Immediate Auto SuspendOnCmd} SmartRevision=10, CheckSum=246, SmartCapability=3 {SaveOnStandBy AutoSave} tornado plugins # and tornado plugins # ./check_ide_smart -d /dev/sda -n OK - Operational (18/18 tests passed) tornado plugins # So I'd say that's all looking fixed. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 16:26 Message: Logged In: YES user_id=1694341 Originator: NO Update: In CVS I fixed the syntax errors and added some hopefully appropriate configure conditions to so that the plugin will actually build. I don't have a sata disk here so I cannot test the described problems with them. Can someone else test if this is a general problem? ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 22:08 Message: Logged In: YES user_id=1694341 Originator: NO This plugin still/again does not build properly, beside the sata problem. make check_ide_smart works after some small changes.. will look at this later.. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-05 17:34 Message: Logged In: YES user_id=26209 Compiles clearly now, some other little problems, but this is progress ;-) 1. Does not get installed when running 'make install'. 2. Running without arguments just silently fails, it ought to output something, perhaps the output of ./check_ide_smart -h 3. Seems to be failing when run: [root at tornado plugins]# ./check_ide_smart -d /dev/sda CRITICAL - SMART_ENABLE: Inappropriate ioctl for device CRITICAL - SMART_CMD_ENABLE [root at tornado plugins]# [root at tornado plugins]# ./check_ide_smart -d /dev/sda -n CRITICAL - Couldn't open device: No such file or directory [root at tornado plugins]# I'm using SATA drives. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-04 11:18 Message: Logged In: YES user_id=388184 Hi, i just committed another fix in the cvs please try..and tell me..;-) ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-04 09:47 Message: Logged In: YES user_id=26209 Better, but still not quite there: [root at tornado plugins]# make check_ide_smart gcc -g -O2 -L. -L/usr/lib -o check_ide_smart check_ide_smart.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -I/usr/include check_ide_smart.o(.text+0x87e): In function `main': /usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:222: undefined reference to `show_help' check_ide_smart.o(.text+0x883):/usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:223: undefined reference to `show_version' collect2: ld returned 1 exit status make: *** [check_ide_smart] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 12:38 Message: Logged In: YES user_id=388184 hi, i have corrected some more problems ;-) Could you just check this version out of cvs ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-03 07:29 Message: Logged In: YES user_id=26209 Still fails to build (but looks slightly better now) [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:451: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:451: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:490: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here make: *** [check_ide_smart.o] Error 1 [root at tornado plugins] I'm using GCC 3.4.3 (Fedora Core 3) FWIW. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 05:37 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 01:04 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 From noreply at sourceforge.net Tue Jun 19 11:18:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 02:18:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1094326 ] check-ide-smart does not build Message-ID: Bugs item #1094326, was opened at 2005-01-02 04:53 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&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: Compilation Group: CVS >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Reuben Farrelly (reuben) Assigned to: Benoit Mortier (opensides) Summary: check-ide-smart does not build Initial Comment: The .c file remains unbuilt in the plugins directory, after a build run: -rw-r--r-- 1 root root 11217 Dec 26 22:43 check_ide_smart.c Upon invoking 'make check_ide_smart', I then get a compile failure: [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:452: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:452: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:491: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here check_ide_smart.c: In function `print_usage': check_ide_smart.c:518: error: syntax error before ')' token make: *** [check_ide_smart.o] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 11:18 Message: Logged In: YES user_id=1694341 Originator: NO Reuben, thank you for your quick testing and reply. I'm closing this item since all your problems seem to be solved. Have a nice day. Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-06-19 11:02 Message: Logged In: YES user_id=26209 Originator: YES Builds fine on Gentoo and seems to function good with a SATA drive: tornado plugins # ./check_ide_smart -d /dev/sda Id= 1, Status=15 {PreFailure , OnLine }, Value=114, Threshold= 6, Passed Id= 3, Status= 3 {PreFailure , OnLine }, Value= 98, Threshold= 0, Passed Id= 4, Status=50 {Advisory , OnLine }, Value=100, Threshold= 20, Passed Id= 5, Status=51 {PreFailure , OnLine }, Value=100, Threshold= 36, Passed Id= 7, Status=15 {PreFailure , OnLine }, Value= 84, Threshold= 30, Passed Id= 9, Status=50 {Advisory , OnLine }, Value= 91, Threshold= 0, Passed Id= 10, Status=19 {PreFailure , OnLine }, Value=100, Threshold= 97, Passed Id= 12, Status=50 {Advisory , OnLine }, Value=100, Threshold= 20, Passed Id=187, Status=50 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=189, Status=58 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=190, Status=34 {Advisory , OnLine }, Value= 74, Threshold= 45, Passed Id=194, Status=34 {Advisory , OnLine }, Value= 26, Threshold= 0, Passed Id=195, Status=26 {Advisory , OnLine }, Value= 63, Threshold= 0, Passed Id=197, Status=18 {Advisory , OnLine }, Value=100, Threshold= 0, Passed Id=198, Status=16 {Advisory , OffLine}, Value=100, Threshold= 0, Passed Id=199, Status=62 {Advisory , OnLine }, Value=200, Threshold= 0, Passed Id=200, Status= 0 {Advisory , OffLine}, Value=100, Threshold= 0, Passed Id=202, Status=50 {Advisory , OnLine }, Value=100, Threshold= 0, Passed OffLineStatus=130 {Completed}, AutoOffLine=Yes, OffLineTimeout=7 minutes OffLineCapability=91 {Immediate Auto SuspendOnCmd} SmartRevision=10, CheckSum=246, SmartCapability=3 {SaveOnStandBy AutoSave} tornado plugins # and tornado plugins # ./check_ide_smart -d /dev/sda -n OK - Operational (18/18 tests passed) tornado plugins # So I'd say that's all looking fixed. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 08:26 Message: Logged In: YES user_id=1694341 Originator: NO Update: In CVS I fixed the syntax errors and added some hopefully appropriate configure conditions to so that the plugin will actually build. I don't have a sata disk here so I cannot test the described problems with them. Can someone else test if this is a general problem? ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 14:08 Message: Logged In: YES user_id=1694341 Originator: NO This plugin still/again does not build properly, beside the sata problem. make check_ide_smart works after some small changes.. will look at this later.. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-05 07:34 Message: Logged In: YES user_id=26209 Compiles clearly now, some other little problems, but this is progress ;-) 1. Does not get installed when running 'make install'. 2. Running without arguments just silently fails, it ought to output something, perhaps the output of ./check_ide_smart -h 3. Seems to be failing when run: [root at tornado plugins]# ./check_ide_smart -d /dev/sda CRITICAL - SMART_ENABLE: Inappropriate ioctl for device CRITICAL - SMART_CMD_ENABLE [root at tornado plugins]# [root at tornado plugins]# ./check_ide_smart -d /dev/sda -n CRITICAL - Couldn't open device: No such file or directory [root at tornado plugins]# I'm using SATA drives. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-04 01:18 Message: Logged In: YES user_id=388184 Hi, i just committed another fix in the cvs please try..and tell me..;-) ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-03 23:47 Message: Logged In: YES user_id=26209 Better, but still not quite there: [root at tornado plugins]# make check_ide_smart gcc -g -O2 -L. -L/usr/lib -o check_ide_smart check_ide_smart.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -I/usr/include check_ide_smart.o(.text+0x87e): In function `main': /usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:222: undefined reference to `show_help' check_ide_smart.o(.text+0x883):/usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:223: undefined reference to `show_version' collect2: ld returned 1 exit status make: *** [check_ide_smart] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 02:38 Message: Logged In: YES user_id=388184 hi, i have corrected some more problems ;-) Could you just check this version out of cvs ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 21:29 Message: Logged In: YES user_id=26209 Still fails to build (but looks slightly better now) [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:451: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:451: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:490: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here make: *** [check_ide_smart.o] Error 1 [root at tornado plugins] I'm using GCC 3.4.3 (Fedora Core 3) FWIW. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 19:37 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 15:04 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 From noreply at sourceforge.net Tue Jun 19 15:29:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 06:29:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) >Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 16:29:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 07:29:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 17:25:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:25:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 17:38:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:38:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 12:18 Message generated for change (Comment added) made by rouilj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: John Rouillard (rouilj) Date: 2007-06-19 11:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 11:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 10:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 09:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 12:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 12:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 17:48:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:48:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:48 Message: Logged In: YES user_id=1694341 Originator: NO Today i have read about a user expecting ldaps to connect to 636 in a forum. But using the direct connection seems to be deprecated according to http://www.openldap.org/lists/openldap-software/200409/msg00617.html So startTLS should be the right way to make it. I couldn't find out if ldap_start_tls_s() eventually makes a secure connect after the query on the default port. IMO it should do so. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2007-06-19 17:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 18:30:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 09:30:02 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 18:30 Message: Logged In: YES user_id=1694341 Originator: NO For the records: wikipedia claims: >A common alternate method of securing LDAP communication is using an SSL tunnel. This is >denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL >is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never >standardized in any formal specification. This usage has been deprecated along with >LDAPv2, which was officially retired in 2003 so if i got it right, starttls starts a tls connection on port 389, ssl on connect uses ssl wrapped around normal ldap since tls was not included in ldap that time I'd say these steps need to be done? - introduce an argument --old-ldaps to force direct connection to 636 - keep default behaviour if -p 636 is given -> ldaps - set default port to 636 if --old-ldaps is defined - introduce default behaviour (startTLS) in --help what do you think? matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:48 Message: Logged In: YES user_id=1694341 Originator: NO Today i have read about a user expecting ldaps to connect to 636 in a forum. But using the direct connection seems to be deprecated according to http://www.openldap.org/lists/openldap-software/200409/msg00617.html So startTLS should be the right way to make it. I couldn't find out if ldap_start_tls_s() eventually makes a secure connect after the query on the default port. IMO it should do so. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2007-06-19 17:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jun 19 19:02:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 10:02:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-06-19 19:02 Message: Logged In: YES user_id=759506 Originator: NO Personally, I'd find "--old-ldaps" a bit confusing, too. I'd suggest: 1) By default, keep the current behaviour for backwards compatibility. 2) Introduce two new flags: - "-T/--starttls", which forces, well, STARTTLS. - "-S/--ssl", which forces "SSL on connect" and sets the default port to 636 (even nicer would be to use getservbyname(3), but IIRC we do that nowhere, so that's a different story). If "--ssl" seems too ambiguous, it could be called "--ssl-on-connect" or so, but I'd prefer "--ssl" as "check_http", "check_tcp" and possibly other plugins use it. If either option is used, the plugin doesn't care about argv[0] nor about the specified port. If neither option is used, you get the current behaviour. 3) Document the default behaviour, and maybe also mark it as deprecated: "If this plugin is called via 'check_ldaps', 'STARTTLS' will be used, unless --port=636 is specified, in which case 'SSL on connect' will be used. This behaviour is deprecated, please use 'check_ldap' with the '--starttls' or '--ssl' flags instead." Just my 2?, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 18:30 Message: Logged In: YES user_id=1694341 Originator: NO For the records: wikipedia claims: >A common alternate method of securing LDAP communication is using an SSL tunnel. This is >denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL >is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never >standardized in any formal specification. This usage has been deprecated along with >LDAPv2, which was officially retired in 2003 so if i got it right, starttls starts a tls connection on port 389, ssl on connect uses ssl wrapped around normal ldap since tls was not included in ldap that time I'd say these steps need to be done? - introduce an argument --old-ldaps to force direct connection to 636 - keep default behaviour if -p 636 is given -> ldaps - set default port to 636 if --old-ldaps is defined - introduce default behaviour (startTLS) in --help what do you think? matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:48 Message: Logged In: YES user_id=1694341 Originator: NO Today i have read about a user expecting ldaps to connect to 636 in a forum. But using the direct connection seems to be deprecated according to http://www.openldap.org/lists/openldap-software/200409/msg00617.html So startTLS should be the right way to make it. I couldn't find out if ldap_start_tls_s() eventually makes a secure connect after the query on the default port. IMO it should do so. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2007-06-19 17:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From alessandro.ren at opservices.com.br Tue Jun 19 22:33:18 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Tue, 19 Jun 2007 17:33:18 -0300 Subject: [Nagiosplug-devel] nsclient new features. Message-ID: <46783D8E.5080804@opservices.com.br> I want to add some new features to the nsclient, like support to run remote programs much like nrpe-nt and WMI but I can not locate the author to ask him if I can do that. I've tried to talk to him via his homepage, http://nsclient.ready2run.nl/. Does anybody know if the code is opensource or how could I get in touch with him? Thanks. Alessandro Ren http://www.opservices.com.br From Thomas at zango.com Tue Jun 19 22:52:08 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 19 Jun 2007 13:52:08 -0700 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <46783D8E.5080804@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> Message-ID: <804160344192334BB21922E8082EA6C09BE5FD@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Alessandro Ren > Sent: June 19, 2007 16:33 > To: Nagios Developers List; nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] nsclient new features. > > > I want to add some new features to the nsclient, like support to run > remote programs much like nrpe-nt and WMI but I can not locate the > author to ask him if I can do that. I've tried to talk to him via his > homepage, http://nsclient.ready2run.nl/. > Does anybody know if the code is opensource or how could I get in > touch with him? You should look at NC_Net (http://www.shatterit.com/nc_net/) or NSClient++ (http://trac.nakednuns.org/nscp/). They already have some (all?) of the features you want and the source code is available for both. On a side note, please avoid cross-posting questions to multiple mailing lists and send them to the users/help lists if they are not directly related to the development of the application (For this question you could have asked nagios-users at lists.sourceforge.net or nagiosplug-help at lists.sourceforge.net). Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From alessandro.ren at opservices.com.br Tue Jun 19 23:04:00 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Tue, 19 Jun 2007 18:04:00 -0300 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <804160344192334BB21922E8082EA6C09BE5FD@seaex01.180solutions.com> References: <46783D8E.5080804@opservices.com.br> <804160344192334BB21922E8082EA6C09BE5FD@seaex01.180solutions.com> Message-ID: <467844C0.50705@opservices.com.br> Thomas Guyot-Sionnest wrote: >> -----Original Message----- >> From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- >> devel-bounces at lists.sourceforge.net] On Behalf Of Alessandro Ren >> Sent: June 19, 2007 16:33 >> To: Nagios Developers List; nagiosplug-devel at lists.sourceforge.net >> Subject: [Nagiosplug-devel] nsclient new features. >> >> >> I want to add some new features to the nsclient, like support to run >> remote programs much like nrpe-nt and WMI but I can not locate the >> author to ask him if I can do that. I've tried to talk to him via his >> homepage, http://nsclient.ready2run.nl/. >> Does anybody know if the code is opensource or how could I get in >> touch with him? >> > > You should look at NC_Net (http://www.shatterit.com/nc_net/) or NSClient++ > (http://trac.nakednuns.org/nscp/). They already have some (all?) of the > features you want and the source code is available for both. > > On a side note, please avoid cross-posting questions to multiple mailing > lists and send them to the users/help lists if they are not directly related > to the development of the application (For this question you could have > asked nagios-users at lists.sourceforge.net or > nagiosplug-help at lists.sourceforge.net). > > Thanks, > > Thomas > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________________ > 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 Thomas, We've already used the clients you mentioned, but we had some problems with them. Nsclient has been very stable and we'd like to upgrade it a little, as it's been stale for a long time now. Sorry for cross posting, I though it would reach more nagios people interested in upgrading nsclient. We already compiled the code that comes with it and have fixed a connection limit that nsclient had of 5 simultaneos connections and we like to go further and give this client to the community, that's why I'd like to check the license or talk to the author. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Wed Jun 20 00:18:02 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 20 Jun 2007 00:18:02 +0200 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <46783D8E.5080804@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> Message-ID: <20070619221802.GV4705358@CIS.FU-Berlin.DE> * Alessandro Ren [2007-06-19 17:33]: > I want to add some new features to the nsclient, like support to run > remote programs much like nrpe-nt and WMI but I can not locate the > author to ask him if I can do that. I've tried to talk to him via his > homepage, http://nsclient.ready2run.nl/. > Does anybody know if the code is opensource | License | | NSClient and NSClientEVL are licensed under the terms of the GNU General | Public License Version 2 as published by the Free Software Foundation. | This gives you legal permission to copy, distribute and/or modify | NSClient/NSClientEVL under certain conditions. [ http://nsclient.ready2run.nl/products.htm ] Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Wed Jun 20 04:20:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 19:20:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 06:33 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-19 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 08:29 Message: Logged In: YES user_id=759506 Originator: NO Errm, we are aware of "--with-ping-command", but we were trying to fix a problem you reported! :-) PING_COMMAND should be set correctly out-of-the-box. If this doesn't happen, that would be a bug. And it definitely makes sense to fix bugs not only within some OS-specific package/port, but also upstream in order to make life easier for the package/port maintainer and for people who install the plugins manually for some reason. I set the status back to 'pending'. Holger ---------------------------------------------------------------------- Comment By: Pentarh Udi (pentarh) Date: 2007-06-05 08:19 Message: Logged In: YES user_id=1694463 Originator: YES There is a configure option --with-ping-command or something similar. You can check it via "./configure --help". Also I suggest to install it from FreeBSD ports - there are no problems. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 08:05 Message: Logged In: YES user_id=759506 Originator: NO Good idea IMO. Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 08:04 Message: Logged In: YES user_id=1694341 Originator: NO sbin is in $PATH by default at least on my freebsd 6.2 box. Should we consider to add the common pathes like /bin, /usr/bin, /sbin, and /usr/sbin to the configure script (after searching $PATH)? Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-05 07:07 Message: Logged In: YES user_id=759506 Originator: NO I cannot reproduce this on a FreeBSD 5.5-STABLE (2006-11-06) box, neither with check_ping 1.4.5 nor with 1.4.9: $ ./configure $ grep PING_COMMAND config.h #define PING_COMMAND "/sbin/ping -n -c %d %s" I _can_ of course reproduce the problem if I remove /sbin from my $PATH prior to "./configure", though. I'd guess this was the problem here. Please let us know whether you can still reproduce the problem with check_ping 1.4.9 and after verifying that your $PATH includes "/sbin". For the moment, I set the status of the bug report to 'pending', which means that it'll be closed automatically if we don't get further feedback. Thanks a lot, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 04:25 Message: Logged In: YES user_id=1694341 Originator: NO I tried this with freebsd 6.2 but cannot reproduce the problem. Has anyone of the devs got a freebsd 5.4 box up and running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From ms at op5.se Wed Jun 20 08:37:35 2007 From: ms at op5.se (Mathias Sundman) Date: Wed, 20 Jun 2007 08:37:35 +0200 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <467844C0.50705@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <804160344192334BB21922E8082EA6C09BE5FD@seaex01.180solutions.com> <467844C0.50705@opservices.com.br> Message-ID: <4678CB2F.1040504@op5.se> Alessandro Ren wrote: > Thomas Guyot-Sionnest wrote: >>> -----Original Message----- >>> From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- >>> devel-bounces at lists.sourceforge.net] On Behalf Of Alessandro Ren >>> Sent: June 19, 2007 16:33 >>> To: Nagios Developers List; nagiosplug-devel at lists.sourceforge.net >>> Subject: [Nagiosplug-devel] nsclient new features. >>> >>> >>> I want to add some new features to the nsclient, like support to run >>> remote programs much like nrpe-nt and WMI but I can not locate the >>> author to ask him if I can do that. I've tried to talk to him via his >>> homepage, http://nsclient.ready2run.nl/. >>> Does anybody know if the code is opensource or how could I get in >>> touch with him? >>> >> >> You should look at NC_Net (http://www.shatterit.com/nc_net/) or NSClient++ >> (http://trac.nakednuns.org/nscp/). They already have some (all?) of the >> features you want and the source code is available for both. > > We've already used the clients you mentioned, but we had some problems > with them. What problems have you had with NSClient++? We have a lot of customers using it, so it's in our very interest that it is stable. Unfortunally v0.2.7 introduced a bug [1]. I tracked it down this weekend though and emailed MickeM, the author of NSClient++ the details and am now waiting for a new official release. In the meantime I'va compiled and packaged a fixed version for our customers. We are now beta testing it internally. Feel free to use our version if you like [2]. You also get an easy to use MSI installation package :-) [1] http://trac.nakednuns.org/nscp/ticket/53 [2] https://support.op5.se/clients/nsclientpp/op5_NSClientpp-0.2.7.1.msi -- A. Because people read from top to bottom. Q. Why should I not top-post? _________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign OP5 AB X NO HTML/RTF in e-mail Tel: +46-(0)733-70 20 99 / \ NO Word docs in e-mail From noreply at sourceforge.net Wed Jun 20 13:15:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 04:15:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&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: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-20 13:15 Message: Logged In: YES user_id=1694341 Originator: NO I commited Holger's proposals a couple of minutes ago. I hope, i didn't break backward compatibility, but I'm quite sure everything should work as expected. The --ssl and --starttls arguments are now valid for check_ldap, too. Not only to check_ldaps. John, it would be great if you could checkout and try the latest cvs version. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 19:02 Message: Logged In: YES user_id=759506 Originator: NO Personally, I'd find "--old-ldaps" a bit confusing, too. I'd suggest: 1) By default, keep the current behaviour for backwards compatibility. 2) Introduce two new flags: - "-T/--starttls", which forces, well, STARTTLS. - "-S/--ssl", which forces "SSL on connect" and sets the default port to 636 (even nicer would be to use getservbyname(3), but IIRC we do that nowhere, so that's a different story). If "--ssl" seems too ambiguous, it could be called "--ssl-on-connect" or so, but I'd prefer "--ssl" as "check_http", "check_tcp" and possibly other plugins use it. If either option is used, the plugin doesn't care about argv[0] nor about the specified port. If neither option is used, you get the current behaviour. 3) Document the default behaviour, and maybe also mark it as deprecated: "If this plugin is called via 'check_ldaps', 'STARTTLS' will be used, unless --port=636 is specified, in which case 'SSL on connect' will be used. This behaviour is deprecated, please use 'check_ldap' with the '--starttls' or '--ssl' flags instead." Just my 2?, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 18:30 Message: Logged In: YES user_id=1694341 Originator: NO For the records: wikipedia claims: >A common alternate method of securing LDAP communication is using an SSL tunnel. This is >denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL >is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never >standardized in any formal specification. This usage has been deprecated along with >LDAPv2, which was officially retired in 2003 so if i got it right, starttls starts a tls connection on port 389, ssl on connect uses ssl wrapped around normal ldap since tls was not included in ldap that time I'd say these steps need to be done? - introduce an argument --old-ldaps to force direct connection to 636 - keep default behaviour if -p 636 is given -> ldaps - set default port to 636 if --old-ldaps is defined - introduce default behaviour (startTLS) in --help what do you think? matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:48 Message: Logged In: YES user_id=1694341 Originator: NO Today i have read about a user expecting ldaps to connect to 636 in a forum. But using the direct connection seems to be deprecated according to http://www.openldap.org/lists/openldap-software/200409/msg00617.html So startTLS should be the right way to make it. I couldn't find out if ldap_start_tls_s() eventually makes a secure connect after the query on the default port. IMO it should do so. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2007-06-19 17:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From bseklecki at collaborativefusion.com Wed Jun 20 15:28:51 2007 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Wed, 20 Jun 2007 09:28:51 -0400 Subject: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4) In-Reply-To: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> References: <1166228115.50417.506.camel@soundwave.pgh.priv.collaborativefusion.com> Message-ID: <1182346131.68077.78.camel@soundwave.pgh.priv.collaborativefusion.com> Just to follow-up: I have written a plugin that uses the somewhat complete PHP Net-SNMP bindings (no getsnmptable() ?!) and the new PF-MIB::CARP Agent Extensions to Net-SNMP snmpd(8). I'll post it on NagiosExchange for review if/when I can deploy a production 4.1-stable system. ~BAS On Fri, 2006-12-15 at 19:15 -0500, Brian A. Seklecki wrote: > Thoughts? Strategies? Ideas? > --- IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From Thomas at zango.com Wed Jun 20 23:20:40 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Wed, 20 Jun 2007 14:20:40 -0700 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <466D1AB3.1060101@op5.se> References: <465453CE.3070609@op5.se><429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> <466D1AB3.1060101@op5.se> Message-ID: <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Andreas Ericsson > Sent: June 11, 2007 5:50 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] [PATCH] negate: Let the user specify what > end result of specific return code > > Ton Voon wrote: > > Hi Andreas, > > > > On 23 May 2007, at 15:46, Andreas Ericsson wrote: > > > >> This patch lets the user specify how to translate the various return > >> codes from the commands the negate plugin runs, rather than just > >> having > >> the hardcoded option to go with. > >> > >> This is specified as such: > >> --critical=warning (to make critical translate to warning) > >> --warning=ok > >> > > > > This looks interesting and I wrote some tests to try this out, but I > > don't appear to be getting the right results. Could have a look at it? > > > > Oh gawds, this went dormant for a long time. Higher prio projects, illness > and vacations came in between. > > I happened to build the patch from the wrong branch. The correct one is > attached. Thanks Andreas... I just found use for that new negate, though it still fail Ton's tests. I noticed that the run_simple function does not handle properly ok state. At line 169: if (WEXITSTATUS(status){ ... } return STATE_UNKNOWN; Did you sent the wrong patch again? After looking at the current code, it looks like there are *many* things that need to be polished as well. Also I have these two suggestions: 1. The default behaviour should only happen if none of -o, -w, -c and -u are present (That's what is in negate.pl too). I.e. in the last example above the correct result would be: 0 0 2 3 2. We should accept numeric values: $ ./negate -w 2 If you're not going to work on this anymore I'll finish up the work whenever I can (Not before 2-3 weeks...). Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From dermoth at aei.ca Thu Jun 21 05:09:02 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 20 Jun 2007 23:09:02 -0400 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> References: <465453CE.3070609@op5.se><429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> <466D1AB3.1060101@op5.se> <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> Message-ID: <4679EBCE.3050506@aei.ca> On 20/06/07 05:20 PM, Thomas Guyot-Sionnest wrote: > > 1. The default behaviour should only happen if none of -o, -w, -c and -u are > present (That's what is in negate.pl too). I.e. in the last example above > the correct result would be: > > 0 0 2 3 Oops, don't search the example; I cut that part.. From noreply at sourceforge.net Thu Jun 21 08:24:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 23:24:34 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1498923 ] nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Message-ID: Bugs item #1498923, was opened at 2006-06-01 17:15 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&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: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergei Haramundanis (volsh) >Assigned to: Matthias Eble (psychotrahe) Summary: nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Initial Comment: I get this build error during compilation of check_ldap on Solaris 9: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:145: warning: too many arguments for format check_ldap.c:161: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:84: warning: unused variable `tls' /bin/bash ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -R/usr/local/ssl/lib -o check_ldap check_ldap.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket -lresolv -lldap -llber ../intl/libintl.a -liconv -lgen -lsocket -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_ldap check_ldap.o netutils.o utils.o -L/usr/local/nagios2/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lldap /opt/sfw/lib/.libs/liblber.so ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lsocket -lssl -lcrypto -R/opt/sfw/lib -R/usr/local/lib -R/usr/local/ssl/lib gcc: /opt/sfw/lib/.libs/liblber.so: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `check_ldap' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== It looks like the liblber.so specification is off as it currently exists in /opt/sfw/lib on the host I am building this on. For some reason ".libs/" is getting in the path for this library. I looked for a possible mishap in the makefiles but could not find any. Please make this a priority as I need to upgrade to nagios-plugins-1.4.3 from netsaint-plugins-1.2.9-4 a.s.a.p. Thanks. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-06-21 08:24 Message: Logged In: YES user_id=1694341 Originator: NO #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif seems to be a good fix on the first view. I'll recheck and try this on our solaris box. ---------------------------------------------------------------------- Comment By: Sergei Haramundanis (volsh) Date: 2006-06-01 17:28 Message: Logged In: YES user_id=1356237 Note, originally, check_ldap failed with the following error: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:120: error: `LDAP_OPT_SUCCESS' undeclared (first use in this function) check_ldap.c:120: error: (Each undeclared identifier is reported only once check_ldap.c:120: error: for each function it appears in.) check_ldap.c:141: warning: too many arguments for format check_ldap.c:157: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:80: warning: unused variable `tls' *** Error code 1 make: Fatal error: Command failed for target `check_ldap.o' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== The workaround for this is to edit ./nagios-plugins-1.4.3/plugins/check_ldap.c and add the following after the includes section at the top of the source file: #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&group_id=29880 From ae at op5.se Thu Jun 21 14:47:05 2007 From: ae at op5.se (Andreas Ericsson) Date: Thu, 21 Jun 2007 14:47:05 +0200 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> References: <465453CE.3070609@op5.se><429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> <466D1AB3.1060101@op5.se> <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> Message-ID: <467A7349.7010209@op5.se> Thomas Guyot-Sionnest wrote: >> -----Original Message----- >> From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- >> devel-bounces at lists.sourceforge.net] On Behalf Of Andreas Ericsson >> Sent: June 11, 2007 5:50 >> To: Nagios Plugin Development Mailing List >> Subject: Re: [Nagiosplug-devel] [PATCH] negate: Let the user specify what >> end result of specific return code >> >> Ton Voon wrote: >>> Hi Andreas, >>> >>> On 23 May 2007, at 15:46, Andreas Ericsson wrote: >>> >>>> This patch lets the user specify how to translate the various return >>>> codes from the commands the negate plugin runs, rather than just >>>> having >>>> the hardcoded option to go with. >>>> >>>> This is specified as such: >>>> --critical=warning (to make critical translate to warning) >>>> --warning=ok >>>> >>> This looks interesting and I wrote some tests to try this out, but I >>> don't appear to be getting the right results. Could have a look at it? >>> >> Oh gawds, this went dormant for a long time. Higher prio projects, illness >> and vacations came in between. >> >> I happened to build the patch from the wrong branch. The correct one is >> attached. > > Thanks Andreas... I just found use for that new negate, though it still fail > Ton's tests. I noticed that the run_simple function does not handle properly > ok state. At line 169: > > if (WEXITSTATUS(status){ > ... > } > > return STATE_UNKNOWN; > > Did you sent the wrong patch again? After looking at the current code, it > looks like there are *many* things that need to be polished as well. > That line is in the old patch, but using the one attached to my second mail (the one you replied to) results in code that has no line reading "if (WEXITSTATUS(status))". Perhaps you applied the old patch again? The current code goes like this: --%<---%<---%<---%<--- /* only use the configured return codes if the program * exited in a normal fashion */ if (WIFEXITED(status)) { result = WEXITSTATUS(status); if (result > 0 && result < sizeof(state) / sizeof(int)) return state[result]; } /* if the program didn't exit normally, we're clueless */ return STATE_UNKNOWN; ---%<---%<---%<---%<--- Since the size of the state-table is sizeof(int) * 4, the code will always return UNKNOWN for return-codes that nagios doesn't understand. > Also I have these two suggestions: > > 1. The default behaviour should only happen if none of -o, -w, -c and -u are > present (That's what is in negate.pl too). I.e. in the last example above > the correct result would be: > > 0 0 2 3 > As the status table is pre-filled with the default values, whatever values are missing will always be translated to their default values. I'm not sure if the defaults I've set in this modified negate program matches the ones in the original program, but that's a minor thing to fix. > 2. We should accept numeric values: > > $ ./negate -w 2 > I have no opinion on this. It might be handy for testing, but I imagine users will most likely want to use the readable arguments. > If you're not going to work on this anymore I'll finish up the work whenever > I can (Not before 2-3 weeks...). > I'll fix what bugs are found that I can reproduce, but I won't add more features. I'll have a look at the test thing as well. -- 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 Thu Jun 21 21:33:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 12:33:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1498923 ] nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Message-ID: Bugs item #1498923, was opened at 2006-06-01 11:15 Message generated for change (Comment added) made by volsh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&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: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergei Haramundanis (volsh) Assigned to: Matthias Eble (psychotrahe) Summary: nagios-plugins-1.4.3 check_ldap build error on Solaris 9 Initial Comment: I get this build error during compilation of check_ldap on Solaris 9: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:145: warning: too many arguments for format check_ldap.c:161: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:84: warning: unused variable `tls' /bin/bash ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -R/usr/local/ssl/lib -o check_ldap check_ldap.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket -lresolv -lldap -llber ../intl/libintl.a -liconv -lgen -lsocket -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_ldap check_ldap.o netutils.o utils.o -L/usr/local/nagios2/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lldap /opt/sfw/lib/.libs/liblber.so ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lsocket -lssl -lcrypto -R/opt/sfw/lib -R/usr/local/lib -R/usr/local/ssl/lib gcc: /opt/sfw/lib/.libs/liblber.so: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `check_ldap' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== It looks like the liblber.so specification is off as it currently exists in /opt/sfw/lib on the host I am building this on. For some reason ".libs/" is getting in the path for this library. I looked for a possible mishap in the makefiles but could not find any. Please make this a priority as I need to upgrade to nagios-plugins-1.4.3 from netsaint-plugins-1.2.9-4 a.s.a.p. Thanks. ---------------------------------------------------------------------- >Comment By: Sergei Haramundanis (volsh) Date: 2007-06-21 15:33 Message: Logged In: YES user_id=1356237 Originator: YES psychotrahe: note that this is still an issue w/nagios-plugins-1.4.9 and the workaround I provided is still the fix for it ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-21 02:24 Message: Logged In: YES user_id=1694341 Originator: NO #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif seems to be a good fix on the first view. I'll recheck and try this on our solaris box. ---------------------------------------------------------------------- Comment By: Sergei Haramundanis (volsh) Date: 2006-06-01 11:28 Message: Logged In: YES user_id=1356237 Note, originally, check_ldap failed with the following error: ============================== if gcc -DLOCALEDIR=\"/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/local/ssl/include -I/usr/local/ssl/include -Wall -g -O2 -MT check_ldap.o -MD -MP -MF ".deps/check_ldap.Tpo" -c -o check_ldap.o check_ldap.c; \ then mv -f ".deps/check_ldap.Tpo" ".deps/check_ldap.Po"; else rm -f ".deps/check_ldap.Tpo"; exit 1; fi check_ldap.c: In function `main': check_ldap.c:120: error: `LDAP_OPT_SUCCESS' undeclared (first use in this function) check_ldap.c:120: error: (Each undeclared identifier is reported only once check_ldap.c:120: error: for each function it appears in.) check_ldap.c:141: warning: too many arguments for format check_ldap.c:157: warning: implicit declaration of function `ldap_start_tls_s' check_ldap.c:80: warning: unused variable `tls' *** Error code 1 make: Fatal error: Command failed for target `check_ldap.o' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3/plugins *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/nagios2/nagios-plugins-1.4.3 *** Error code 1 make: Fatal error: Command failed for target `all' ============================== The workaround for this is to edit ./nagios-plugins-1.4.3/plugins/check_ldap.c and add the following after the includes section at the top of the source file: #ifndef LDAP_OPT_SUCCESS # define LDAP_OPT_SUCCESS LDAP_SUCCESS #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1498923&group_id=29880 From noreply at sourceforge.net Sat Jun 23 15:44:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jun 2007 06:44:00 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1742066 ] nagios-plugins-1.4.8 check_smtp Message-ID: Bugs item #1742066, was opened at 2007-06-23 13:44 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=1742066&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christoph Schell (cschell) Assigned to: Nobody/Anonymous (nobody) Summary: nagios-plugins-1.4.8 check_smtp Initial Comment: buffer overflow in argument handling If I use check_smtp -H 127.0.0.1 -C "HELO Nagios" -R 250 -C "MAIL FROM:" -R 250 -C "RCPT TO:" -R 250 -C "DATA" -R 354 -C "." -R 250 -t 30 I got a buffer overflow in the argument handling. I fixed the problem with the attched patch. Christoph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1742066&group_id=29880 From dermoth at aei.ca Sat Jun 23 18:06:19 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 23 Jun 2007 12:06:19 -0400 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <467A7349.7010209@op5.se> References: <465453CE.3070609@op5.se><429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> <466D1AB3.1060101@op5.se> <804160344192334BB21922E8082EA6C0A15F2B@seaex01.180solutions.com> <467A7349.7010209@op5.se> Message-ID: <467D44FB.5000702@aei.ca> On 21/06/07 08:47 AM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >>> -----Original Message----- >>> From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- >>> devel-bounces at lists.sourceforge.net] On Behalf Of Andreas Ericsson >>> Sent: June 11, 2007 5:50 >>> To: Nagios Plugin Development Mailing List >>> Subject: Re: [Nagiosplug-devel] [PATCH] negate: Let the user specify what >>> end result of specific return code >>> >>> Ton Voon wrote: >>>> Hi Andreas, >>>> >>>> On 23 May 2007, at 15:46, Andreas Ericsson wrote: >>>> >>>>> This patch lets the user specify how to translate the various return >>>>> codes from the commands the negate plugin runs, rather than just >>>>> having >>>>> the hardcoded option to go with. >>>>> >>>>> This is specified as such: >>>>> --critical=warning (to make critical translate to warning) >>>>> --warning=ok >>>>> >>>> This looks interesting and I wrote some tests to try this out, but I >>>> don't appear to be getting the right results. Could have a look at it? >>>> >>> Oh gawds, this went dormant for a long time. Higher prio projects, illness >>> and vacations came in between. >>> >>> I happened to build the patch from the wrong branch. The correct one is >>> attached. >> Thanks Andreas... I just found use for that new negate, though it still fail >> Ton's tests. I noticed that the run_simple function does not handle properly >> ok state. At line 169: >> >> if (WEXITSTATUS(status){ >> ... >> } >> >> return STATE_UNKNOWN; >> >> Did you sent the wrong patch again? After looking at the current code, it >> looks like there are *many* things that need to be polished as well. >> > > That line is in the old patch, but using the one attached to my second mail > (the one you replied to) results in code that has no line reading > "if (WEXITSTATUS(status))". > > Perhaps you applied the old patch again? > > The current code goes like this: > --%<---%<---%<---%<--- > /* only use the configured return codes if the program > * exited in a normal fashion */ > if (WIFEXITED(status)) { > result = WEXITSTATUS(status); > if (result > 0 && result < sizeof(state) / sizeof(int)) > return state[result]; > } > > /* if the program didn't exit normally, we're clueless */ > return STATE_UNKNOWN; > ---%<---%<---%<---%<--- > > Since the size of the state-table is sizeof(int) * 4, the code will > always return UNKNOWN for return-codes that nagios doesn't understand. The problem is the "if (WIFEXITED(status)". If the status code is 0, WIFEXITED(status) returns 0 and the if statement is skipped. You should probably do: result = WEXITSTATUS(status); if (result > 0 && result < sizeof(state) / sizeof(int)) return state[result]; } Though I'd like to know the possible return codes for WEXITSTATUS first. As I said I can work on this patch at a later time if you like. The test script is in cvs, just do: $ ../test.pl.in t/negate.pl or prove t/negate.pl from the plugins directory. Thomas Thomas From noreply at sourceforge.net Tue Jun 26 04:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 19:20:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1252285 ] check_ssh reports critical for some SSH servers Message-ID: Bugs item #1252285, was opened at 2005-08-04 16:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: TexasDavid (daupperle) Assigned to: Matthias Eble (psychotrahe) Summary: check_ssh reports critical for some SSH servers Initial Comment: The check_ssh plugin reports STATE_CRITICAL for certain SSH servers. As a result some valid SSH servers are reported down. For example, the following is a valid response for a working SSH server: sshd2: SSH Secure Shell 2.4.0 (non-commercial version) on hppa2.0n-hp-hpux11.00 The problem lies on line 216 of check_ssh.c (Version 1.27). THe function strncmp should be replaced with strncasecmp. Note: this change will not return the version properly, but it will return the state information. The following changes will properly evaluate the above SSH server in more detail and probably should be applied to the patch. 216c216 < if (strncmp (output, "SSH", 3)) { --- > if (strncasecmp (output, "SSH", 3)) { 224,227c224,237 < ssh_proto = output + 4; < ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); < ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; < --- > if (strncmp(output,"sshd2",5)==0) { > // Output(one line): sshd2: SSH Secure > // Shell 2.4.0 (non-commercial version) > // on hppa2.0n-hp-hpux11.00 > ssh_server = output + 7; > ssh_server[strcspn (ssh_server, "0123456789")-1] = 0; > ssh_proto = ssh_server + strlen (ssh_server)+1; > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } > else { // Standard servers > ssh_proto = output + 4; > ssh_server = ssh_proto + strspn (ssh_proto, "-0123456789. "); > ssh_proto[strspn (ssh_proto, "0123456789. ")] = 0; > } ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 01:15 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-03 10:49 Message: Logged In: YES user_id=1694341 Originator: NO Hi David, I looked at the rfc (http://tools.ietf.org/html/rfc4253#section-4.2) and this claims that there must be a line like SSH-... but there MAY be other lines before that one that specifies the version. could you send the whole text the server offers (eg using netcat 127.0.0.1 22)? The patch you specified is a bit too specific to me. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1252285&group_id=29880 From noreply at sourceforge.net Tue Jun 26 04:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 19:20:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 09:31 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&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: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ton Voon (tonvoon) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 01:19 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2007-02-02 11:46 Message: Logged In: YES user_id=865292 Originator: YES Thanks. However, since I have just changed job I am unable to test. This one is down to bubbafat. Duncs ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-02-02 09:05 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan and bubbafat, Hi Duncan, I think this is fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-11 22:25 Message: Logged In: YES user_id=1495257 Same thing happens on Solaris 7 with gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release). source='check_smtp.c' object='check_smtp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/local/include -I/usr/local/include -Wall -g -O2 -c check_smtp.c check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3' make: *** [all] Error 2 A lame fix is: --- nagios-plugins-1.4.3/plugins/check_smtp.c Wed Nov 2 03:47:26 2005 +++ nagios-plugins-1.4.3m/plugins/check_smtp.c Mon Apr 24 22:52:01 2006 @@ -26,6 +26,7 @@ #include "common.h" #include "netutils.h" #include "utils.h" +#include #ifdef HAVE_SSL int check_cert = FALSE; However, on Solaris 8 with gcc version 3.3.2, this is not needed. netdb.h gets included somehow. Haven't been able to trace it down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From noreply at sourceforge.net Tue Jun 26 04:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 19:20:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1250967 ] broken awk script subst.in Message-ID: Bugs item #1250967, was opened at 2005-08-03 04:53 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: broken awk script subst.in Initial Comment: The script plugins-scripts/subst.in does things in the wrong order resulting in broken pathnames. As an example look at check_rpc.pl. First "use lib utils.pm;" is substituted by the full path name to utils.pm, but then the first name component is stripped off again (at least on OpenBSD where /usr/local/libexec/nagios/utils.pm becomes just nagios/utils.pm) This is on OpenBSD-current with plugins 1.4 and 1.4.1. Diff attached. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 01:13 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 05:07 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I have tried to reproduce this case on freebsd 6.2. But the lines were substituted correctly. use lib PREFIX/libexec use utils (... I tried 1.4.1, 1.4.3 and 1.4.5. Could you please test if this issue perstists with the latest version (1.4.9 or cvs snapshot)? Matthias ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-12-08 11:48 Message: Logged In: YES user_id=1526665 Originator: NO Similar problem on FreeBSD 6.2-RC1 and nagios-plugins-1.4.5 . For example: in nagios-plugins-1.4.3 string in check_mailq.pl "use lib utils.pm;" substituted with full path in installed check_mailq "use lib "/usr/local/libexec/nagios";", but in nagios-plugins-1.4.5 it substituted as "use lib "nagios";" and check_mailq plugin cannot find utils.pm . Patch patch-plugins-scripts_subst_in fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1250967&group_id=29880 From noreply at sourceforge.net Tue Jun 26 04:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 19:20:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1523748 ] check_disk should error if warn range is subset of critical Message-ID: Bugs item #1523748, was opened at 2006-07-17 02:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_disk should error if warn range is subset of critical Initial Comment: the new se->w_idfp and se->c_idfp in version 1.4.3 are not initialized resulting in the following error (on HP-UX 11.23) check_disk -c 5% -w 10% -p /dev/vg00/lvol1 INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (64768802081573470261722606760322190900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /dev/vg00/lvol1 check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [-v] [-q] The following patch corrects this *** check_disk.c Mon Jul 17 11:32:26 2006 --- check_disk.c.good Mon Jul 17 11:32:03 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-06-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-06-11 02:13 Message: Logged In: YES user_id=664364 Originator: NO Matthias, Sorry, I should have put some more details in here. Dick's original query was because check_disk used to give an error if the range values did not "make sense" - ie, "./check_disk 0 200" (200% free?) and "./check_disk -w 10% -c 15%" (warn if less than 10%, but critical if less than 15% means warn will neven happen). The changes I made a few months ago for range values does not do any validation for the input values. There are some TODO tests in check_disk.t for invalid values and invalid percent figures - I think these are what Dick would like fixed. I'm unsure how general these cases are. Should you always flag an UNKNOWN state if the warning range is completely within the critical range? Should you check values for data types such as percentages (of course, it is possible to get something as 200% of a previous value...). Matthias, this is probably a good conversation for the mailing list if you want to drive. Ton ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 01:21 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to vandenburgd. Unfortunately the mail couldn't be delivered. Yet setting to pending. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-10 09:52 Message: Logged In: YES user_id=1694341 Originator: NO what do you mean with "consistency check"? matthias ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-07-17 08:46 Message: Logged In: YES user_id=780242 As the changes in CURRENT deleted every reference to w_idfp and c_idfp the error also disappears. Unfortunately the consistency check also dispappeared. Dick ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-17 03:27 Message: Logged In: YES user_id=664364 Dick, Can you try the snapshot at http://nagiosplug.sourceforge.net/snapshot. There have been fixes to check_disk recently. Please update if there is still a problem. I've marked the call in pending so it will autoclose in 7 days. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 From alessandro.ren at opservices.com.br Tue Jun 26 18:46:21 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Tue, 26 Jun 2007 13:46:21 -0300 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <468131CD.9020305@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> Message-ID: <468142DD.7050806@opservices.com.br> The new version of nsclient that we call opmonagent can be downloaded from http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. We have fixed the connection limit that nsclient had and fix a access violation with some global variables that nsclient used. We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and it's running very stable on these platforms. If someone wants the sourcecode, just drop me a line. Any suggestions or bug reports are welcome. Alessandro Ren www.opservices.com.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.ren at opservices.com.br Wed Jun 27 15:00:04 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Wed, 27 Jun 2007 10:00:04 -0300 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <468142DD.7050806@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> <468142DD.7050806@opservices.com.br> Message-ID: <46825F54.8080507@opservices.com.br> I forgot to mention that we've changed the default TCP port to 5667, as the old 1248 would be in use from time to time on the windows servers. As NRPE default port is 5666 we taught of 5667, but the port can be changed in the register as it can be changed in nsclient, the same way. []s. Alessandro Ren wrote: > > The new version of nsclient that we call opmonagent can be > downloaded from > http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. > We have fixed the connection limit that nsclient had and fix a > access violation with some global variables that nsclient used. > We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and it's > running very stable on these platforms. > If someone wants the sourcecode, just drop me a line. > Any suggestions or bug reports are welcome. > > Alessandro Ren > www.opservices.com.br > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.ren at opservices.com.br Wed Jun 27 23:33:16 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Wed, 27 Jun 2007 18:33:16 -0300 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <46825F54.8080507@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> <468142DD.7050806@opservices.com.br> <46825F54.8080507@opservices.com.br> Message-ID: <4682D79C.4020805@opservices.com.br> We've set up a forum to support opmonagent that can be reached here http://intranet.opservices.com.br/phpBB2/ Thanks. Alessandro Ren wrote: > > I forgot to mention that we've changed the default TCP port to > 5667, as the old 1248 would be in use from time to time on the windows > servers. > As NRPE default port is 5666 we taught of 5667, but the port can > be changed in the register as it can be changed in nsclient, the same way. > > []s. > > > Alessandro Ren wrote: >> >> The new version of nsclient that we call opmonagent can be >> downloaded from >> http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. >> We have fixed the connection limit that nsclient had and fix a >> access violation with some global variables that nsclient used. >> We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and >> it's running very stable on these platforms. >> If someone wants the sourcecode, just drop me a line. >> Any suggestions or bug reports are welcome. >> >> Alessandro Ren >> www.opservices.com.br >> -- __________________________________________________ *Alessandro Ren* /*OpServices*/ /*Luciana de Abreu, 471 - Sala 403*/ /*Porto Alegre, RS - CEP 90570-060*/ *(* phone 55(51)3061-3588 *4* fax 55(51)3061-3588 *Q* mobile 55(48)9987-0625 *:* email alessandro.ren at opservices.com.br __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.ren at opservices.com.br Thu Jun 28 13:37:26 2007 From: alessandro.ren at opservices.com.br (Alessandro Ren) Date: Thu, 28 Jun 2007 08:37:26 -0300 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <4682D79C.4020805@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> <468142DD.7050806@opservices.com.br> <46825F54.8080507@opservices.com.br> <4682D79C.4020805@opservices.com.br> Message-ID: <46839D76.3010708@opservices.com.br> The correct link is https://intranet.opservices.com.br/phpBB2/ Alessandro Ren wrote: > > We've set up a forum to support opmonagent that can be reached > here http://intranet.opservices.com.br/phpBB2/ > > Thanks. > > Alessandro Ren wrote: >> >> I forgot to mention that we've changed the default TCP port to >> 5667, as the old 1248 would be in use from time to time on the >> windows servers. >> As NRPE default port is 5666 we taught of 5667, but the port can >> be changed in the register as it can be changed in nsclient, the same >> way. >> >> []s. >> >> >> Alessandro Ren wrote: >>> >>> The new version of nsclient that we call opmonagent can be >>> downloaded from >>> http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. >>> We have fixed the connection limit that nsclient had and fix a >>> access violation with some global variables that nsclient used. >>> We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and >>> it's running very stable on these platforms. >>> If someone wants the sourcecode, just drop me a line. >>> Any suggestions or bug reports are welcome. >>> >>> Alessandro Ren >>> www.opservices.com.br >>> > > -- > __________________________________________________ > *Alessandro Ren* > /*OpServices*/ > /*Luciana de Abreu, 471 - Sala 403*/ > /*Porto Alegre, RS - CEP 90570-060*/ > > *(* phone 55(51)3061-3588 > *4* fax 55(51)3061-3588 > *Q* mobile 55(48)9987-0625 > *:* email alessandro.ren at opservices.com.br > > > __________________________________________________ -- __________________________________________________ *Alessandro Ren* /*OpServices*/ /*Luciana de Abreu, 471 - Sala 403*/ /*Porto Alegre, RS - CEP 90570-060*/ *(* phone 55(51)3061-3588 *4* fax 55(51)3061-3588 *Q* mobile 55(48)9987-0625 *:* email alessandro.ren at opservices.com.br __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagiosplug-devel at lusis.org Thu Jun 28 19:32:47 2007 From: nagiosplug-devel at lusis.org (John E. Vincent) Date: Thu, 28 Jun 2007 13:32:47 -0400 Subject: [Nagiosplug-devel] Suggestion about SNMP errors Message-ID: <4683F0BF.3030604@lusis.org> I know this isn't going to thread right because I just signed up for the mailing list but: My opinion on the failure of snmp-agents and honestly all plugin failures is that it should return UNKNOWN. This is what the status is for. It's up to the individual implementation of Nagios at each site to determine if UNKNOWN is an alert condition or not. I know several plugins I've seen actually offer an option of how to handle service timeouts and such (which would typically be the result from a failed agent connection). Chiel, was there a specific condition or return that you had in mind? Maybe an incorrect index on a disk query or such? From nagiosplug-devel at lusis.org Thu Jun 28 20:26:09 2007 From: nagiosplug-devel at lusis.org (John Vincent) Date: Thu, 28 Jun 2007 14:26:09 -0400 Subject: [Nagiosplug-devel] rrdlabel change Message-ID: I realized after the fact that Performance.pm was part of nagiosplug not nagiosgraph. I'm actually using Opsview (Great job, Ton) so I wasn't aware initially of where it came from. One of the problems nagiosgraph has is that it appends _warn and _crit to values from perfdata. While Performance.pm does a good job in being aware of the ds name limitation of 19 characters, this still causes problems with truncated values becoming longer than 19 with the append of _warn/_crit. Here's where I posted my change to Performance.pm. I'm going to be moving it into insert.pl as soon as I get my local svn repo setup at home. http://sourceforge.net/forum/message.php?msg_id=4384299 My question to this actually revolves around how tightly coupled nagiosplug and perfdata feels to the graphing community. Obviously this is a limitation of nagiosgraph and not nagiosplug (for instance perfparse doesn't suffer from this problem because it doesn't use rrdtool). What are the thoughts on the hand-off between perfdata and those who use it? From nagiosplug-devel at lusis.org Thu Jun 28 23:44:00 2007 From: nagiosplug-devel at lusis.org (John Vincent) Date: Thu, 28 Jun 2007 17:44:00 -0400 Subject: [Nagiosplug-devel] Opinion on multifunction plugins Message-ID: Does anyone have an opinion on multifunctional plugins? e.g. I have a mysql plugin that I've written that gets different information based on the options passed. -Q gets query_cache hit ratio, -q gets queries per sec, -p gets innodb page cache usage and so on. It's a idea I picked up from the various plugins that Patrick Proy writes. His snmp load and mem scripts take different options for different plugins. Yeah they're hard to read sometimes but it gets the job done and it I happen to like it. Opinions? The reason I asked is that looking at Nagios::Plugin, it appears to be designed with a single check in mind. I don't have any real data to back that up but that was a first glance thought. From hanjuan at gmail.com Thu Jun 28 23:54:17 2007 From: hanjuan at gmail.com (Ellen Yang) Date: Thu, 28 Jun 2007 14:54:17 -0700 Subject: [Nagiosplug-devel] nagios plugin to monitor Oracle Database XE Message-ID: Hello, I'm trying to monitor my Oracle Database XE using Nagios. The limit on that is: 4GB of disk space for user data storage, 5GB for physical storage and 1GB of memory for SGA+PGA . Are there any Nagios plugins can monitor the disk space usage and memory usage for XE? Thanks a lot, Ellen From Thomas at zango.com Thu Jun 28 23:56:42 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 28 Jun 2007 14:56:42 -0700 Subject: [Nagiosplug-devel] Suggestion about SNMP errors In-Reply-To: <085001c7a753$2fa3da20$570010ac@michiel> References: <085001c7a753$2fa3da20$570010ac@michiel> Message-ID: <804160344192334BB21922E8082EA6C0A708E2@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of chiel > Sent: June 5, 2007 5:24 > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Suggestion about SNMP errors > > Hello, > > I got a couple of scripts that use snmp for service cheking. > The thing is that all these script will send a diferent error code if > there is a problem with the communtication with the snmp-agent. So scripts > will trigger a critical, warning or unknown message. > Woudn't it be better if all script use the same error code? This would be > much better for sending and processing notifications. > I think the best option is "unknown" with these kind of errors. > > like to know your thoughts on this Are you talking about check_snmp? AFAIK it returns UNKNOWN if it can't talk with the SNMP daemon. Also I recently (1.4.9) made it not complain when snmpget writes something on STDERR (That often happens when using broken MIBs). check_snmp used to return a warning (if not critical) in these cases. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From nagiosplug-devel at lusis.org Fri Jun 29 00:36:27 2007 From: nagiosplug-devel at lusis.org (John Vincent) Date: Thu, 28 Jun 2007 18:36:27 -0400 Subject: [Nagiosplug-devel] nagios plugin to monitor Oracle Database XE Message-ID: Ellen Yang writes: > > Hello, > > I'm trying to monitor my Oracle Database XE using Nagios. The limit on > that is: 4GB of disk space for user data storage, 5GB for physical > storage and 1GB of memory for SGA+PGA . Are there any Nagios plugins > can monitor the disk space usage and memory usage for XE? > > Thanks a lot, > Ellen Ellen, I'm not aware of a plugin off the bat but I might provide some tips for writing one yourself. It's been a long time since I've even sat down in front of an oracle database but I know that DB2 provides information on actually tablespace usage depending on the tablespace type. Take a look at this: http://dev.lusis.org/nagios/usable/monitoring_db2_with_nagios.html It is DB2 specific but Oracle must provide some similar type of query information of that nature. Indeed a quick google search came up with this: http://www.dba-oracle.com/t_tablespace_script.htm I'm sure more digging would find a compliment for the SGA+PGA. I'm not sure of your role within the organization where the database is going but SAGE put out an excellent book last year by Ben Rockwood: http://www.sage.org/pubs/13_oracle/ It really gets into Oracle from the SA side of the house. If I had my copy at hand I might be able to find the memory pool information. From ae at op5.se Fri Jun 29 10:44:39 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 29 Jun 2007 10:44:39 +0200 Subject: [Nagiosplug-devel] Suggestion about SNMP errors In-Reply-To: <4683F0BF.3030604@lusis.org> References: <4683F0BF.3030604@lusis.org> Message-ID: <4684C677.9070302@op5.se> John E. Vincent wrote: > I know this isn't going to thread right because I just signed up for the > mailing list but: > > My opinion on the failure of snmp-agents and honestly all plugin > failures is that it should return UNKNOWN. It doesn't work so well when you're testing a network based service (HTTP, SMTP, POP3) and the reason you can't test the timeout value is that you get Connection Refused. For agent/server solutions this might be proper however. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nagiosplug-devel at lusis.org Fri Jun 29 12:55:55 2007 From: nagiosplug-devel at lusis.org (John Vincent) Date: Fri, 29 Jun 2007 06:55:55 -0400 Subject: [Nagiosplug-devel] Suggestion about SNMP errors In-Reply-To: <4684C677.9070302@op5.se> References: <4683F0BF.3030604@lusis.org> <4684C677.9070302@op5.se> Message-ID: On 6/29/07, Andreas Ericsson wrote: > John E. Vincent wrote: > > I know this isn't going to thread right because I just signed up for the > > mailing list but: > > > > My opinion on the failure of snmp-agents and honestly all plugin > > failures is that it should return UNKNOWN. > > It doesn't work so well when you're testing a network based service (HTTP, > SMTP, POP3) and the reason you can't test the timeout value is that you > get Connection Refused. > > For agent/server solutions this might be proper however. I would wager that a connection refused or a connection timeout is a critical scenario for a network service plugin. Maybe what I should have said is that plugin failures of a nature that get back invalid data or were called improperly should return UNKNOWN. By invalid data, I refer to the previous "No such index" snmp type errors. By called improperly, I mean the type of errors you might get when trying to set up a new plugin and forget to add all the options ;) From ae at op5.se Fri Jun 29 13:46:36 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 29 Jun 2007 13:46:36 +0200 Subject: [Nagiosplug-devel] Suggestion about SNMP errors In-Reply-To: References: <4683F0BF.3030604@lusis.org> <4684C677.9070302@op5.se> Message-ID: <4684F11C.8020502@op5.se> John Vincent wrote: > On 6/29/07, Andreas Ericsson wrote: >> John E. Vincent wrote: >> > I know this isn't going to thread right because I just signed up for >> the >> > mailing list but: >> > >> > My opinion on the failure of snmp-agents and honestly all plugin >> > failures is that it should return UNKNOWN. >> >> It doesn't work so well when you're testing a network based service >> (HTTP, >> SMTP, POP3) and the reason you can't test the timeout value is that you >> get Connection Refused. >> >> For agent/server solutions this might be proper however. > > I would wager that a connection refused or a connection timeout is a > critical scenario for a network service plugin. Maybe what I should > have said is that plugin failures of a nature that get back invalid > data or were called improperly should return UNKNOWN. By invalid data, > I refer to the previous "No such index" snmp type errors. By called > improperly, I mean the type of errors you might get when trying to set > up a new plugin and forget to add all the options ;) "No such index" might mean that a particular device was offline or malfunctioning when the server hosting them was brought up though, as some of that stuff is added ad-hoc at boot-time. In short, it varies from case to case. In general, I agree with you but no case is provably correct. -- 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 Jun 29 17:20:03 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 29 Jun 2007 08:20:03 -0700 Subject: [Nagiosplug-devel] Opinion on multifunction plugins In-Reply-To: References: Message-ID: <804160344192334BB21922E8082EA6C0A70979@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of John Vincent > Sent: June 28, 2007 17:44 > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Opinion on multifunction plugins > > Does anyone have an opinion on multifunctional plugins? > > e.g. I have a mysql plugin that I've written that gets different > information based on the options passed. -Q gets query_cache hit > ratio, -q gets queries per sec, -p gets innodb page cache usage and so > on. > > It's a idea I picked up from the various plugins that Patrick Proy > writes. His snmp load and mem scripts take different options for > different plugins. Yeah they're hard to read sometimes but it gets the > job done and it I happen to like it. check_tcp is a good example of multifunction plugin. The command-line allows checking many things trough send and expecting strings, with or without ssl, and it also has "presets" that are loaded when called as a different name (usually trough a symlink). I'm not against it as long as it stays within the plugin's scope. It wouldn't make sense for example to hack check_tcp to do complex handshake for protocol X; that belongs to a different plugin. But once you've written a plugin that talks protocol X then it could possibly make sense to make it able to check different things trough it. > Opinions? The reason I asked is that looking at Nagios::Plugin, it > appears to be designed with a single check in mind. I don't have any > real data to back that up but that was a first glance thought. N::P is just a set of tools to make Perl-based Nagios plugin development brainless. It will eventually supersede the utils.pm currently used in Nagios-plugins. You can do whatever you want with it (i.e. avoid it for some tasks and do the work yourself if it doesn't suit your needs) and so far I haven't noticed any such limitation. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From krishiin at gmail.com Sun Jun 24 23:13:22 2007 From: krishiin at gmail.com (bala krishnan) Date: Mon, 25 Jun 2007 02:43:22 +0530 Subject: [Nagiosplug-devel] NRPE procs Message-ID: <6832ff680706241413n546fa7abt795da9a0972e036a@mail.gmail.com> Hi, We have installed Nagios on one server with latest plugin and installed NRPE in client side with all plugins.everything is fine like load,user,disk except porcs.its show " CHECK_NRPE: Socket timeout after 10 seconds".I increased timeout into 60 sec but no use.could you please help me on this Regards Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: From palleje at gmail.com Tue Jun 26 19:32:08 2007 From: palleje at gmail.com (Palle Jensen) Date: Tue, 26 Jun 2007 13:32:08 -0400 Subject: [Nagiosplug-devel] [Nagios-devel] nsclient new features. In-Reply-To: <468142DD.7050806@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> <468142DD.7050806@opservices.com.br> Message-ID: <009901c7b817$ee199100$bdac38a6@na.dsmain.com> This sounds interesting, however I don't know Spanish/portugis language, and the website doesn't tell me anything. Is the website in English as well? Also it seems to be a big difference from NSClient++, at least size wise. There is no documentation for the new Client? - Palle _____ From: nagios-devel-bounces at lists.sourceforge.net [mailto:nagios-devel-bounces at lists.sourceforge.net] On Behalf Of Alessandro Ren Sent: Tuesday, June 26, 2007 12:46 PM To: Nagios Plugin Development Mailing List Cc: Nagios Developers List Subject: Re: [Nagios-devel] [Nagiosplug-devel] nsclient new features. The new version of nsclient that we call opmonagent can be downloaded from http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. We have fixed the connection limit that nsclient had and fix a access violation with some global variables that nsclient used. We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and it's running very stable on these platforms. If someone wants the sourcecode, just drop me a line. Any suggestions or bug reports are welcome. Alessandro Ren www.opservices.com.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From palleje at gmail.com Thu Jun 28 21:59:20 2007 From: palleje at gmail.com (Palle Jensen) Date: Thu, 28 Jun 2007 15:59:20 -0400 Subject: [Nagiosplug-devel] nsclient new features. In-Reply-To: <46839D76.3010708@opservices.com.br> References: <46783D8E.5080804@opservices.com.br> <468131CD.9020305@opservices.com.br> <468142DD.7050806@opservices.com.br> <46825F54.8080507@opservices.com.br> <4682D79C.4020805@opservices.com.br> <46839D76.3010708@opservices.com.br> Message-ID: <000001c7b9be$d380d8f0$bdac38a6@na.dsmain.com> Alessandro, I don't see any documentation nor instructions for the new Agent? Thanks, Palle _____ From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of Alessandro Ren Sent: Thursday, June 28, 2007 7:37 AM To: Nagios Plugin Development Mailing List Cc: Nagios Developers List Subject: Re: [Nagiosplug-devel] nsclient new features. The correct link is https://intranet.opservices.com.br/phpBB2/ Alessandro Ren wrote: We've set up a forum to support opmonagent that can be reached here http://intranet.opservices.com.br/phpBB2/ Thanks. Alessandro Ren wrote: I forgot to mention that we've changed the default TCP port to 5667, as the old 1248 would be in use from time to time on the windows servers. As NRPE default port is 5666 we taught of 5667, but the port can be changed in the register as it can be changed in nsclient, the same way. []s. Alessandro Ren wrote: The new version of nsclient that we call opmonagent can be downloaded from http://www.opservices.com.br/downloads/opmonagent-2.2.0.0.zip. We have fixed the connection limit that nsclient had and fix a access violation with some global variables that nsclient used. We've tested it on Windows 2k, XP, 2k3 32bits and 64 bits and it's running very stable on these platforms. If someone wants the sourcecode, just drop me a line. Any suggestions or bug reports are welcome. Alessandro Ren www.opservices.com.br -- __________________________________________________ Alessandro Ren OpServices Luciana de Abreu, 471 - Sala 403 Porto Alegre, RS - CEP 90570-060 * phone 55(51)3061-3588 * fax 55(51)3061-3588 * mobile 55(48)9987-0625 * email alessandro.ren at opservices.com.br __________________________________________________ -- __________________________________________________ Alessandro Ren OpServices Luciana de Abreu, 471 - Sala 403 Porto Alegre, RS - CEP 90570-060 * phone 55(51)3061-3588 * fax 55(51)3061-3588 * mobile 55(48)9987-0625 * email alessandro.ren at opservices.com.br __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lusis.org at gmail.com Fri Jun 29 00:23:44 2007 From: lusis.org at gmail.com (John Vincent) Date: Thu, 28 Jun 2007 18:23:44 -0400 Subject: [Nagiosplug-devel] nagios plugin to monitor Oracle Database XE Message-ID: Ellen Yang writes: > > Hello, > > I'm trying to monitor my Oracle Database XE using Nagios. The limit on > that is: 4GB of disk space for user data storage, 5GB for physical > storage and 1GB of memory for SGA+PGA . Are there any Nagios plugins > can monitor the disk space usage and memory usage for XE? > > Thanks a lot, > Ellen > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at ... > 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 > > Ellen, I'm not aware of a plugin off the bat but I might provide some tips for writing one yourself. It's been a long time since I've even sat down in front of an oracle database but I know that DB2 provides information on actually tablespace usage depending on the tablespace type. Take a look at this: http://dev.lusis.org/nagios/usable/monitoring_db2_with_nagios.html It is DB2 specific but Oracle must provide some similar type of query information of that nature. Indeed a quick google search came up with this: http://www.dba-oracle.com/t_tablespace_script.htm I'm sure more digging would find a compliment for the SGA+PGA. I'm not sure of your role within the organization where the database is going but SAGE put out an excellent book last year by Ben Rockwood: http://www.sage.org/pubs/13_oracle/ It really gets into Oracle from the SA side of the house. If I had my copy at hand I might be able to find the memory pool information.