From noreply at sourceforge.net Tue Nov 4 05:50:41 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Nov 2008 04:50:41 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985263 ] check_ups doesn't disconnect cleanly Message-ID: Bugs item #1985263, was opened at 2008-06-05 05:29 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985263&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: Jan Wagner (cyco_dd) >Assigned to: Thomas Guyot (dermoth) Summary: check_ups doesn't disconnect cleanly Initial Comment: The following Bugreport we got against our debian package: everytime check_ups connects to my upsd, the following line is left in my syslog: Sep 11 17:39:09 holly upsd[15381]: Host 127.0.0.1 disconnected (read failure) What happens is that check_ups drops the connection to upsd as soon as it has queried for a variable. upsd expects 'LOGOUT' before terminating the connection, and happily writes "Client on 127.0.0.1 logged out" to syslog if it sees it. This is slightly annoying in conjunction with tools like logcheck: While I'm quite happy to ignore the "logged out" line in a upsd-specific rule, the word "failure" triggers a global logcheck rule and notifies me hour for hour. The attached patch should do away with this problem; check_ups works now fine in my installation. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387001 Thanks and kind regards, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-03 23:50 Message: this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- Comment By: Nick Loeve (trickie) Date: 2008-10-23 09:17 Message: Well as I cannot work out how to attach the updated diff, please see http://bugs.gentoo.org/show_bug.cgi?id=243384 for a copy ---------------------------------------------------------------------- Comment By: Nick Loeve (trickie) Date: 2008-10-23 08:59 Message: This patch doesn't apply currently... I have updated it, but I cannot work out how to attach it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985263&group_id=29880 From dermoth at aei.ca Tue Nov 4 07:17:28 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 04 Nov 2008 01:17:28 -0500 Subject: [Nagiosplug-devel] check_icmp min and max In-Reply-To: <49098956.5090800@op5.se> References: <200810281446.m9SEkhgW011556@ginseng.hep.wisc.edu> <4907566A.5010401@op5.se> <200810281855.m9SItdf1032723@ginseng.hep.wisc.edu> <490761D7.7010303@op5.se> <49083A9B.2080800@aei.ca> <49085009.4070107@op5.se> <49085928.20503@aei.ca> <49098956.5090800@op5.se> Message-ID: <490FE8F8.9030909@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/10/08 06:15 AM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 29/10/08 07:59 AM, Andreas Ericsson wrote: >>> Thomas Guyot-Sionnest wrote: >>> DBL_MAX isn't always defined. Think broken header files here. >>> otoh, defining DBL_MAX to something suitably huge if it isn't >>> defined would get the best of both worlds. >>> >> >> That's what I first though, but gnulib defines LDBL_MAX on some systems >> where it's missing, but not DBL_MAX, so my guess was that's it's always >> there. Anyways it never hurts to check for that though. >> >> So what about something like that: >> >> @@ -106,6 +106,7 @@ >> # define ICMP_UNREACH_PRECEDENCE_CUTOFF 15 >> #endif >> >> +#ifdef DBL_MAX >> +# define RTMIN_MAGIC_CONSTANT DBL_MAX >> +#else >> +# define RTMIN_MAGIC_CONSTANT 9.999999999999999e999 >> +#endif >> >> typedef unsigned short range_t; /* type for get_range() -- >> unimplemented */ >> >> @@ -120,6 +121,8 @@ >> >> >> Shall I commit his patch for you?? >> > > Sure. An even better one would probably be > #ifndef DBL_MAX > # define DBL_MAX 9.9999999999e999 > #endif > > and then just using DBL_MAX instead of RTMIN_MAGIC_CONSTANT, but I > have no strong preference either way. > Hi Andreas, You can see my updated patch here (The perdata format was broken BTW): http://solaris.beaubien.net/cgi-bin/gitweb.cgi/nagiosplug-dermoth.git I didn't apply it yet as I still have one issue to work out... Then the host is unresponsive rtamax is 0 and rtamin is 'inf' (I guess the latter depends on the compiler/libc too): > CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; rtmax=0.000ms;;;; rtmin=infms;;;; I could easily force rtamin to print 0 if it's == to DBL_MAX, however does is make sense to print them at all?? i.e. Solution 1: > CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; rtmax=0.000ms;;;; rtmin=0.000ms;;;; Solution 2: > CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; - From a RRD graphing standpoint, it's better to have no value when data is unknown, however considering that we already print "rta=0.000" it would probably look better to do the same with rtamax and rtamin. What do you think? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJD+j46dZ+Kt5BchYRAkRwAJ9/kd5TNjh5tkfQUfA/3SiSvZNTiwCeMVew AAfV5US5ahtIPsLIhRvJpwc= =zI8R -----END PGP SIGNATURE----- From rich at richhorner.com Tue Nov 4 17:04:00 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Tue, 4 Nov 2008 11:04:00 -0500 Subject: [Nagiosplug-devel] check_icmp min and max In-Reply-To: <490FE8F8.9030909@aei.ca> References: <200810281446.m9SEkhgW011556@ginseng.hep.wisc.edu> <4907566A.5010401@op5.se> <200810281855.m9SItdf1032723@ginseng.hep.wisc.edu> <490761D7.7010303@op5.se> <49083A9B.2080800@aei.ca> <49085009.4070107@op5.se> <49085928.20503@aei.ca> <49098956.5090800@op5.se> <490FE8F8.9030909@aei.ca> Message-ID: <7a65a83a0811040804v1bc953baif63919274647caa3@mail.gmail.com> > Solution 2: > >> CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; > > - From a RRD graphing standpoint, it's better to have no value when data > is unknown, however considering that we already print "rta=0.000" it > would probably look better to do the same with rtamax and rtamin. What > do you think? Sorry if this is a dumb question as I'm not using this plugin in any deployments but why is rta=0.000 getting printed at all in this case? I like Solution 2 here where you omit the min and max values but it seems as though it would make more sense to omit the rta value in this case as well. Am I missing something? Thanks, Rich(ard) -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso http://richhorner.com From Csimm at pubpress.com Tue Nov 4 17:05:07 2008 From: Csimm at pubpress.com (Chase Simms) Date: Tue, 04 Nov 2008 11:05:07 -0500 Subject: [Nagiosplug-devel] standard in must be a tty Message-ID: <49102C63.A859.003B.0@pubpress.com> I am working on a plugin to monitor a process. http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2780.html;d=1 It works fine when run locally through the shell. But when run through the NRPE sandbox it gets the "standard in must be a tty" error. Where can I find more information on the NRPE sandbox and how to work with/around it? I tried rewriting it as a shell script and it came back with the same result. The broken part is where I try to catch the output of - `/sbin/service dalimServer status` When I run it through NRPE it comes back with nothing. Thank you, Chase The information in this email is intended for the sole use of the addressees and may be confidential and subject to protection under the law. If you are not the intended recipient, you are hereby notified that any distribution or copying of this email is strictly prohibited. If you have received this message in error, please reply and delete your copy. From rich at richhorner.com Tue Nov 4 17:11:42 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Tue, 4 Nov 2008 11:11:42 -0500 Subject: [Nagiosplug-devel] standard in must be a tty In-Reply-To: <49102C63.A859.003B.0@pubpress.com> References: <49102C63.A859.003B.0@pubpress.com> Message-ID: <7a65a83a0811040811r5cf5b1c8q1c71e28d188ec362@mail.gmail.com> Chase, I think the dalimServer init script is throwing this and not NRPE. Can you please post the /etc/init.d/dalimServer file? Thanks, Rich(ard) On Tue, Nov 4, 2008 at 11:05 AM, Chase Simms wrote: > I am working on a plugin to monitor a process. > > http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2780.html;d=1 > > It works fine when run locally through the shell. But when run through > the NRPE sandbox it gets the "standard in must be a tty" error. Where > can I find more information on the NRPE sandbox and how to work > with/around it? > > I tried rewriting it as a shell script and it came back with the same > result. > > The broken part is where I try to catch the output of - `/sbin/service > dalimServer status` > > When I run it through NRPE it comes back with nothing. > > Thank you, > Chase > > The information in this email is intended for the sole use of the > addressees and may be confidential and subject to protection under the > law. If you are not the intended recipient, you are hereby notified that > any distribution or copying of this email is strictly prohibited. If you > have received this message in error, please reply and delete your copy. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso http://richhorner.com From ae at op5.se Tue Nov 4 21:41:01 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 04 Nov 2008 21:41:01 +0100 Subject: [Nagiosplug-devel] check_icmp min and max In-Reply-To: <7a65a83a0811040804v1bc953baif63919274647caa3@mail.gmail.com> References: <200810281446.m9SEkhgW011556@ginseng.hep.wisc.edu> <4907566A.5010401@op5.se> <200810281855.m9SItdf1032723@ginseng.hep.wisc.edu> <490761D7.7010303@op5.se> <49083A9B.2080800@aei.ca> <49085009.4070107@op5.se> <49085928.20503@aei.ca> <49098956.5090800@op5.se> <490FE8F8.9030909@aei.ca> <7a65a83a0811040804v1bc953baif63919274647caa3@mail.gmail.com> Message-ID: <4910B35D.4030902@op5.se> Richard Edward Horner wrote: >> Solution 2: >> >>> CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; >> - From a RRD graphing standpoint, it's better to have no value when data >> is unknown, however considering that we already print "rta=0.000" it >> would probably look better to do the same with rtamax and rtamin. What >> do you think? > > Sorry if this is a dumb question as I'm not using this plugin in any > deployments but why is rta=0.000 getting printed at all in this case? > I like Solution 2 here where you omit the min and max values but it > seems as though it would make more sense to omit the rta value in this > case as well. Am I missing something? > Search the mailing archives (from around 2004 or 2005, I think), when check_icmp was originally added. git log -S'rta=0.000' in a clone of the nagiosplug git repo might show you when it was added, and possibly why. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From mox87 at mail.ru Wed Nov 5 12:48:12 2008 From: mox87 at mail.ru (=?koi8-r?Q?=F0=C1=D7=C5=CC_=F4=C9=CD=CF=C6=C5=C5=D7?=) Date: Wed, 05 Nov 2008 14:48:12 +0300 Subject: [Nagiosplug-devel] =?koi8-r?b?RXJyb3IgaW4gY2hlY2tfcGluZw==?= Message-ID: Good day to you! I find error in you check_ping plugin. Not even error, it`s rather defict. This defict displays when host is down. My system - FreeBSD 6.3, nagios plugins 1.4.13 When I use check_ping plugin for ping host from server in same subnet, sometimes I have message "System call sent warnings to stderr" # /usr/local/nagios/libexec/check_ping -H 192.168.8.124 -w 12,5% -c 17,9% -t 30 PING CRITICAL - System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr Packet loss = 100%|rta=17.000000ms;12.000000;17.000000;0.000000 pl=100%;5;9;0 (and in web-interface i see this message too) But if I ping host in another subnet, I haven`t this message # /usr/local/nagios/libexec/check_ping -H 192.168.2.244 -w 15,4% -c 19,10% -t 30 PING CRITICAL - Packet loss = 100% If you use standart ping util to pinging this hosts you get this: Same subnet: # ping 192.168.8.124 PING 192.168.8.124 (192.168.8.124): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ^C --- 192.168.8.124 ping statistics --- 15 packets transmitted, 0 packets received, 100% packet loss Another subnet: # ping 192.168.2.244 PING 192.168.2.244 (192.168.2.244): 56 data bytes ^C --- 192.168.2.244 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss In this case you haven`t "ping: sendto: Host is down" messages in stderr. I saw your check_ping source. In you source not provide for this situation. It`s right? My english is very bad, and I want to ask you: are you understand me? =) or i need to go to english school =) ? Best Regards System Administrator Timofeev Pavel Russia ? ????????? ????????? ????????????? ???????? ????? From Csimm at pubpress.com Wed Nov 5 15:31:57 2008 From: Csimm at pubpress.com (Chase Simms) Date: Wed, 05 Nov 2008 09:31:57 -0500 Subject: [Nagiosplug-devel] standard in must be a tty Message-ID: <4911680D.A859.003B.0@pubpress.com> I'll send the init script directly to you. I don't want Dalim getting upset about me posting their code even though the init script is nothing special. On Tue, 4 Nov 2008 11:11 Richard Edward Horner wrote: Chase, I think the dalimServer init script is throwing this and not NRPE. Can you please post the /etc/init.d/dalimServer file? Thanks, Rich(ard) On Tue, Nov 4, 2008 at 11:05 AM, Chase Simms wrote: > I am working on a plugin to monitor a process. > > http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2780.html;d=1 > > It works fine when run locally through the shell. But when run through > the NRPE sandbox it gets the "standard in must be a tty" error. Where > can I find more information on the NRPE sandbox and how to work > with/around it? > > I tried rewriting it as a shell script and it came back with the same > result. > > The broken part is where I try to catch the output of - `/sbin/service > dalimServer status` > > When I run it through NRPE it comes back with nothing. > > Thank you, > Chase The information in this email is intended for the sole use of the addressees and may be confidential and subject to protection under the law. If you are not the intended recipient, you are hereby notified that any distribution or copying of this email is strictly prohibited. If you have received this message in error, please reply and delete your copy. From engelenh at gmail.com Wed Nov 5 17:24:05 2008 From: engelenh at gmail.com (Hans Engelen) Date: Wed, 5 Nov 2008 17:24:05 +0100 Subject: [Nagiosplug-devel] standard in must be a tty In-Reply-To: <49102C63.A859.003B.0@pubpress.com> References: <49102C63.A859.003B.0@pubpress.com> Message-ID: <5383c62b0811050824g68aa3e16w45076e8344291021@mail.gmail.com> Aside from the error what does the init script do to check the status. Most scripts just lookup a pid in a pid file and check to see if said pid is still running. Rather then forking the script it might be easier to redo that check in the plugin itself. On that note it might even be easier to just check if the process is running rather then fork to a script. Note that I don't know what a dalimserver is so might not apply. Cheers, Hans On Tue, Nov 4, 2008 at 5:05 PM, Chase Simms wrote: > I am working on a plugin to monitor a process. > > http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2780.html;d=1 > > It works fine when run locally through the shell. But when run through > the NRPE sandbox it gets the "standard in must be a tty" error. Where > can I find more information on the NRPE sandbox and how to work > with/around it? > > I tried rewriting it as a shell script and it came back with the same > result. > > The broken part is where I try to catch the output of - `/sbin/service > dalimServer status` > > When I run it through NRPE it comes back with nothing. > > Thank you, > Chase > > The information in this email is intended for the sole use of the > addressees and may be confidential and subject to protection under the > law. If you are not the intended recipient, you are hereby notified that > any distribution or copying of this email is strictly prohibited. If you > have received this message in error, please reply and delete your copy. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From dermoth at aei.ca Wed Nov 5 20:06:44 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 05 Nov 2008 14:06:44 -0500 Subject: [Nagiosplug-devel] Error in check_ping In-Reply-To: References: Message-ID: <4911EEC4.9040801@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ????? ???????? wrote: > Good day to you! > I find error in you check_ping plugin. Not even error, it`s rather defict. This defict displays when host is down. > My system - FreeBSD 6.3, nagios plugins 1.4.13 > > > When I use check_ping plugin for ping host from server in same subnet, sometimes I have message "System call sent warnings to stderr" > > # /usr/local/nagios/libexec/check_ping -H 192.168.8.124 -w 12,5% -c 17,9% -t 30 > PING CRITICAL - System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr System call sent warnings to stderr Packet loss = 100%|rta=17.000000ms;12.000000;17.000000;0.000000 pl=100%;5;9;0 > (and in web-interface i see this message too) > > But if I ping host in another subnet, I haven`t this message > > # /usr/local/nagios/libexec/check_ping -H 192.168.2.244 -w 15,4% -c 19,10% -t 30 > PING CRITICAL - Packet loss = 100% > > > > > If you use standart ping util to pinging this hosts you get this: > > Same subnet: > # ping 192.168.8.124 > PING 192.168.8.124 (192.168.8.124): 56 data bytes > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > ^C > --- 192.168.8.124 ping statistics --- > 15 packets transmitted, 0 packets received, 100% packet loss > > Another subnet: > # ping 192.168.2.244 > PING 192.168.2.244 (192.168.2.244): 56 data bytes > ^C > --- 192.168.2.244 ping statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > In this case you haven`t "ping: sendto: Host is down" messages in stderr. > > > I saw your check_ping source. In you source not provide for this situation. > > It`s right? check_ping tries to work with most common ping versions. If you have unusual system or custom ping application installed, it is possible that check_ping is unable to find the proper arguments or properly interpret its output. The best solution IMHO is using check_icmp instead. check_icmp has a native ICMP implementation and therefore needs to be run with root privileges, so be sure you have the setuid bit set for it (common permissions for this binary is 4555 (-r-sr-xr-x) and owned by root). - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEe7E6dZ+Kt5BchYRArO+AKCkNvJE0EtwgDSkmeGxrxW+ss8V6wCfVs8l R+4lBnaQH9spWCj8CBKAKJI= =mYMA -----END PGP SIGNATURE----- From dermoth at aei.ca Thu Nov 6 05:58:58 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 05 Nov 2008 23:58:58 -0500 Subject: [Nagiosplug-devel] check_icmp min and max In-Reply-To: <4910B35D.4030902@op5.se> References: <200810281446.m9SEkhgW011556@ginseng.hep.wisc.edu> <4907566A.5010401@op5.se> <200810281855.m9SItdf1032723@ginseng.hep.wisc.edu> <490761D7.7010303@op5.se> <49083A9B.2080800@aei.ca> <49085009.4070107@op5.se> <49085928.20503@aei.ca> <49098956.5090800@op5.se> <490FE8F8.9030909@aei.ca> <7a65a83a0811040804v1bc953baif63919274647caa3@mail.gmail.com> <4910B35D.4030902@op5.se> Message-ID: <49127992.9060502@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/08 03:41 PM, Andreas Ericsson wrote: > Richard Edward Horner wrote: >>> Solution 2: >>> >>>> CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; >>> - From a RRD graphing standpoint, it's better to have no value when data >>> is unknown, however considering that we already print "rta=0.000" it >>> would probably look better to do the same with rtamax and rtamin. What >>> do you think? >> Sorry if this is a dumb question as I'm not using this plugin in any >> deployments but why is rta=0.000 getting printed at all in this case? >> I like Solution 2 here where you omit the min and max values but it >> seems as though it would make more sense to omit the rta value in this >> case as well. Am I missing something? >> > > Search the mailing archives (from around 2004 or 2005, I think), when > check_icmp was originally added. > > git log -S'rta=0.000' > > in a clone of the nagiosplug git repo might show you when it was added, > and possibly why. > Couldn't find anything... I updated my commit with the fix for rtamin, so both now prints 0.000 (not sure it casts are needed, but I put them everywhere anyway): http://solaris.beaubien.net/cgi-bin/gitweb.cgi/nagiosplug-dermoth.git The end result: > $ sudo plugins-root/check_icmp -H 192.168.1.111 > CRITICAL - 192.168.1.111: Host unreachable @ 192.168.1.116. rta nan, lost 100%|rta=0.000ms;200.000;500.000;0; pl=100%;40;80;; rtmax=0.000ms;;;; rtmin=0.000ms;;;; > $ sudo plugins-root/check_icmp -H 192.168.1.1 > OK - 192.168.1.1: rta 0.940ms, lost 0%|rta=0.940ms;200.000;500.000;0; pl=0%;40;80;; rtmax=1.408ms;;;; rtmin=0.805ms;;;; If no one complains loudly I'll commit it tomorrow to SVN - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEnmS6dZ+Kt5BchYRAhL5AKCfFlkacuBIwwkgT3sMy3agLzwQGACfb3Wr R2Xn27QXN8nOOj/LJjO5tlE= =PmGU -----END PGP SIGNATURE----- From ewelch at nvidia.com Thu Nov 6 23:07:26 2008 From: ewelch at nvidia.com (Erik Welch) Date: Thu, 6 Nov 2008 14:07:26 -0800 Subject: [Nagiosplug-devel] Bug and fix for the check_disk plugin Message-ID: <18A1316EEEE31E46AC536571A107579B12C0246FE9@HQMAIL01.nvidia.com> Bug in plugins/check_disk.c from nagios-plugins-1.4.12 (and prior) * $Id: check_disk.c 1991 2008-05-07 10:02:42Z dermoth $ The program collects the mounted filesystem data before it processes the command line arguments. This is a problem for multiple reasons: * Why spend cycles on the filesystem if there is an error or --help in the arguments? * The argument processing stats the -p options to mount them in an autofs environment, but they won't have been mounted yet... Detailed output showing the autofs problem: $ sudo umount /home/userdir $ plugins/check_disk -w 5% -c 1% -vvvvv -e -p /home/userdir calling stat on /home/userdir Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 calling stat on /home/userdir DISK UNKNOWN - free space:| Simply changing the order of the mount_list creation does not fix the problem as process_arguments uses the mount list in calls to np_set_best_match(), but does nothing with the results. I commented them and now the program works as it should. Diff output: $ diff check_disk.c check_disk.c.new 193,194d192 < mount_list = read_file_system_list (0); < 200a199,200 > mount_list = read_file_system_list (0); > 642c642 < np_set_best_match(se, mount_list, exact_match); --- > /* np_set_best_match(se, mount_list, exact_match); */ 750c750 < np_set_best_match(path_select_list, mount_list, exact_match); --- > /* np_set_best_match(path_select_list, mount_list, exact_match); */ Detailed output from fixed binary: $ sudo umount /home/userdir $ plugins/check_disk.new -w 5% -c 1% -vvvvv -e -p /home/userdir calling stat on /home/userdir Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 calling stat on /home/userdir For /home/userdir, total=2129920, available=1047846, available_to_root=1047846, used=1082074, fsp.fsu_files=4133162, fsp.fsu_ffree=4031760 For /home/userdir, used_pct=51 free_pct=49 used_units=33814 free_units=32745 total_units=66560 used_inodes_pct=3 free_inodes_pct=97 fsp.fsu_blocksize=32768 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK OK /home/userdir 32745 MB (49% inode=97%);| /home/userdir=33814MB;63232;65894;0;66560 Thanks, Erik Erik Welch - Unix Administrator NVIDIA 2701 San Tomas Expwy Santa Clara, CA 95050 ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu Nov 6 23:48:11 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 06 Nov 2008 17:48:11 -0500 Subject: [Nagiosplug-devel] Bug and fix for the check_disk plugin In-Reply-To: <18A1316EEEE31E46AC536571A107579B12C0246FE9@HQMAIL01.nvidia.com> References: <18A1316EEEE31E46AC536571A107579B12C0246FE9@HQMAIL01.nvidia.com> Message-ID: <4913742B.3020307@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Welch wrote: > Bug in plugins/check_disk.c from nagios-plugins-1.4.12 (and prior) > * $Id: check_disk.c 1991 2008-05-07 10:02:42Z dermoth $ > > The program collects the mounted filesystem data before it processes the > command line arguments. This is a problem for multiple reasons: > * Why spend cycles on the filesystem if there is an error or --help in > the arguments? > * The argument processing stats the -p options to mount them in an > autofs environment, but they won't have been mounted yet... > > Detailed output showing the autofs problem: > $ sudo umount /home/userdir > $ plugins/check_disk -w 5% -c 1% -vvvvv -e -p /home/userdir > calling stat on /home/userdir > Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 > calling stat on /home/userdir > DISK UNKNOWN - free space:| > > Simply changing the order of the mount_list creation does not fix the > problem as process_arguments uses the mount list in calls to > np_set_best_match(), but does nothing with the results. I commented > them and now the program works as it should. > > Diff output: > $ diff check_disk.c check_disk.c.new > 193,194d192 > < mount_list = read_file_system_list (0); > < > 200a199,200 >> mount_list = read_file_system_list (0); >> > 642c642 > < np_set_best_match(se, mount_list, exact_match); > --- >> /* np_set_best_match(se, mount_list, exact_match); */ > 750c750 > < np_set_best_match(path_select_list, mount_list, exact_match); > --- >> /* np_set_best_match(path_select_list, mount_list, exact_match); */ Thank you for your bug report. Could you please send you patch as unified diff (diff -u check_disk.c check_disk.c.new) and I will most likely apply it to SVN. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJE3Qq6dZ+Kt5BchYRAuwVAKDOc8uo8psVPA3TCtk6AlWZ18Cd6wCg2U7G ZxCMP5az7p7lEWJhMVovcB4= =5eDv -----END PGP SIGNATURE----- From ewelch at nvidia.com Fri Nov 7 00:17:53 2008 From: ewelch at nvidia.com (Erik Welch) Date: Thu, 6 Nov 2008 15:17:53 -0800 Subject: [Nagiosplug-devel] Check_disk plugin unified diff Message-ID: <18A1316EEEE31E46AC536571A107579B12C0246FEB@HQMAIL01.nvidia.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --- ./check_disk.c.new Thu Nov 6 10:58:28 2008 +++ /tmp/nagios-plugins-1.4.12/plugins/check_disk.c Wed May 7 03:02:42 2008 @@ -190,14 +190,14 @@ bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); + mount_list = read_file_system_list (0); + /* Parse extra opts if any */ argv = np_extra_opts (&argc, argv, progname); if (process_arguments (argc, argv) == ERROR) usage4 (_("Could not parse arguments")); - - mount_list = read_file_system_list (0); - - /* If a list of paths has not been selected, find entire mount list and create list of paths */ @@ -639,7 +639,7 @@ } se->group = group; set_all_thresholds(se); - - /* np_set_best_match(se, mount_list, exact_match); */ + np_set_best_match(se, mount_list, exact_match); stat_path(se); path_selected = TRUE; break; @@ -747,7 +747,7 @@ fnd = FALSE; path_selected = TRUE; - - /* np_set_best_match(path_select_list, mount_list, exact_match); */ + np_set_best_match(path_select_list, mount_list, exact_match); cflags = default_cflags; break; Erik Welch - Unix Administrator NVIDIA 2701 San Tomas Expwy Santa Clara, CA 95050 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkkTeyAACgkQgGzpy3g56SebYQCdG7mws2AybxsBPR9Opn53I9K9 3HAAniwPRbUOGBV/TUJSae0uHMZ9PLy0 =Bzz0 -----END PGP SIGNATURE----- ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From dermoth at aei.ca Fri Nov 7 04:00:35 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 06 Nov 2008 22:00:35 -0500 Subject: [Nagiosplug-devel] Check_disk plugin unified diff In-Reply-To: <18A1316EEEE31E46AC536571A107579B12C0246FEB@HQMAIL01.nvidia.com> References: <18A1316EEEE31E46AC536571A107579B12C0246FEB@HQMAIL01.nvidia.com> Message-ID: <4913AF53.9060407@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/11/08 06:17 PM, Erik Welch wrote: > --- ./check_disk.c.new Thu Nov 6 10:58:28 2008 > +++ /tmp/nagios-plugins-1.4.12/plugins/check_disk.c Wed May 7 03:02:42 2008 > @@ -190,14 +190,14 @@ > bindtextdomain (PACKAGE, LOCALEDIR); > textdomain (PACKAGE); > > + mount_list = read_file_system_list (0); > + > /* Parse extra opts if any */ > argv = np_extra_opts (&argc, argv, progname); > > if (process_arguments (argc, argv) == ERROR) > usage4 (_("Could not parse arguments")); > > - mount_list = read_file_system_list (0); > - > /* If a list of paths has not been selected, find entire > mount list and create list of paths > */ > @@ -639,7 +639,7 @@ > } > se->group = group; > set_all_thresholds(se); > - /* np_set_best_match(se, mount_list, exact_match); */ > + np_set_best_match(se, mount_list, exact_match); > stat_path(se); > path_selected = TRUE; > break; > @@ -747,7 +747,7 @@ > > fnd = FALSE; > path_selected = TRUE; > - /* np_set_best_match(path_select_list, mount_list, exact_match); */ > + np_set_best_match(path_select_list, mount_list, exact_match); > cflags = default_cflags; > > break; Thanks, although next time please send it as an attachment as important formating is lost when you send it inline. Making a forward patch would be appreciated too ;). Unfortunately I'm afraid this will break multiple options that require a populated mount_list structure during parsing (including -p in some circumstances I think). Also when you said that the result of np_set_best_match() is unused, did you realize that path_select_list is declared globally and np_set_best_match() modify data inside that structure? Again, there's some other behaviours that are likely broken. And as expected, applying your path breaks some of the built-in tests (5 tests to be more precise): Failed Test Stat Wstat Total Fail List of Failed - ------------------------------------------------------------------------------- t/check_disk.t 5 1280 78 5 66 72-74 76 I'm not very used to automount environments (didn't use one for years), so unless you can find a way to fix it otherwise I'm affraid I won't be of any help. Maybe you could try re-reading the mountlist after the stat while parsing -p; i.e.: stat_path(se); mount_list = read_file_system_list (0); np_set_best_match(se, mount_list, exact_match); Be sure to comment well why you're doing that though. It would also be interesting to see the performance difference... If the impact is too high it might be worth making this extra read_file_system_list() optional, triggered by another switch. Hope this helps, and thanks for contributing your patches. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJE69T6dZ+Kt5BchYRAkqaAKDj3+OetqY/k5qosD0LcDz1vNyKTgCePZCs xjb+ioI4rLLyWSqrU2b9Oac= =o3pt -----END PGP SIGNATURE----- From Martin.Gerdes at directbox.com Fri Nov 7 15:46:25 2008 From: Martin.Gerdes at directbox.com (Martin.Gerdes at directbox.com) Date: Fri, 07 Nov 2008 15:46:25 Subject: [Nagiosplug-devel] restricted shell for nagios checks Message-ID: <139C07D80B070E2E19329@directbox.com> I wanted to use ssh to execute checkscripts (and evaluate their results). But I didn't want to give that account a full shell, since it isn't necessary for the task, and a risk. So what I decided to do was to write a wrapper to execute the individual scripts, and set it as the shell: in /etc/passwd of the client: nagios:x:9000:9000::/home/nagios:/home/nagios/executeCheck.sh ========executeCheck.sh:======= #!/bin/bash #first parameter is '-c', which we skip shift 1 CMD="`echo "$1" | cut -d ' ' -f1`" CMD_DIR="/home/nagios/plugins" #make sure check name is benign and exists if [ ! "`echo "$CMD" | egrep '^[a-zA-Z0-9_\.-]+$'`" ] || \ [ ! -e "$CMD_DIR/$CMD" ] ; then echo "unknown check '$CMD'" exit 3 fi #protect checks from weird parameters if [ ! "`echo "$1" | egrep '^[a-zA-Z0-9_%,\./ -]+$'`" ] ; then echo "command '$1' contains illegal characters" exit 3 fi #execute command "$CMD_DIR/"$1 =============================== To execute a check, the nagios server calls ssh -q check_... If a file of that name exists in CMD_DIR, it is executed, and its result returned. Opinions or thoughts? Any glaring security holes I am overlooking? (Of course the checks themselves could still contain errors which allow escape to a shell...) From nagios at babar.us Fri Nov 7 18:01:47 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Fri, 7 Nov 2008 18:01:47 +0100 Subject: [Nagiosplug-devel] restricted shell for nagios checks In-Reply-To: <139C07D80B070E2E19329@directbox.com> References: <139C07D80B070E2E19329@directbox.com> Message-ID: <20081107170147.GA7680@mail.babar.us> On Fri, Nov 07, 2008 at 03:46:25PM +0000, Martin.Gerdes at directbox.com wrote: > I wanted to use ssh to execute checkscripts (and evaluate their results). > But I didn't want to give that account a full shell, [zip] > Opinions or thoughts? Any glaring security holes I am overlooking? You might want to have a look at ssh's build-in features for this. Typically, set a key in your authorized_keys with: command="some_wrapper $SSH_ORIGINAL_COMMAND" ssh-dss ... http://www.unix.com.ua/orelly/networking_2ndEd/ssh/ch08_02.htm#ch08-22858 Might help if you've never used this. Just my 2 cts. -- Babar. From dermoth at aei.ca Fri Nov 7 18:48:09 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 07 Nov 2008 12:48:09 -0500 Subject: [Nagiosplug-devel] restricted shell for nagios checks In-Reply-To: <139C07D80B070E2E19329@directbox.com> References: <139C07D80B070E2E19329@directbox.com> Message-ID: <49147F59.1050400@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin.Gerdes at directbox.com wrote: > I wanted to use ssh to execute checkscripts (and evaluate their results). > But I didn't want to give that account a full shell, > since it isn't necessary for the task, and a risk. > So what I decided to do was to write a wrapper to execute the individual > scripts, and set it as the shell: > > in /etc/passwd of the client: > nagios:x:9000:9000::/home/nagios:/home/nagios/executeCheck.sh > > ========executeCheck.sh:======= > #!/bin/bash > > #first parameter is '-c', which we skip > shift 1 > > CMD="`echo "$1" | cut -d ' ' -f1`" > CMD_DIR="/home/nagios/plugins" > > #make sure check name is benign and exists > if [ ! "`echo "$CMD" | egrep '^[a-zA-Z0-9_\.-]+$'`" ] || \ > [ ! -e "$CMD_DIR/$CMD" ] ; then > echo "unknown check '$CMD'" > exit 3 > fi > > #protect checks from weird parameters > if [ ! "`echo "$1" | egrep '^[a-zA-Z0-9_%,\./ -]+$'`" ] ; then > echo "command '$1' contains illegal characters" > exit 3 > fi > > #execute command > "$CMD_DIR/"$1 > > =============================== > > To execute a check, the nagios server calls ssh -q check_... > If a file of that name exists in CMD_DIR, it is executed, > and its result returned. > > Opinions or thoughts? Any glaring security holes I am overlooking? > (Of course the checks themselves could still contain errors > which allow escape to a shell...) Unless you want one key per check/arguments, you'll need a wrapper script anyway. Since you can get the original command trough environment variable, you can still sanitize it and exec it from a wrapper (the key runs your wrapper script, and the wrapper script exec the original command if it's deemed safe). I do this for rsync over ssh, although in this case it's mainly to avoid accidentally destroying the remote file structure since it uses --delete. Another option would be using latest OpenSSH's chroot capabilities to give it access only to required binaries. Although, my preference is still using nrpe with cfg_dirs, so all I have to do is copy the configs over and issue a HUP to nrpe to activate new configs. I have scripts for that so updating the configs is just as simple. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJFH9Z6dZ+Kt5BchYRAuebAKDQ9XXb5FXRELPVtlDcTz1oVDgkxgCeOKRH 1JXAyVRB/enywfIGKM8sr9s= =Fnkq -----END PGP SIGNATURE----- From ewelch at nvidia.com Fri Nov 7 20:19:26 2008 From: ewelch at nvidia.com (Erik Welch) Date: Fri, 7 Nov 2008 11:19:26 -0800 Subject: [Nagiosplug-devel] Check_disk plugin update Message-ID: <18A1316EEEE31E46AC536571A107579B12C0246FF1@HQMAIL01.nvidia.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, the benefits of unit testing. Proves me wrong when I so desperately deserve it :-). My testing consisted of running it in my limited environment and it worked like a charm. (This is what happens when you have a perl/python programmer learn enough C to try and debug a problem). Your suggestion to rebuild the mount_list worked perfectly. On a system that had 120 mounts (115 automounts), there doesn't seem to be much of a performance hit, though I only check one path at a time. I umounted the test volume before each run, and did a couple runs of each binary, dropped the first time result of each, and averaged the times. Let me know if you want anything more than the output of time for perf testing. $ time ./check_disk.badautofs -vvvv -w 5% -c 1% -p /home/userdir calling stat on /home/userdir Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 calling stat on /home/userdir DISK UNKNOWN - free space:| real 0m0.018s user 0m0.000s sys 0m0.000s $ time plugins/check_disk -vvvv -w 5% -c 1% -p /home/userdir calling stat on /home/userdir Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 calling stat on /home/userdir For /home/userdir, total=2129920, available=1047858, available_to_root=1047858, used=1082062, fsp.fsu_files=4133162, fsp.fsu_ffree=4031761 For /home/userdir, used_pct=51 free_pct=49 used_units=33814 free_units=32745 total_units=66560 used_inodes_pct=3 free_inodes_pct=97 fsp.fsu_blocksize=32768 mult=1048576 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK OK - free space: /home/userdir 32745 MB (49% inode=97%);| /home/userdir=33814MB;63232;65894;0;66560 real 0m0.027s user 0m0.000s sys 0m0.000s Another thing that I've found is that the version of automount is important. One of my test systems RHEL R3U2 (kernel 2.4.21-47 automount v4.1.3-154) and none of the check_disk versions work. The stat() never seems to mount the volume. I'm not going to troubleshoot this as this is an old crufty system. The patched check_disk works on both my RedHat 7.2 (kernel 2.4.35 automount v3.1.7) and CentOS 4.5 (kernel 2.6.24.2, automount v5.0.2) systems. Can you run the attached patch through your unit tests to see if I break anything new? I couldn't find a way to add an ARGV to manage the repopulation of mount_list as it needs to happen during process_arguments() in the "case 'p'" section before the np_set_best_match() is executed, but I also couldn't spend much time on this now that I have a working solution... <> Thanks, erik Erik Welch - Unix Administrator NVIDIA 2701 San Tomas Expwy Santa Clara, CA 95050 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkkUlL4ACgkQgGzpy3g56ScpogCdHf5/A8hv0t5JOSKWnuagxNlr J/0AnR0CnzNX8V4DzP7lWrcezvvEqLvC =uxFi -----END PGP SIGNATURE----- ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: check_disk.patch.gpg Type: application/octet-stream Size: 819 bytes Desc: check_disk.patch.gpg URL: From sfnetmail at nurfuerspam.de Fri Nov 7 21:11:09 2008 From: sfnetmail at nurfuerspam.de (Olli Hauer) Date: Fri, 07 Nov 2008 21:11:09 +0100 Subject: [Nagiosplug-devel] segfault in plugin check_nt and solution / patch Message-ID: <20081107201109.47390@gmx.net> Hi, in the plugin check_nt there is a wrong handling that cause the plugin segfault. I have already created a bug report with patch, but no feedback until now. http://sourceforge.net/tracker/?func=detail&atid=397599&aid=2179754&group_id=29880 patch: http://sourceforge.net/tracker/download.php?group_id=29880&atid=397599&file_id=297946&aid=2179754 Since the probem is descriped in the bug report i want to hear if someon can confirm this. the following lines (patch wo. formating to keep the code short) shows what should be changed in the code. for a correct formating (long patch) please grab the patch from the bug report. Regards, olli hauer @@ -97,6 +97,8 @@ char *temp_string_perf=NULL; char *description=NULL,*counter_unit = NULL; char *minval = NULL, *maxval = NULL, *errcvt = NULL; + char *fds=NULL; + char *tds=NULL; double total_disk_space=0; double free_disk_space=0; @@ -218,8 +220,15 @@ else { asprintf(&send_buffer,"%s&4&%s", req_password, value_list); fetch_data (server_address, server_port, send_buffer); - free_disk_space=atof(strtok(recv_buffer,"&")); - total_disk_space=atof(strtok(NULL,"&")); + fds=strtok(recv_buffer,"&"); + tds=strtok(NULL,"&"); + + if (fds != NULL) + free_disk_space=atof(fds); + if (tds != NULL) + total_disk_space=atof(tds); + + if (total_disk_space>0) { percent_used_space = ((total_disk_space - free_disk_space) / total_disk_space) * 100; warning_used_space = ((float)warning_value / 100) * total_disk_space; critical_used_space = ((float)critical_value / 100) * total_disk_space; @@ -241,7 +250,8 @@ output_message = strdup (temp_string); perfdata = temp_string_perf; - } else { + } + } else { output_message = strdup (_("Free disk space : Invalid drive ")); return_code=STATE_UNKNOWN; } -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From dermoth at aei.ca Fri Nov 7 21:45:48 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 07 Nov 2008 15:45:48 -0500 Subject: [Nagiosplug-devel] Check_disk plugin update In-Reply-To: <18A1316EEEE31E46AC536571A107579B12C0246FF1@HQMAIL01.nvidia.com> References: <18A1316EEEE31E46AC536571A107579B12C0246FF1@HQMAIL01.nvidia.com> Message-ID: <4914A8FC.1080407@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Welch wrote: > Ah, the benefits of unit testing. Proves me wrong when I so desperately deserve it :-). My testing consisted of running it in my limited environment and it worked like a charm. (This is what happens when you have a perl/python programmer learn enough C to try and debug a problem). Your suggestion to rebuild the mount_list worked perfectly. > > On a system that had 120 mounts (115 automounts), there doesn't seem to be much of a performance hit, though I only check one path at a time. I umounted the test volume before each run, and did a couple runs of each binary, dropped the first time result of each, and averaged the times. Let me know if you want anything more than the output of time for perf testing. > > > $ time ./check_disk.badautofs -vvvv -w 5% -c 1% -p /home/userdir > calling stat on /home/userdir > Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 > calling stat on /home/userdir > DISK UNKNOWN - free space:| > > real 0m0.018s > user 0m0.000s > sys 0m0.000s > > $ time plugins/check_disk -vvvv -w 5% -c 1% -p /home/userdir > calling stat on /home/userdir > Thresholds(pct) for /home/userdir warn: 5.000000 crit 1.000000 > calling stat on /home/userdir > For /home/userdir, total=2129920, available=1047858, available_to_root=1047858, used=1082062, fsp.fsu_files=4133162, fsp.fsu_ffree=4031761 > For /home/userdir, used_pct=51 free_pct=49 used_units=33814 free_units=32745 total_units=66560 used_inodes_pct=3 free_inodes_pct=97 fsp.fsu_blocksize=32768 mult=1048576 > Freespace_units result=0 > Freespace% result=0 > Usedspace_units result=0 > Usedspace_percent result=0 > Usedinodes_percent result=0 > Freeinodes_percent result=0 > DISK OK - free space: /home/userdir 32745 MB (49% inode=97%);| /home/userdir=33814MB;63232;65894;0;66560 > > real 0m0.027s > user 0m0.000s > sys 0m0.000s > > Another thing that I've found is that the version of automount is important. > One of my test systems RHEL R3U2 (kernel 2.4.21-47 automount v4.1.3-154) and none of the check_disk versions work. The stat() never seems to mount the volume. I'm not going to troubleshoot this as this is an old crufty system. > The patched check_disk works on both my RedHat 7.2 (kernel 2.4.35 automount v3.1.7) and CentOS 4.5 (kernel 2.6.24.2, automount v5.0.2) systems. Thanks. The mount_path will be rebuilt on each "-p" invocation... I'll do some testing myself, but if you don't see any big difference with and without the patch applied when specifying 10-15 path elements I'd say it's fine. > Can you run the attached patch through your unit tests to see if I break anything new? Will do tonight and keep you in the loop. > I couldn't find a way to add an ARGV to manage the repopulation of mount_list as it needs to happen during process_arguments() in the "case 'p'" section before the np_set_best_match() is executed, but I also couldn't spend much time on this now that I have a working solution... Easy; I'll take care of it if needed. ;) Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJFKj86dZ+Kt5BchYRAtlwAKCRf/36XJNxOENDjwM+Xy5OYgCdiwCbBFT5 +PUqakXIi4dKSXqnSQpBqrE= =L4sZ -----END PGP SIGNATURE----- From ewelch at nvidia.com Fri Nov 7 22:54:23 2008 From: ewelch at nvidia.com (Erik Welch) Date: Fri, 7 Nov 2008 13:54:23 -0800 Subject: [Nagiosplug-devel] Check_disk plugin update In-Reply-To: <4914A8FC.1080407@aei.ca> References: <18A1316EEEE31E46AC536571A107579B12C0246FF1@HQMAIL01.nvidia.com> <4914A8FC.1080407@aei.ca> Message-ID: <18A1316EEEE31E46AC536571A107579B12C0246FF6@HQMAIL01.nvidia.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Irrelevant (my earlier email) data truncated. Comments inline following [erik] as Outlook handles inline comments badly. *feh* Thanks, erik - -----Original Message----- From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] Sent: Friday, November 07, 2008 12:46 PM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] Check_disk plugin update - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks. The mount_path will be rebuilt on each "-p" invocation... I'll do some testing myself, but if you don't see any big difference with and without the patch applied when specifying 10-15 path elements I'd say it's fine. [erik] I only specified one path element in my tests, because that is all I need in my environment. If you create a solution to the ARGV issue (below), I suspect that it will also fix the constant re-read of mounted disks. > I couldn't find a way to add an ARGV to manage the repopulation of mount_list as it needs to happen during process_arguments() in the "case 'p'" section before the np_set_best_match() is executed, but I also couldn't spend much time on this now that I have a working solution... Easy; I'll take care of it if needed. ;) [erik] Sweet! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkkUuQ4ACgkQgGzpy3g56Sf7tgCgkaKvBhbQYlsAHCO2iGDyZvby COMAoJ/roIe13hDgPJV2BInB5i3fKmVM =IjHo -----END PGP SIGNATURE----- ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From noreply at sourceforge.net Sat Nov 8 03:10:17 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:10:17 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2155152 ] Added option to check_http to choose the HTTP method Message-ID: Patches item #2155152, was opened at 2008-10-09 15:09 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan (jblipphaus) Assigned to: Nobody/Anonymous (nobody) Summary: Added option to check_http to choose the HTTP method Initial Comment: Added the new option -j / --method to check_http. I wanted the program to be able to use any HTTP method (like HEAD, PUT, DELETE...). When this option is used, the option -P / --post just sets the content and not the method. For example "check_http -H hostname -j PUT -P testdata -u /testfile". Also changed the testscript to test the new option. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:10 Message: Jan, Thanks for the patch, especially the updating of the tests. Commit number 2075. If you let me know your full name, I'll add you to the THANKS file. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 From noreply at sourceforge.net Sat Nov 8 03:32:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:32:36 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2089159 ] check_http: extra headers and redirect doesn't work Message-ID: Patches item #2089159, was opened at 2008-09-02 16:12 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2089159&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Van de Walle (dietervdw) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: extra headers and redirect doesn't work Initial Comment: Patch against Plugin Version (-V output): check_http v1991 (nagios-plugins 1.4.12) Plugin Name: check_http Example Plugin Commandline: ./check_http -u "http://somewhere" -f follow -k "header: value" Tested on operating system: Ubuntu Tested on architecture: x86 Tested with compiler: gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) When adding extra headers and doing a redirect, mayhem occurs. The extra headers are free'd in the first check_http() call, making the second check_http() call after the redir() create a faulty request. Drop the free(http_opt_headers) . ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:32 Message: Dieter, Thanks for the report. Fixed in commit 2076. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2089159&group_id=29880 From noreply at sourceforge.net Sat Nov 8 03:34:47 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:34:47 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1831132 ] add HEAD support to check_http Message-ID: Patches item #1831132, was opened at 2007-11-13 15:27 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1831132&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: sni (svennierlein) Assigned to: Nobody/Anonymous (nobody) Summary: add HEAD support to check_http Initial Comment: Patch for: check_http v1759 (nagios-plugins 1.4.10) This patch adds an additional --head option to make check_http a HEAD request instead of the default GET. Plugin Name: check_http Example Plugin Commandline: ./check_http --head -H yourhost Tested on operating system: Linux Tested on architecture: SLES 9 (i586) Tested with compiler: gcc version 3.3.3 (SuSE Linux) I carefully tested the patch, but these are still my first steps with c code. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:34 Message: Sven, Thanks for the patch, but this has been implemented slightly differently in SF https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 Ton ---------------------------------------------------------------------- Comment By: sni (svennierlein) Date: 2008-02-15 14:27 Message: Logged In: YES user_id=1936413 Originator: YES New patch for revision (1.4.11 release): Id: check_http.c 1861 2007-12-11 05:57:35Z dermoth File Added: check_http.head.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1831132&group_id=29880 From noreply at sourceforge.net Sat Nov 8 03:35:13 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:35:13 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2155152 ] Added option to check_http to choose the HTTP method Message-ID: Patches item #2155152, was opened at 2008-10-09 15:09 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan (jblipphaus) >Assigned to: Ton Voon (tonvoon) Summary: Added option to check_http to choose the HTTP method Initial Comment: Added the new option -j / --method to check_http. I wanted the program to be able to use any HTTP method (like HEAD, PUT, DELETE...). When this option is used, the option -P / --post just sets the content and not the method. For example "check_http -H hostname -j PUT -P testdata -u /testfile". Also changed the testscript to test the new option. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:10 Message: Jan, Thanks for the patch, especially the updating of the tests. Commit number 2075. If you let me know your full name, I'll add you to the THANKS file. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 From noreply at sourceforge.net Sat Nov 8 03:39:12 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:39:12 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1712985 ] Make check_http post binary data Message-ID: Patches item #1712985, was opened at 2007-05-04 19:11 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1712985&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: Unstable (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: T. Pascal (t_pascal) Assigned to: Nobody/Anonymous (nobody) Summary: Make check_http post binary data Initial Comment: This is a horrible hack to post binary data (passed as -P "URL-encoded bin data"). It works, but really needs to be fixed up to check the input and use proper libararies. I also need to hack it to allow a binary data search for the -s option (which I haven't done yet). T. Pascal ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:39 Message: T Pascal, Yes, this is quite horrible :). What about having a new flag which specifies a file to use for the post data? I can see that being a lot cleaner to implement, rather than trying to specify on the command line. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1712985&group_id=29880 From noreply at sourceforge.net Sat Nov 8 03:46:45 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 02:46:45 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1868822 ] check_http link fails with openssl installed Message-ID: Bugs item #1868822, was opened at 2008-01-10 20:24 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&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: Dave van Nierop (ca28200) >Assigned to: Ton Voon (tonvoon) Summary: check_http link fails with openssl installed Initial Comment: Compile and link of nagios-plugins-1.4.10 succeeds, but a compile and link of nagios-plugins-1.4.11 fails. Problem: All function references for np_net_ssl_* (included in netutils.h) in plugins/check_http.c are unresolved when the linker fires in. I tried to figure it out, but just didn't have the time. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:46 Message: Dave, Is this still a problem with the latest snapshot? http://nagiosplug.sf.net/snapshot If so, would you like to provide a tinderbox build server so we can see the error and you will know that it will continue to be fixed: http://tinderbox.opsera.com I'm marking the call into pending so this will autoclose if there are no updates. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&group_id=29880 From noreply at sourceforge.net Sat Nov 8 04:04:11 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 03:04:11 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1998257 ] only "Invalid HTTP response received from host" Message-ID: Bugs item #1998257, was opened at 2008-06-19 22:31 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1998257&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: Duplicate Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Ton Voon (tonvoon) Summary: only "Invalid HTTP response received from host" Initial Comment: The following Bugreport we got against our debian package: Rather than stating what it got, the script just barfs generically. The code says: if (!strstr (status_line, server_expect)) { if (server_port == HTTP_PORT) asprintf (&msg, _("Invalid HTTP response received from host\n")); else asprintf (&msg, _("Invalid HTTP response received from host on port %d\n"), server_port); die (STATE_CRITICAL, "HTTP CRITICAL - %s", msg); } It should add the contents of the status_line (as %s) into the output (msg). Oddly enough, the script actually does this pretty consistently in the lines below, only in these two cases does it fail to mention the actual status line. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486932 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 03:04 Message: Hi Jan, This looks like it is already in the latest code with testcases to cover it. Thanks for raising. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1998257&group_id=29880 From noreply at sourceforge.net Sat Nov 8 08:35:46 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 07:35:46 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2155152 ] Added option to check_http to choose the HTTP method Message-ID: Patches item #2155152, was opened at 2008-10-09 16:09 Message generated for change (Comment added) made by jblipphaus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Jan (jblipphaus) Assigned to: Ton Voon (tonvoon) Summary: Added option to check_http to choose the HTTP method Initial Comment: Added the new option -j / --method to check_http. I wanted the program to be able to use any HTTP method (like HEAD, PUT, DELETE...). When this option is used, the option -P / --post just sets the content and not the method. For example "check_http -H hostname -j PUT -P testdata -u /testfile". Also changed the testscript to test the new option. ---------------------------------------------------------------------- Comment By: Jan (jblipphaus) Date: 2008-11-08 08:35 Message: Hi Ton, my full name is Jan Lipphaus. Jan ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-11-08 03:10 Message: Jan, Thanks for the patch, especially the updating of the tests. Commit number 2075. If you let me know your full name, I'll add you to the THANKS file. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 From noreply at sourceforge.net Sat Nov 8 09:41:27 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Nov 2008 08:41:27 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2155152 ] Added option to check_http to choose the HTTP method Message-ID: Patches item #2155152, was opened at 2008-10-09 15:09 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jan (jblipphaus) Assigned to: Ton Voon (tonvoon) Summary: Added option to check_http to choose the HTTP method Initial Comment: Added the new option -j / --method to check_http. I wanted the program to be able to use any HTTP method (like HEAD, PUT, DELETE...). When this option is used, the option -P / --post just sets the content and not the method. For example "check_http -H hostname -j PUT -P testdata -u /testfile". Also changed the testscript to test the new option. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2008-11-08 08:41 Message: Thanks - added! ---------------------------------------------------------------------- Comment By: Jan (jblipphaus) Date: 2008-11-08 07:35 Message: Hi Ton, my full name is Jan Lipphaus. Jan ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2008-11-08 02:10 Message: Jan, Thanks for the patch, especially the updating of the tests. Commit number 2075. If you let me know your full name, I'll add you to the THANKS file. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2155152&group_id=29880 From noreply at sourceforge.net Mon Nov 10 19:19:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Nov 2008 18:19:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-2257044 ] check_http client ssl certificate support Message-ID: Feature Requests item #2257044, was opened at 2008-11-10 13:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2257044&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 Priority: 5 Private: No Submitted By: cybernet_ (cybernet_) Assigned to: Nobody/Anonymous (nobody) Summary: check_http client ssl certificate support Initial Comment: Hi, I know thant there's a contrib plugin check_http-with-client-certificate.c that support client cert but it would be nice that this feature was added to the currect version of check_http. The contrib plugin mentioned is a little bit out of date (2003). thanks Cybernet_ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2257044&group_id=29880 From rich at richhorner.com Mon Nov 10 22:19:25 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Mon, 10 Nov 2008 16:19:25 -0500 Subject: [Nagiosplug-devel] standard in must be a tty In-Reply-To: <5383c62b0811050824g68aa3e16w45076e8344291021@mail.gmail.com> References: <49102C63.A859.003B.0@pubpress.com> <5383c62b0811050824g68aa3e16w45076e8344291021@mail.gmail.com> Message-ID: <7a65a83a0811101319l6a2ea674xf08b1bba454f27af@mail.gmail.com> Sorry it took me so long to get back to you. I've been super busy. I can't actually run this because I don't have whatever this service is but it appears to be exactly what I suspected and that is that you have a su -c call in the init script. Actually, there are several but only one in the "status" section. I agree with Hans, you should rewrite the check status functionality of the init script into your plugin. It looks like it might need root privileges in which case I suggest you setup the call (or your script) to run via sudo with NOPASSWD set on the single command in /etc/sudoers. Rich(ard) On Wed, Nov 5, 2008 at 11:24 AM, Hans Engelen wrote: > Aside from the error what does the init script do to check the status. > Most scripts just lookup a pid in a pid file and check to see if said > pid is still running. > > Rather then forking the script it might be easier to redo that check > in the plugin itself. On that note it might even be easier to just > check if the process is running rather then fork to a script. > > Note that I don't know what a dalimserver is so might not apply. > > Cheers, > Hans > > On Tue, Nov 4, 2008 at 5:05 PM, Chase Simms wrote: >> I am working on a plugin to monitor a process. >> >> http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2780.html;d=1 >> >> It works fine when run locally through the shell. But when run through >> the NRPE sandbox it gets the "standard in must be a tty" error. Where >> can I find more information on the NRPE sandbox and how to work >> with/around it? >> >> I tried rewriting it as a shell script and it came back with the same >> result. >> >> The broken part is where I try to catch the output of - `/sbin/service >> dalimServer status` >> >> When I run it through NRPE it comes back with nothing. >> >> Thank you, >> Chase >> >> The information in this email is intended for the sole use of the >> addressees and may be confidential and subject to protection under the >> law. If you are not the intended recipient, you are hereby notified that >> any distribution or copying of this email is strictly prohibited. If you >> have received this message in error, please reply and delete your copy. >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________________ >> Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net >> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >> ::: Please include plugins version (-v) and OS when reporting any issue. >> ::: Messages without supporting info will risk being sent to /dev/null >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso rich at richhorner.com http://richhorner.com From dermoth at aei.ca Tue Nov 11 00:25:13 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 10 Nov 2008 18:25:13 -0500 Subject: [Nagiosplug-devel] standard in must be a tty In-Reply-To: <7a65a83a0811101319l6a2ea674xf08b1bba454f27af@mail.gmail.com> References: <49102C63.A859.003B.0@pubpress.com> <5383c62b0811050824g68aa3e16w45076e8344291021@mail.gmail.com> <7a65a83a0811101319l6a2ea674xf08b1bba454f27af@mail.gmail.com> Message-ID: <4918C2D9.2020105@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/11/08 04:19 PM, Richard Edward Horner wrote: > Sorry it took me so long to get back to you. I've been super busy. > > I can't actually run this because I don't have whatever this service > is but it appears to be exactly what I suspected and that is that you > have a su -c call in the init script. Actually, there are several but > only one in the "status" section. > > I agree with Hans, you should rewrite the check status functionality > of the init script into your plugin. It looks like it might need root > privileges in which case I suggest you setup the call (or your script) > to run via sudo with NOPASSWD set on the single command in > /etc/sudoers. Not sure it it will actually work, but if the only thing needed is a tty, you could try compiling a custom check_by_ssh like this: 1. Prepare a nagios-plugins source tree (configure only, don't run make yet, although it it's already compiled it doesn't matter) 2. Edit config.h, find the following line: /* path to ssh binary */ #define SSH_COMMAND "/usr/bin/ssh" Add " -tt" to it (-t is to allocate a tty, and specified twice it force it even if there's no local tty) so if you have the same path as above, that would be: /* path to ssh binary */ #define SSH_COMMAND "/usr/bin/ssh -tt" 3. Run "make", and copy check_by_ssh to your plugins directory (you can rename it too, like check_by_ssh_tty) 4. Try it (you'll need a key pair set-up for log-in, man ssh for more info). Hope this helps - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGMLZ6dZ+Kt5BchYRAs5OAJ9ngBlAd4qetcYoJ3K3o14Uujqg9ACg4MKH 9nQCalPXi15zXvXLedbLiBk= =seu5 -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed Nov 12 11:32:25 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Nov 2008 10:32:25 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2268675 ] fix for quoting in check_by_ssh Message-ID: Patches item #2268675, was opened at 2008-11-12 11:32 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=2268675&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: Will Preston (wpreston) Assigned to: Nobody/Anonymous (nobody) Summary: fix for quoting in check_by_ssh Initial Comment: check_by_ssh builds its check into a single string and passes it to the np_runcmd() function to execute ssh. This function parses the command line back into ssh options and calls execve. Unfortunately the conversion causes various problems with quoted strings. The patch bypasses this conversion and passes the option string directly to execve. This should ensure that ssh checks and local checks are identical. Example: > /bin/sh -c "echo '"'$PATH'"'" $PATH > /bin/sh -c 'echo "a b"' a b > Unpatched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" /usr/local/bin:/usr/bin/:/bin > check_by_ssh -H localhost -C 'echo "a b"' Could not open pipe: /usr/bin/ssh localhost 'echo "a b"' > Patched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" $PATH > check_by_ssh -H localhost -C 'echo "a b"' a b > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2268675&group_id=29880 From dermoth at aei.ca Fri Nov 14 03:50:59 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 13 Nov 2008 21:50:59 -0500 Subject: [Nagiosplug-devel] FW: Check_disk plugin update In-Reply-To: <18A1316EEEE31E46AC536571A107579B12F7A19703@HQMAIL01.nvidia.com> References: <18A1316EEEE31E46AC536571A107579B12F7A19703@HQMAIL01.nvidia.com> Message-ID: <491CE793.40109@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/11/08 01:52 PM, Erik Welch wrote: > How did your testing go? Is there more work/testing that you need from me? > > We have a rather large and complex automount environment, so we tend to hit some interesting corner cases on just about every tool we use... Sorry; I've been busy with work and converting the repository for a SVN -> Git migration coming soon. The last patch works, although it obviously leak memory for each -p invocation... I tried freeing the struct first but for reasons that I still don't understand it fails horribly... So I finally got it working by using a temporary struct for that code block. I'd still like some feedback from other developers, as I don't like much my current code, and I would especially like to know why it failed when freeing the global array. I could also make it a configure option, because I doubt many people will use that anyway. Oh, out of curiosity, since the stat call mounts the partition, shouldn't it be mounted on further checks? What is your check interval and max_check_attempt? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHOeT6dZ+Kt5BchYRAsYAAJ9gV5AD1ZGKKn3q9EXPBHjz+QyhoQCg0i+Q G3aEeUdz2K/rEk1yoR+sKpg= =sXR6 -----END PGP SIGNATURE----- From dermoth at aei.ca Fri Nov 14 04:14:53 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 13 Nov 2008 22:14:53 -0500 Subject: [Nagiosplug-devel] FW: Check_disk plugin update In-Reply-To: <491CE793.40109@aei.ca> References: <18A1316EEEE31E46AC536571A107579B12F7A19703@HQMAIL01.nvidia.com> <491CE793.40109@aei.ca> Message-ID: <491CED2D.8020008@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/11/08 09:50 PM, Thomas Guyot-Sionnest wrote: > On 13/11/08 01:52 PM, Erik Welch wrote: >> How did your testing go? Is there more work/testing that you need from me? > >> We have a rather large and complex automount environment, so we tend to hit some interesting corner cases on just about every tool we use... > > Sorry; I've been busy with work and converting the repository for a > SVN -> Git migration coming soon. > > The last patch works, although it obviously leak memory for each -p > invocation... I tried freeing the struct first but for reasons that I > still don't understand it fails horribly... So I finally got it working > by using a temporary struct for that code block. > > I'd still like some feedback from other developers, as I don't like much > my current code, and I would especially like to know why it failed when > freeing the global array. I could also make it a configure option, > because I doubt many people will use that anyway. > > > Oh, out of curiosity, since the stat call mounts the partition, > shouldn't it be mounted on further checks? What is your check interval > and max_check_attempt? > Oops, I totally forgot to post the url to my Git repo with this patch: http://solaris.beaubien.net/cgi-bin/gitweb.cgi/nagiosplug-dermoth.git It's not in trunk yet, and I may amend it. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHO0t6dZ+Kt5BchYRAtRrAJ43wD7ytbGFG44vbO/MYgDkabGC9gCfafZj bfBcqttw3C/bEZRvb7zhIN8= =2ZJp -----END PGP SIGNATURE----- From dermoth at aei.ca Sat Nov 15 00:40:08 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 14 Nov 2008 18:40:08 -0500 Subject: [Nagiosplug-devel] FW: Check_disk plugin update In-Reply-To: <491CED2D.8020008@aei.ca> References: <18A1316EEEE31E46AC536571A107579B12F7A19703@HQMAIL01.nvidia.com> <491CE793.40109@aei.ca> <491CED2D.8020008@aei.ca> Message-ID: <491E0C58.7020503@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/11/08 10:14 PM, Thomas Guyot-Sionnest wrote: > On 13/11/08 09:50 PM, Thomas Guyot-Sionnest wrote: >> On 13/11/08 01:52 PM, Erik Welch wrote: >>> How did your testing go? Is there more work/testing that you need from me? >>> We have a rather large and complex automount environment, so we tend to hit some interesting corner cases on just about every tool we use... >> Sorry; I've been busy with work and converting the repository for a >> SVN -> Git migration coming soon. > >> The last patch works, although it obviously leak memory for each -p >> invocation... I tried freeing the struct first but for reasons that I >> still don't understand it fails horribly... So I finally got it working >> by using a temporary struct for that code block. > >> I'd still like some feedback from other developers, as I don't like much >> my current code, and I would especially like to know why it failed when >> freeing the global array. I could also make it a configure option, >> because I doubt many people will use that anyway. > > >> Oh, out of curiosity, since the stat call mounts the partition, >> shouldn't it be mounted on further checks? What is your check interval >> and max_check_attempt? > > > Oops, I totally forgot to post the url to my Git repo with this patch: > > http://solaris.beaubien.net/cgi-bin/gitweb.cgi/nagiosplug-dermoth.git > > It's not in trunk yet, and I may amend it. > Nevermind - this patch has no effect because I forgot to use temp_me instead of mount_list in np_set_best_match. It should work with this little change: in the case 'p':, change: np_set_best_match(se, mount_list, exact_match); to: np_set_best_match(se, temp_me, exact_match); I'm still working on it though, mount_list should be freeable :) - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHgxX6dZ+Kt5BchYRAq69AJ4/gnuoVuhlCLTral2tYBqagWm+6wCg4DCX jmswooE00lAWbMM4oAe0kFE= =7G/V -----END PGP SIGNATURE----- From noreply at sourceforge.net Tue Nov 18 17:49:08 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Nov 2008 16:49:08 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 08:04 Message generated for change (Comment added) made by tcarrez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: Thierry Carrez (tcarrez) Date: 2008-11-18 17:49 Message: A similar bug was filed on Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/291265 Here is the analysis of Jamie Strandboge about it: ------------------- I looked at this a bit, and the math seems to be wrong in this line: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((m.count)?4-(ntohs(m.count)%4):0)) In ntp_request we have (where MAX_CM_SIZE is defined as 468): req.count=htons(MAX_CM_SIZE); Which makes req.count = 54273. Later, we have: if(read(conn, &req, SIZEOF_NTPCM(req)) == -1) So the nbytes for read() ends up being: (12 + 468 + (4 - 0)) = 484 However, a sizeof(req) reveals that it is 480 bytes (this can also be seen by looking at the ntp_control_message struct (1+1+2+2+2+2+2+468)). This is not security relevant, because the 4 bytes that are overwritten end up being the 'conn' file descriptor (as seen from gdb), which triggers read() to: read(3, 0xbffff850, 484) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- resulting in check_ntp_peer to error out with: CRITICAL - Socket timeout after 10 seconds This is a bug whether or not _FORTIFY_SOURCE is used, because read() may SIGALRM. You'll also notice that check_ntp.c suffers from the same problem (the code in question is identical), as seen with: $ /usr/lib/nagios/plugins/check_ntp -H foo -j 1 ------------------ ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2008-09-13 04:20 Message: 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: Thomas Guyot (dermoth) Date: 2008-08-29 06:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 10:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 18:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 16:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From igoyret at alcatel-lucent.com Tue Nov 18 20:42:32 2008 From: igoyret at alcatel-lucent.com (Ignacio Goyret) Date: Tue, 18 Nov 2008 11:42:32 -0800 Subject: [Nagiosplug-devel] [PATCH] check_smtp.c - float warn/crit thresholds Message-ID: <200811181943.mAIJh9jk024380@cliff.eng.ascend.com> Hi all, The attached patched allows check_smtp.c to accept double (floating point) values for warning and critical thresholds. Previously, it only accepted integers. Note that the help message (check_smtp -h) indicated that these parameters were supposed to be DOUBLE so this change makes it consistent. Cheers, -Ignacio PS: The attached patch is svn-based. I found the issue on nagios-plugins-1.4.13. From igoyret at alcatel-lucent.com Tue Nov 18 20:42:22 2008 From: igoyret at alcatel-lucent.com (Ignacio Goyret) Date: Tue, 18 Nov 2008 11:42:22 -0800 Subject: [Nagiosplug-devel] [PATCH] contrib/check_netapp.pl - strict warnings Message-ID: <200811181943.mAIJh9ji024380@cliff.eng.ascend.com> [to the correct mailing list now...] Hi all, This is a trivial patch to eliminate perl warnings when strict and warnings are enabled. Cheers, -Ignacio -------------- next part -------------- A non-text attachment was scrubbed... Name: plugins-svn-trunk-check_netapp.pl.u Type: application/octet-stream Size: 1223 bytes Desc: not available URL: From noreply at sourceforge.net Tue Nov 18 20:46:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Nov 2008 19:46:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-18 14:46 Message: Awww. IIRC I hands-calculated the SIZEOF_NTPCM formula and couldn't see anything wrong. I probably didn't realize the condition was the problem without even looking at it... 131 /* NTP control message header is 12 bytes, plus any data in the data 132 * field, plus null padding to the nearest 32-bit boundary per rfc. 133 */ Indeed, when the modulo is zero, 4-(ntohs(m.count)%4) returns 4, which adds 4 more bytes of "rounding" to the result ("m.count" is always true if count > 0)!! The correct define should probably be: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((ntohs(m.count)%4)?4-(ntohs(m.count)%4):0)) In other words, if there's no modulo use "0" instead of the formula. I'll get that fixed soon. I should probably learn how to use a debugger ;) Thanks Jamie for pointing it out, and Thierry for forwarding the post! ---------------------------------------------------------------------- Comment By: Thierry Carrez (tcarrez) Date: 2008-11-18 11:49 Message: A similar bug was filed on Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/291265 Here is the analysis of Jamie Strandboge about it: ------------------- I looked at this a bit, and the math seems to be wrong in this line: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((m.count)?4-(ntohs(m.count)%4):0)) In ntp_request we have (where MAX_CM_SIZE is defined as 468): req.count=htons(MAX_CM_SIZE); Which makes req.count = 54273. Later, we have: if(read(conn, &req, SIZEOF_NTPCM(req)) == -1) So the nbytes for read() ends up being: (12 + 468 + (4 - 0)) = 484 However, a sizeof(req) reveals that it is 480 bytes (this can also be seen by looking at the ntp_control_message struct (1+1+2+2+2+2+2+468)). This is not security relevant, because the 4 bytes that are overwritten end up being the 'conn' file descriptor (as seen from gdb), which triggers read() to: read(3, 0xbffff850, 484) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- resulting in check_ntp_peer to error out with: CRITICAL - Socket timeout after 10 seconds This is a bug whether or not _FORTIFY_SOURCE is used, because read() may SIGALRM. You'll also notice that check_ntp.c suffers from the same problem (the code in question is identical), as seen with: $ /usr/lib/nagios/plugins/check_ntp -H foo -j 1 ------------------ ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2008-09-12 22:20 Message: 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: Thomas Guyot (dermoth) Date: 2008-08-29 00:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 04:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From igoyret at alcatel-lucent.com Wed Nov 19 02:03:21 2008 From: igoyret at alcatel-lucent.com (Ignacio Goyret) Date: Tue, 18 Nov 2008 17:03:21 -0800 Subject: [Nagiosplug-devel] [PATCH] check_smtp.c - float warn/crit thresholds In-Reply-To: <200811181943.mAIJh9jk024380@cliff.eng.ascend.com> References: <200811181943.mAIJh9jk024380@cliff.eng.ascend.com> Message-ID: <200811190103.mAJ13LEm000546@cliff.eng.ascend.com> At 11:42 AM 11/18/2008 -0800, Ignacio Goyret wrote: >Hi all, >The attached patched allows check_smtp.c to accept double (floating >point) values for warning and critical thresholds. Previously, it >only accepted integers. > >Note that the help message (check_smtp -h) indicated that these >parameters were supposed to be DOUBLE so this change makes it >consistent. > >Cheers, >-Ignacio > >PS: The attached patch is svn-based. I found the issue on >nagios-plugins-1.4.13. Oops, I forgot to actually attach the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: plugins-svn-trunk-check_smtp.u Type: application/octet-stream Size: 1803 bytes Desc: not available URL: From noreply at sourceforge.net Wed Nov 19 07:01:14 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Nov 2008 06:01:14 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-18 14:46 Message: Awww. IIRC I hands-calculated the SIZEOF_NTPCM formula and couldn't see anything wrong. I probably didn't realize the condition was the problem without even looking at it... 131 /* NTP control message header is 12 bytes, plus any data in the data 132 * field, plus null padding to the nearest 32-bit boundary per rfc. 133 */ Indeed, when the modulo is zero, 4-(ntohs(m.count)%4) returns 4, which adds 4 more bytes of "rounding" to the result ("m.count" is always true if count > 0)!! The correct define should probably be: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((ntohs(m.count)%4)?4-(ntohs(m.count)%4):0)) In other words, if there's no modulo use "0" instead of the formula. I'll get that fixed soon. I should probably learn how to use a debugger ;) Thanks Jamie for pointing it out, and Thierry for forwarding the post! ---------------------------------------------------------------------- Comment By: Thierry Carrez (tcarrez) Date: 2008-11-18 11:49 Message: A similar bug was filed on Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/291265 Here is the analysis of Jamie Strandboge about it: ------------------- I looked at this a bit, and the math seems to be wrong in this line: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((m.count)?4-(ntohs(m.count)%4):0)) In ntp_request we have (where MAX_CM_SIZE is defined as 468): req.count=htons(MAX_CM_SIZE); Which makes req.count = 54273. Later, we have: if(read(conn, &req, SIZEOF_NTPCM(req)) == -1) So the nbytes for read() ends up being: (12 + 468 + (4 - 0)) = 484 However, a sizeof(req) reveals that it is 480 bytes (this can also be seen by looking at the ntp_control_message struct (1+1+2+2+2+2+2+468)). This is not security relevant, because the 4 bytes that are overwritten end up being the 'conn' file descriptor (as seen from gdb), which triggers read() to: read(3, 0xbffff850, 484) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- resulting in check_ntp_peer to error out with: CRITICAL - Socket timeout after 10 seconds This is a bug whether or not _FORTIFY_SOURCE is used, because read() may SIGALRM. You'll also notice that check_ntp.c suffers from the same problem (the code in question is identical), as seen with: $ /usr/lib/nagios/plugins/check_ntp -H foo -j 1 ------------------ ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2008-09-12 22:20 Message: 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: Thomas Guyot (dermoth) Date: 2008-08-29 00:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 04:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Wed Nov 19 07:02:04 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Nov 2008 06:02:04 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-18 14:46 Message: Awww. IIRC I hands-calculated the SIZEOF_NTPCM formula and couldn't see anything wrong. I probably didn't realize the condition was the problem without even looking at it... 131 /* NTP control message header is 12 bytes, plus any data in the data 132 * field, plus null padding to the nearest 32-bit boundary per rfc. 133 */ Indeed, when the modulo is zero, 4-(ntohs(m.count)%4) returns 4, which adds 4 more bytes of "rounding" to the result ("m.count" is always true if count > 0)!! The correct define should probably be: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((ntohs(m.count)%4)?4-(ntohs(m.count)%4):0)) In other words, if there's no modulo use "0" instead of the formula. I'll get that fixed soon. I should probably learn how to use a debugger ;) Thanks Jamie for pointing it out, and Thierry for forwarding the post! ---------------------------------------------------------------------- Comment By: Thierry Carrez (tcarrez) Date: 2008-11-18 11:49 Message: A similar bug was filed on Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/291265 Here is the analysis of Jamie Strandboge about it: ------------------- I looked at this a bit, and the math seems to be wrong in this line: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((m.count)?4-(ntohs(m.count)%4):0)) In ntp_request we have (where MAX_CM_SIZE is defined as 468): req.count=htons(MAX_CM_SIZE); Which makes req.count = 54273. Later, we have: if(read(conn, &req, SIZEOF_NTPCM(req)) == -1) So the nbytes for read() ends up being: (12 + 468 + (4 - 0)) = 484 However, a sizeof(req) reveals that it is 480 bytes (this can also be seen by looking at the ntp_control_message struct (1+1+2+2+2+2+2+468)). This is not security relevant, because the 4 bytes that are overwritten end up being the 'conn' file descriptor (as seen from gdb), which triggers read() to: read(3, 0xbffff850, 484) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- resulting in check_ntp_peer to error out with: CRITICAL - Socket timeout after 10 seconds This is a bug whether or not _FORTIFY_SOURCE is used, because read() may SIGALRM. You'll also notice that check_ntp.c suffers from the same problem (the code in question is identical), as seen with: $ /usr/lib/nagios/plugins/check_ntp -H foo -j 1 ------------------ ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2008-09-12 22:20 Message: 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: Thomas Guyot (dermoth) Date: 2008-08-29 00:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 04:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Wed Nov 19 07:02:36 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Nov 2008 06:02:36 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1999319 ] check_ntp_peer buffer overflow Message-ID: Bugs item #1999319, was opened at 2008-06-21 02:04 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heim (g_phreak) Assigned to: Thomas Guyot (dermoth) Summary: check_ntp_peer buffer overflow Initial Comment: check_ntp_peer v1991 (nagios-plugins 1.4.12) commandline: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 OS: SLES10 SP2 (i586) GCC: gcc-4.1.2_20070115-0.21 GLIBC: glibc-2.4-31.54 gdb backtrace: (gdb) file /usr/lib/nagios/plugins/check_ntp_peer Reading symbols from /usr/lib/nagios/plugins/check_ntp_peer...Reading symbols from /usr/lib/debug/usr/lib/nagios/plugins/check_ntp_peer.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. (gdb) set args -H ptbtime1.ptb.de -w 120 -c 240 (gdb) run Starting program: /usr/lib/nagios/plugins/check_ntp_peer -H ptbtime1.ptb.de -w 120 -c 240 *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xb7e89071] /lib/libc.so.6(__read_chk+0x50)[0xb7e89510] /usr/lib/nagios/plugins/check_ntp_peer[0x8049e9b] /usr/lib/nagios/plugins/check_ntp_peer[0x804a95e] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7dcc8ac] /usr/lib/nagios/plugins/check_ntp_peer[0x8048e71] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 rw-p 00006000 08:02 346900 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08071000 rw-p 08050000 00:00 0 [heap] b7d76000-b7d80000 r-xp 00000000 08:02 180638 /lib/libgcc_s.so.1 b7d80000-b7d81000 rw-p 00009000 08:02 180638 /lib/libgcc_s.so.1 b7d81000-b7db6000 r--s 00000000 08:02 383495 /var/run/nscd/dbMurBjs (deleted) b7db6000-b7db7000 rw-p b7db6000 00:00 0 b7db7000-b7edc000 r-xp 00000000 08:02 180596 /lib/libc-2.4.so b7edc000-b7ede000 r--p 00124000 08:02 180596 /lib/libc-2.4.so b7ede000-b7ee0000 rw-p 00126000 08:02 180596 /lib/libc-2.4.so b7ee0000-b7ee4000 rw-p b7ee0000 00:00 0 b7ee4000-b7ee6000 r-xp 00000000 08:02 180602 /lib/libdl-2.4.so b7ee6000-b7ee8000 rw-p 00001000 08:02 180602 /lib/libdl-2.4.so b7ee8000-b7f0b000 r-xp 00000000 08:02 180604 /lib/libm-2.4.so b7f0b000-b7f0d000 rw-p 00022000 08:02 180604 /lib/libm-2.4.so b7f0d000-b7f1c000 r-xp 00000000 08:02 180624 /lib/libresolv-2.4.so b7f1c000-b7f1e000 rw-p 0000e000 08:02 180624 /lib/libresolv-2.4.so b7f1e000-b7f20000 rw-p b7f1e000 00:00 0 b7f20000-b7f31000 r-xp 00000000 08:02 180607 /lib/libnsl-2.4.so b7f31000-b7f33000 rw-p 00010000 08:02 180607 /lib/libnsl-2.4.so b7f33000-b7f35000 rw-p b7f33000 00:00 0 b7f3e000-b7f3f000 rw-p b7f3e000 00:00 0 b7f3f000-b7f59000 r-xp 00000000 08:02 180589 /lib/ld-2.4.so b7f59000-b7f5b000 rw-p 0001a000 08:02 180589 /lib/ld-2.4.so bf962000-bf978000 rw-p bf962000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ddf8d0 in raise () from /lib/libc.so.6 #2 0xb7de0ff3 in abort () from /lib/libc.so.6 #3 0xb7e14f9b in __libc_message () from /lib/libc.so.6 #4 0xb7e89071 in __chk_fail () from /lib/libc.so.6 #5 0xb7e89510 in __read_chk () from /lib/libc.so.6 #6 0x08049e9b in ntp_request (host=0x8050130 "ptbtime1.ptb.de", offset=0xbf9745a0, offset_result=0xbf9745b4, jitter=0xbf974598, stratum=0xbf9745b0) at /usr/include/bits/unistd.h:34 #7 0x0804a95e in main (argc=7, argv=0xbf974664) at check_ntp_peer.c:572 #8 0xb7dcc8ac in __libc_start_main () from /lib/libc.so.6 #9 0x08048e71 in _start () Thanks a lot. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-19 01:02 Message: Fixed in r2086 (for both check_ntp and check_ntp_peer) ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-11-18 14:46 Message: Awww. IIRC I hands-calculated the SIZEOF_NTPCM formula and couldn't see anything wrong. I probably didn't realize the condition was the problem without even looking at it... 131 /* NTP control message header is 12 bytes, plus any data in the data 132 * field, plus null padding to the nearest 32-bit boundary per rfc. 133 */ Indeed, when the modulo is zero, 4-(ntohs(m.count)%4) returns 4, which adds 4 more bytes of "rounding" to the result ("m.count" is always true if count > 0)!! The correct define should probably be: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((ntohs(m.count)%4)?4-(ntohs(m.count)%4):0)) In other words, if there's no modulo use "0" instead of the formula. I'll get that fixed soon. I should probably learn how to use a debugger ;) Thanks Jamie for pointing it out, and Thierry for forwarding the post! ---------------------------------------------------------------------- Comment By: Thierry Carrez (tcarrez) Date: 2008-11-18 11:49 Message: A similar bug was filed on Ubuntu bugtracker: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/291265 Here is the analysis of Jamie Strandboge about it: ------------------- I looked at this a bit, and the math seems to be wrong in this line: #define SIZEOF_NTPCM(m) (12+ntohs(m.count)+((m.count)?4-(ntohs(m.count)%4):0)) In ntp_request we have (where MAX_CM_SIZE is defined as 468): req.count=htons(MAX_CM_SIZE); Which makes req.count = 54273. Later, we have: if(read(conn, &req, SIZEOF_NTPCM(req)) == -1) So the nbytes for read() ends up being: (12 + 468 + (4 - 0)) = 484 However, a sizeof(req) reveals that it is 480 bytes (this can also be seen by looking at the ntp_control_message struct (1+1+2+2+2+2+2+468)). This is not security relevant, because the 4 bytes that are overwritten end up being the 'conn' file descriptor (as seen from gdb), which triggers read() to: read(3, 0xbffff850, 484) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- resulting in check_ntp_peer to error out with: CRITICAL - Socket timeout after 10 seconds This is a bug whether or not _FORTIFY_SOURCE is used, because read() may SIGALRM. You'll also notice that check_ntp.c suffers from the same problem (the code in question is identical), as seen with: $ /usr/lib/nagios/plugins/check_ntp -H foo -j 1 ------------------ ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2008-09-12 22:20 Message: 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: Thomas Guyot (dermoth) Date: 2008-08-29 00:12 Message: Logged In: YES user_id=375623 Originator: NO Although I did reproduce the bug once I couldn't a few weeks later (library/compiler updates??). I couldn't either on a SLES test system kindly provided for testing. >From the backtrace, we're failing __read_chk (_FORTIFY_SOURCE for the read() call) in ntp_request. There's a single read() in it and I re-calculated everything by hand: the read data should no exceed allocated memory for req. This seems like a bug in the _FORTIFY_SOURCE checks. Marking as pending as I'm unable to move forward. ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-05 04:09 Message: Logged In: YES user_id=1404363 Originator: NO http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29 : CC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits. References: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-08-04 12:07 Message: Logged In: YES user_id=375623 Originator: NO Thanks for your feedback. I noticed this as well when the bug was reported but I haven't had time to debug it yet. I'm not sure that the number means, but it fails even with -D_FORTIFY_SOURCE. Any more info on this flag would be nice... ---------------------------------------------------------------------- Comment By: tuxlife (tuxlife) Date: 2008-08-04 10:53 Message: Logged In: YES user_id=1404363 Originator: NO I had the same problem with a self-RPM. The reason was following CFLAGS/CXXFLAGS/FFLAGS option: -D_FORTIFY_SOURCE=2 Without this option does the plugin work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1999319&group_id=29880 From noreply at sourceforge.net Wed Nov 19 23:28:05 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Nov 2008 22:28:05 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2315953 ] check_ping: timeouts when reverse name resolution times out Message-ID: Bugs item #2315953, was opened at 2008-11-19 22:28 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=2315953&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: Ton Voon (tonvoon) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping: timeouts when reverse name resolution times out Initial Comment: On a system where a reverse name resolution times out, two things appear to happen: 1) check_ping will sometimes fail with a popen error 2) check_ping will take a long time to run (1) is because, I think, there are is_host calls. These should be removed (check on mailing list first). Instead, the command should be run and any error captured and displayed. There's no point trying to validate the command - just pass to the command. (2) might occur because "time check_ping -c 1 {hostname}" just takes a long time due to this system. However, "check_ping -n -c 1 {hostname}" will return quickly. So, ./configure should try and use check_ping -n where possible. The best workaround: use check_icmp instead, which doesn't attempt to do these resolutions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2315953&group_id=29880 From dermoth at aei.ca Sun Nov 23 10:58:06 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 23 Nov 2008 04:58:06 -0500 Subject: [Nagiosplug-devel] Nagios-Plugins migrated to Git Message-ID: <4929292E.70206@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The Nagios Plugin team has been planning a migration to Git for some time now, and the final steps have just been completed this morning. You can access the new Git repositories at these URLs (Full history has been preserved): Nagios-plugins: http://repo.or.cz/w/nagiosplugins.git Nagios::Plugin Perl module: http://repo.or.cz/w/Nagios-Plugin.git Notification-MIB (Anyone using that anyway?): http://repo.or.cz/w/nagiosmib.git We'll keep pushing every commit to the Git master branch back to subversion trunk while we migrate our existing scripts and tinderbox; after that there's no promises on how long subversion will be left running and updated. We have put up a sort tutorial on how to use Git on nagiosplugins.org: http://nagiosplugins.org/node/88 - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKSku6dZ+Kt5BchYRAvOXAJ9Bfjfy9FReDl3xA0bXWK3FzeSetgCgvnHL XNArdEFEY80tklPsQt5O1y8= =EhXV -----END PGP SIGNATURE----- From noreply at sourceforge.net Mon Nov 24 03:20:26 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Nov 2008 02:20:26 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1868822 ] check_http link fails with openssl installed Message-ID: Bugs item #1868822, was opened at 2008-01-10 20:24 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&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: Dave van Nierop (ca28200) Assigned to: Ton Voon (tonvoon) Summary: check_http link fails with openssl installed Initial Comment: Compile and link of nagios-plugins-1.4.10 succeeds, but a compile and link of nagios-plugins-1.4.11 fails. Problem: All function references for np_net_ssl_* (included in netutils.h) in plugins/check_http.c are unresolved when the linker fires in. I tried to figure it out, but just didn't have the time. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-11-24 02:20 Message: 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: 2008-11-08 02:46 Message: Dave, Is this still a problem with the latest snapshot? http://nagiosplug.sf.net/snapshot If so, would you like to provide a tinderbox build server so we can see the error and you will know that it will continue to be fixed: http://tinderbox.opsera.com I'm marking the call into pending so this will autoclose if there are no updates. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1868822&group_id=29880 From hrpoliveira at gmail.com Mon Nov 24 20:38:21 2008 From: hrpoliveira at gmail.com (Helder Oliveira) Date: Mon, 24 Nov 2008 19:38:21 +0000 Subject: [Nagiosplug-devel] popen return code problem Message-ID: Hi guys, this is my first email here. I wonder if any of you have this problem in the past and maybe can help me. im creating a plugin in C that executes a wmic command in the background using open. My problem is that im getting some return code from wmic that nrpe gets before my real plugin return code. WHat are my changes before change all my code to another solution ? Helder From noreply at sourceforge.net Tue Nov 25 06:21:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Nov 2008 05:21:44 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2341696 ] check_fping: expose fping timeout option (-t) Message-ID: Patches item #2341696, was opened at 2008-11-25 16:21 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=2341696&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Foster (martin_foster) Assigned to: Nobody/Anonymous (nobody) Summary: check_fping: expose fping timeout option (-t) Initial Comment: This patch exposes the fping timeout (-t) option to check_fping. Necessary for checking hosts that are likely to have more than the default of 500msec RTT. Works in the same way as the timeout option for ping/check_ping. Attached patch applies to version 1.4.13 of the plugins, though we've maintained this patch at my site for years. Hopefully useful to the greater community. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2341696&group_id=29880 From noreply at sourceforge.net Tue Nov 25 14:32:08 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Nov 2008 13:32:08 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2343438 ] check_ifoperstatus.pl: fix for --authpass and --privpass Message-ID: Bugs item #2343438, was opened at 2008-11-25 14:32 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=2343438&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robin Schroeder (r_schroeder) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifoperstatus.pl: fix for --authpass and --privpass Initial Comment: When calling check_ifoperstatus or check_ifstatus with the following arguments, I get errors: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 UNKNOWN: Invalid argument '-authpass => XXXXXXXX' ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Missing arguments! check_ifoperstatus and check_ifstatus generate the "-authpass => ..." parameter in a way, Net::SNMP->session doesn't understand. check_ifstatus doesn't recognize "-L authPriv". The attached patch fixes all problems for me. Some details about my environment: Plugin Version (-V output): check_ifoperstatus v1642 (nagios-plugins 1.4.13) Plugin Version (-V output): check_ifstatus v884 (nagios-plugins 1.4.13) Plugin Name: check_ifoperstatus, check_ifstatus Plugin Commandline showing issues: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Operating System: Debian GNU/Linux etch (4.0) Architecture: i686 Compiler: perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.24.4, archname=i486-linux-gnu-thread-multi uname='linux ninsei 2.6.24.4 #1 smp preempt fri apr 18 15:36:09 pdt 2008 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-21)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8 gnulibc_version='2.3.6' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Apr 25 2008 20:23:05 @INC: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2343438&group_id=29880 From noreply at sourceforge.net Tue Nov 25 14:33:06 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Nov 2008 13:33:06 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2343438 ] SNMPv3 fixes for perl plugins Message-ID: Bugs item #2343438, was opened at 2008-11-25 14:32 Message generated for change (Settings changed) made by r_schroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2343438&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robin Schroeder (r_schroeder) Assigned to: Nobody/Anonymous (nobody) >Summary: SNMPv3 fixes for perl plugins Initial Comment: When calling check_ifoperstatus or check_ifstatus with the following arguments, I get errors: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 UNKNOWN: Invalid argument '-authpass => XXXXXXXX' ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Missing arguments! check_ifoperstatus and check_ifstatus generate the "-authpass => ..." parameter in a way, Net::SNMP->session doesn't understand. check_ifstatus doesn't recognize "-L authPriv". The attached patch fixes all problems for me. Some details about my environment: Plugin Version (-V output): check_ifoperstatus v1642 (nagios-plugins 1.4.13) Plugin Version (-V output): check_ifstatus v884 (nagios-plugins 1.4.13) Plugin Name: check_ifoperstatus, check_ifstatus Plugin Commandline showing issues: ./check_ifoperstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX -d eth0 ./check_ifstatus -v3 -H hostname -U user -L authPriv -a MD5 --privpass YYYYYYYY --authpass XXXXXXXX Operating System: Debian GNU/Linux etch (4.0) Architecture: i686 Compiler: perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.24.4, archname=i486-linux-gnu-thread-multi uname='linux ninsei 2.6.24.4 #1 smp preempt fri apr 18 15:36:09 pdt 2008 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-21)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8 gnulibc_version='2.3.6' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Apr 25 2008 20:23:05 @INC: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2343438&group_id=29880 From noreply at sourceforge.net Tue Nov 25 22:21:05 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Nov 2008 21:21:05 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2346176 ] Errors in check_ifstatus Message-ID: Bugs item #2346176, was opened at 2008-11-25 21:21 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=2346176&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: Matthew (the132nduserid) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in check_ifstatus Initial Comment: I believe that some of the check_ifstatus logic is not correct. I am attaching a file with the code I think is right. I hope this is the right way to submit bugs, and thanks for the plugins! [monitor/opt/nagios-3.0.5/libexec] ./check_ifstatus --version check_ifstatus v884 (nagios-plugins 1.4.13) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2346176&group_id=29880 From noreply at sourceforge.net Wed Nov 26 02:41:26 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Nov 2008 01:41:26 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2347686 ] check_fping: expose fping timeout option (-t) Message-ID: Patches item #2347686, was opened at 2008-11-26 12:41 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=2347686&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Foster (martin_foster) Assigned to: Nobody/Anonymous (nobody) Summary: check_fping: expose fping timeout option (-t) Initial Comment: This patch exposes the fping timeout (-t) option to check_fping. Necessary for checking hosts that are likely to have more than the default of 500msec RTT. Works in the same way as the timeout option for ping/check_ping. Attached patch applies to version 1.4.13 of the plugins, though we've maintained this patch at my site for years. Hopefully useful to the greater community. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2347686&group_id=29880 From mattias.ryrlen at op5.com Thu Nov 27 17:00:13 2008 From: mattias.ryrlen at op5.com (Mattias =?ISO-8859-1?Q?Ryrl=E9n?=) Date: Thu, 27 Nov 2008 17:00:13 +0100 Subject: [Nagiosplug-devel] NagiosPlugin.vbs new framework Message-ID: <1227801613.24177.41.camel@mr-laptop> Hello, I have built a framework to be used with vbscript files and nagios. this is in early stage but it almost works as i would expect it (similar as Nagios::Plugin for perl) you can see the information about it on http://git.op5.org/git/?p=nagios/vbs-plugins.git;a=summary to just download/view the files click "tree" then "raw" on NagiosPlugin.vbs and check_test.vbs for example. you can use git to check-out the whole project with the following command: git clone git://git.op5.org/nagios/vbs-plugins.git Feedback can be sent to list or direct to me :) Example: ' Define what args that should be used np.add_arg "host", "Hostaddress", 1 np.add_arg "warning", "warning threshold", 0 np.add_arg "critical", "critical threshold", 0 np.add_arg "community", "SNMP Community", 1 np.add_arg "variable", "Variable to check, eg CPU", 1 ' If we have no args or arglist contains /help or not all of the required arguments are fulfilled show the usage output,. If Args.Count < 1 Or Args.Exists("help") Or np.parse_args = 0 Then np.Usage End If ' If we define /warning /critical on commandline it should override the script default. If Args.Exists("warning") Then threshold_warning = Args("warning") If Args.Exists("critical") Then threshold_critical = Args("critical") np.set_thresholds threshold_warning, threshold_critical ' Set the msg output to be used (OK/WARNING/CRITICAL/UNKNOWN will be applied automaticly) return_code = np.check_threshold(Args("variable")) msg = "Testing " & Args.Item("host") & " " & np.get_threshold("warning") & " " & np.get_threshold("critical") ' Nice Exit with msg and exitcode np.nagios_exit msg, return_code -- V?nliga h?lsningar / Best Regards Mattias Ryrl?n __________________________ op5 AB F?rsta L?nggatan 19 SE-413 27 G?teborg Mobil: +46 735-17 70 99 Support: +46 31-774 09 24 www.op5.com