From flo at bier.homeip.net Mon Jan 1 01:07:56 2007 From: flo at bier.homeip.net (Florian Gleixner) Date: Mon, 01 Jan 2007 01:07:56 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <458AD7D0.1090902@nagios.org> References: <458AD7D0.1090902@nagios.org> Message-ID: <459850DC.4050606@bier.homeip.net> Hi, is there or is it planned to support some time plugins that are compiled as dynamic libraries and can be loaded with dlopen()? The embedded perl is very nice and makes plugin development fast, but a C/C++ api with dynamically loaded plugins could make nagios much faster. Flo Ethan Galstad wrote: > Hi Everyone - > > One of the things that Nagios 3 will support is the ability to use the > embedded Perl interpreter for specific perl plugins only, instead of all > or nothing. The Nagios 3 development code currently support the > following... > > Line 2 of a Perl plugin may start with one of the following: > > #USE_EPN > > -or- > > #NO_EPN > > If the #USE_EPN statement is found, Nagios will use the embedded Perl > interpreter to run the plugin. If #NO_EPN is found, it will not be used > (even if epn is compiled in and enabled in the Nagios daemon). If > neither directive is found, Nagios will default to the behavior > specified by a new 'use_embedded_perl_implicitly' variable in the main > Nagios config file. > > Plugin devs - would you prefer different statements other than #USE_EPN > / #NO_EPN, or are they okay? Any other comments or suggestions? > > > Ethan Galstad, > Nagios Developer > --- > Email: nagios at nagios.org > Website: http://www.nagios.org > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 Mon Jan 1 16:43:55 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 01 Jan 2007 10:43:55 -0500 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459850DC.4050606@bier.homeip.net> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> Message-ID: <45992C3B.1000609@aei.ca> If I understand it correctly, it could also make Nagios crash and leak memory much more easily. C plugins are very fast already and can behave pretty badly without affecting the main process. What performance gain could we expect going from C to dynamically loaded plugins? Thomas On 31/12/06 07:07 PM, Florian Gleixner wrote: > Hi, > > is there or is it planned to support some time plugins that are compiled > as dynamic libraries and can be loaded with dlopen()? > The embedded perl is very nice and makes plugin development fast, but a > C/C++ api with dynamically loaded plugins could make nagios much faster. > > Flo > > Ethan Galstad wrote: >> Hi Everyone - >> >> One of the things that Nagios 3 will support is the ability to use the >> embedded Perl interpreter for specific perl plugins only, instead of all >> or nothing. The Nagios 3 development code currently support the >> following... >> >> Line 2 of a Perl plugin may start with one of the following: >> >> #USE_EPN >> >> -or- >> >> #NO_EPN >> >> If the #USE_EPN statement is found, Nagios will use the embedded Perl >> interpreter to run the plugin. If #NO_EPN is found, it will not be used >> (even if epn is compiled in and enabled in the Nagios daemon). If >> neither directive is found, Nagios will default to the behavior >> specified by a new 'use_embedded_perl_implicitly' variable in the main >> Nagios config file. >> >> Plugin devs - would you prefer different statements other than #USE_EPN >> / #NO_EPN, or are they okay? Any other comments or suggestions? >> >> >> Ethan Galstad, >> Nagios Developer >> --- >> Email: nagios at nagios.org >> Website: http://www.nagios.org >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________________ >> 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 >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > 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 flo at bier.homeip.net Tue Jan 2 00:14:22 2007 From: flo at bier.homeip.net (Florian Gleixner) Date: Tue, 02 Jan 2007 00:14:22 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45992C3B.1000609@aei.ca> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> Message-ID: <459995CE.6070008@bier.homeip.net> True, leaks and crashes could make nagios more unstable. dl-plugins should be used with care. "Worker threads" could isolate some of the risk. The performance gain is simply the time a C plugin needs to create a process. You could say, that this is not very much time, but some nagios setups make thousands of checks per minute. Here is a very simple test: The bash has the echo command build in. On most linux systems you will find a /bin/echo program with same functionality too. So compare: time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done real 0m1.536s user 0m0.172s sys 0m0.020s time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done real 0m34.047s user 0m8.761s sys 0m15.365s I think some default plugins like ping or tcp-check could be made as dl module, the more complicated or the plugins that are usually executed at the monitored nodes should be "normal" plugins. I never had a look at the nagios code, it was just a idea popping up. Flo Thomas Guyot-Sionnest wrote: > If I understand it correctly, it could also make Nagios crash and leak > memory much more easily. > > C plugins are very fast already and can behave pretty badly without > affecting the main process. What performance gain could we expect going > from C to dynamically loaded plugins? > > Thomas > > On 31/12/06 07:07 PM, Florian Gleixner wrote: >> Hi, >> >> is there or is it planned to support some time plugins that are compiled >> as dynamic libraries and can be loaded with dlopen()? >> The embedded perl is very nice and makes plugin development fast, but a >> C/C++ api with dynamically loaded plugins could make nagios much faster. >> >> Flo >> >> Ethan Galstad wrote: >>> Hi Everyone - >>> >>> One of the things that Nagios 3 will support is the ability to use the >>> embedded Perl interpreter for specific perl plugins only, instead of all >>> or nothing. The Nagios 3 development code currently support the >>> following... >>> >>> Line 2 of a Perl plugin may start with one of the following: >>> >>> #USE_EPN >>> >>> -or- >>> >>> #NO_EPN >>> >>> If the #USE_EPN statement is found, Nagios will use the embedded Perl >>> interpreter to run the plugin. If #NO_EPN is found, it will not be used >>> (even if epn is compiled in and enabled in the Nagios daemon). If >>> neither directive is found, Nagios will default to the behavior >>> specified by a new 'use_embedded_perl_implicitly' variable in the main >>> Nagios config file. >>> >>> Plugin devs - would you prefer different statements other than #USE_EPN >>> / #NO_EPN, or are they okay? Any other comments or suggestions? >>> >>> >>> Ethan Galstad, >>> Nagios Developer >>> --- >>> Email: nagios at nagios.org >>> Website: http://www.nagios.org >>> From g.vickers at qut.edu.au Wed Jan 3 06:27:58 2007 From: g.vickers at qut.edu.au (Greg Vickers) Date: Wed, 03 Jan 2007 15:27:58 +1000 Subject: [Nagiosplug-devel] HDD temperature plugin? Message-ID: <459B3EDE.3080601@qut.edu.au> Hi all, I'm going to write a plugin (probably perl, and put it up on nagiosexchange.org) to check HDD temperature for Nagios using the hddtemp program. I just wanted to check that it hasn't been done or that I am replicating someone else's work? Thanks, -- Greg Vickers IT Security Engineer & Project Manager IT Security, Network Services, Information Technology Services Queensland University of Technology L12, 126 Margaret St, Brisbane Phone: +61 7 3138 9536 Mobile: 0410 434 734 Fax: +61 7 3138 2921 Email: g.vickers at qut.edu.au IT Security web site: http://www.its.qut.edu.au/itsecurity/ CRICOS No. 00213J From noreply at sourceforge.net Wed Jan 3 10:50:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 03 Jan 2007 01:50:53 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: Bugs item #1614164, was opened at 2006-12-12 17:38 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&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: alexus (a1exus) >Assigned to: Ton Voon (tonvoon) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-01-03 09:50 Message: Logged In: YES user_id=664364 Originator: NO Alexus, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot? There has been a fix to the generation of alloca.h. Ton ---------------------------------------------------------------------- Comment By: alexus (a1exus) Date: 2006-12-26 15:13 Message: Logged In: YES user_id=227889 Originator: YES this is what i did for "work-around" alexus at d:/usr/local/src/nagios-plugins-1.4.5> cd lib alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ls -la alloca.h lrwxr-xr-x 1 root wheel 34 Dec 12 22:39 alloca.h -> /usr/src/gnu/usr.bin/sort/alloca.h alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ---------------------------------------------------------------------- Comment By: David (daspez) Date: 2006-12-26 08:13 Message: Logged In: YES user_id=1676837 Originator: NO Try compiling using the "--without-included-regex" parameter. I have had the same issue under FreeBSD 5.5 and it compiles using the above paramter. HIH. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From ae at op5.se Wed Jan 3 11:24:54 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 03 Jan 2007 11:24:54 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45915270.6000807@nagios.org> References: <458AD7D0.1090902@nagios.org> <20061221191058.GA12311@eric.schwarzvogel.de> <20061221223901.GB22917@openfusion.com.au> <458B1B3D.4000103@nagios.org> <26CE556D-8C1C-4F0D-B3F5-BFD4DE387023@altinity.com> <45915270.6000807@nagios.org> Message-ID: <459B8476.5060802@op5.se> Ethan Galstad wrote: > Ton Voon wrote: >> On 21 Dec 2006, at 23:39, Ethan Galstad wrote: >> >>> I like Tobias' suggestion as well. >>> >>> As far as flexible location, that could be arranged. Limiting its >>> location the the beginning X lines of the plugin would be far easier >>> that figuring out how many lines the plugin has and working backwards. >>> In order to reduce overhead/increase speed of detection the keywords, I >>> would suggest we limit the possible location to the first 100 lines or >>> less. >>> >>> Ton, Benoit, others... does this sound okay? >> Sorry, I've stayed quiet on this because I don't use epn, so don't >> necessarily understand the issues. I know Gavin Carr uses epn, but I'm >> not sure who else currently on the plugin team. >> >> My British penny (just less than two cents) says: vim style comments; >> limit macro to first 10 lines. Maybe you could cache the plugin name >> (keyed on file location?) so that you don't need to keep re-reading the >> plugin? >> >> Ton > > Okay, CVS code now supports the following two incantations in the > 2nd-10th lines of Perl plugins: > > # nagios:+epn > > # nagios:-epn > > > Its probably better to cache the plugin directives as you mentioned, so > I'll take a look at doing that. Although I can see it would be useful > to allow people to tweak plugin directives without having to restart Nagios. > Definitely. I'd say you'd be better off saving yourself the trouble of exception handling and hashed caches by simply doing the check every time the plugin is run. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Wed Jan 3 11:27:28 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 03 Jan 2007 11:27:28 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459995CE.6070008@bier.homeip.net> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> Message-ID: <459B8510.7010803@op5.se> Florian Gleixner wrote: > True, leaks and crashes could make nagios more unstable. dl-plugins > should be used with care. "Worker threads" could isolate some of the risk. > > The performance gain is simply the time a C plugin needs to create a > process. You could say, that this is not very much time, but some nagios > setups make thousands of checks per minute. Here is a very simple test: > The bash has the echo command build in. On most linux systems you will > find a /bin/echo program with same functionality too. So compare: > > time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done > real 0m1.536s > user 0m0.172s > sys 0m0.020s > > time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done > real 0m34.047s > user 0m8.761s > sys 0m15.365s > > I think some default plugins like ping or tcp-check could be made as dl > module, the more complicated or the plugins that are usually executed at > the monitored nodes should be "normal" plugins. > > I never had a look at the nagios code, it was just a idea popping up. > A lower hanging apple is to make Nagios use fork() / execve() instead of using popen(), which does a double fork() / exec() thing. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From flo at bier.homeip.net Wed Jan 3 14:34:32 2007 From: flo at bier.homeip.net (Florian Gleixner) Date: Wed, 03 Jan 2007 14:34:32 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459B8510.7010803@op5.se> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> Message-ID: <459BB0E8.9050304@bier.homeip.net> Andreas Ericsson wrote: > Florian Gleixner wrote: >> True, leaks and crashes could make nagios more unstable. dl-plugins >> should be used with care. "Worker threads" could isolate some of the risk. >> >> The performance gain is simply the time a C plugin needs to create a >> process. You could say, that this is not very much time, but some nagios >> setups make thousands of checks per minute. Here is a very simple test: >> The bash has the echo command build in. On most linux systems you will >> find a /bin/echo program with same functionality too. So compare: >> >> time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done >> real 0m1.536s >> user 0m0.172s >> sys 0m0.020s >> >> time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done >> real 0m34.047s >> user 0m8.761s >> sys 0m15.365s >> >> I think some default plugins like ping or tcp-check could be made as dl >> module, the more complicated or the plugins that are usually executed at >> the monitored nodes should be "normal" plugins. >> >> I never had a look at the nagios code, it was just a idea popping up. >> > > A lower hanging apple is to make Nagios use fork() / execve() instead of > using popen(), which does a double fork() / exec() thing. > or use the popen() call from popen.{h,c} from the nagios plugins. The nagios plugins also call external programs via this call. So at the moment one plugin check usually creates a shell process, the plugin executable process and if the plugin creates a process we have three process created for one simple ping. Ideally a dynamically loaded plugin, that does not call external programs but has the code of for example "ping" complied in, does not create a single process. From gavin at openfusion.com.au Thu Jan 4 02:04:56 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 4 Jan 2007 12:04:56 +1100 Subject: [Nagiosplug-devel] HDD temperature plugin? In-Reply-To: <459B3EDE.3080601@qut.edu.au> References: <459B3EDE.3080601@qut.edu.au> Message-ID: <20070104010456.GA12049@openfusion.com.au> On Wed, Jan 03, 2007 at 03:27:58PM +1000, Greg Vickers wrote: > I'm going to write a plugin (probably perl, and put it up on > nagiosexchange.org) to check HDD temperature for Nagios using the > hddtemp program. I just wanted to check that it hasn't been done or that > I am replicating someone else's work? That sounds good - I'm not aware of an hddtemp plugin at least. Please if you do go with a perl plugin consider using the shiny new Nagios::Plugin modules on CPAN. They should make the non-interesting plugin parts much simpler, and we'd value any feedback you might have as a new user. Thanks, Gavin From g.vickers at qut.edu.au Thu Jan 4 03:05:04 2007 From: g.vickers at qut.edu.au (Greg Vickers) Date: Thu, 04 Jan 2007 12:05:04 +1000 Subject: [Nagiosplug-devel] HDD temperature plugin? In-Reply-To: <20070104010456.GA12049@openfusion.com.au> References: <459B3EDE.3080601@qut.edu.au> <20070104010456.GA12049@openfusion.com.au> Message-ID: <459C60D0.80905@qut.edu.au> Hi, Gavin Carr wrote: > On Wed, Jan 03, 2007 at 03:27:58PM +1000, Greg Vickers wrote: >> I'm going to write a plugin (probably perl, and put it up on >> nagiosexchange.org) to check HDD temperature for Nagios using the >> hddtemp program. I just wanted to check that it hasn't been done or that >> I am replicating someone else's work? > > That sounds good - I'm not aware of an hddtemp plugin at least. > > Please if you do go with a perl plugin consider using the shiny new > Nagios::Plugin modules on CPAN. They should make the non-interesting > plugin parts much simpler, and we'd value any feedback you might have > as a new user. Thanks for the tip Gavin, that'll make the job a lot easier! Once it is developed I'll post it for feedback. Thanks, -- Greg Vickers IT Security Engineer & Project Manager IT Security, Network Services, Information Technology Services Queensland University of Technology L12, 126 Margaret St, Brisbane Phone: +61 7 3138 9536 Mobile: 0410 434 734 Fax: +61 7 3138 2921 Email: g.vickers at qut.edu.au IT Security web site: http://www.its.qut.edu.au/itsecurity/ CRICOS No. 00213J From ae at op5.se Thu Jan 4 11:06:52 2007 From: ae at op5.se (Andreas Ericsson) Date: Thu, 04 Jan 2007 11:06:52 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459BB0E8.9050304@bier.homeip.net> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> <459BB0E8.9050304@bier.homeip.net> Message-ID: <459CD1BC.9000105@op5.se> Florian Gleixner wrote: > Andreas Ericsson wrote: >> Florian Gleixner wrote: >>> True, leaks and crashes could make nagios more unstable. dl-plugins >>> should be used with care. "Worker threads" could isolate some of the risk. >>> >>> The performance gain is simply the time a C plugin needs to create a >>> process. You could say, that this is not very much time, but some nagios >>> setups make thousands of checks per minute. Here is a very simple test: >>> The bash has the echo command build in. On most linux systems you will >>> find a /bin/echo program with same functionality too. So compare: >>> >>> time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done >>> real 0m1.536s >>> user 0m0.172s >>> sys 0m0.020s >>> >>> time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done >>> real 0m34.047s >>> user 0m8.761s >>> sys 0m15.365s >>> >>> I think some default plugins like ping or tcp-check could be made as dl >>> module, the more complicated or the plugins that are usually executed at >>> the monitored nodes should be "normal" plugins. >>> >>> I never had a look at the nagios code, it was just a idea popping up. >>> >> A lower hanging apple is to make Nagios use fork() / execve() instead of >> using popen(), which does a double fork() / exec() thing. >> > > or use the popen() call from popen.{h,c} from the nagios plugins. That doesn't leave room for passing the environment though, which will break a very valuable feature in Nagios atm. Btw, popen.[hc] have been replaced by runcmd.[hc]. How old a version are you running? > The nagios plugins also call external programs via this call. So at the > moment one plugin check usually creates a shell process, the plugin > executable process and if the plugin creates a process we have three > process created for one simple ping. No, there is the fork()/execve() in nagios (done through popen(3)) which spawns a shell. Then there's the fork()/execve() in the shell, and finally the plugin is run, so it's always three processes per plugin invocation. If the plugin spawns fe /bin/ps or /bin/df we have four processes for one plugin. > Ideally a dynamically loaded plugin, that does not call external > programs but has the code of for example "ping" complied in, does not > create a single process. > This is a Bad Idea beacuse the core program can't block on read()'s, which means all plugins that work over the network will have their timing values skewed unless you run each check in a separate thread or fork() a new nagios daemon for each check to run dynamically, in which case you've already lost 90% of the gain and ended up with a wicked burden of maintainability. That's without considering the initial cost (in developer time) to rewrite all plugins to never use signals[1] (or alarm(3)), which will be huge. Also, for PING checks you're opening a new can of worms, since implementing the ICMP protocol generally requires access to raw sockets, which is, on almost all systems, restricted to the super-user. It's possible to work around this by obtaining one[2] raw socket prior to dropping the root privileges at startup, but then you'd be up for a fairly complex ping program that needs to keep track of all the hosts that currently has echo requests pending and assign each response to the right check. [1] All module-based checks would want to catch the same signals, so the signal-handlers would be overwritten. alarm(3) is sometimes implemented through signals, so that's not usable. [2] Obtaining one socket per ping-check at start-up and keeping them is not feasible, since most systems normally only allow 1024 file-descriptors / process. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Thu Jan 4 12:37:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Jan 2007 03:37:16 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1592605 ] check_ping times out Message-ID: Bugs item #1592605, was opened at 2006-11-08 07:32 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592605&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Stewart (thomasdstewart) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping times out Initial Comment: Hi, I have noticed a minor time-out bug in check_ping. The plug-in returns "CRITICAL - Plugin timed out after 10 seconds" if it is trying to ping a host on a different network. I have used 4 IPs in my example, a host that is on my network and is up (192.168.0.1), a host that it on my network but is down (192.168.0.10), a host that it not on my network and is up (192.168.1.1) and a host that is not on my network but is down (10 192.168.1.10). Firstly I pinged each host in turn. See the Ping Commands[1]. I got 0% loss on the hosts that are up. For the down host that is on my network I got "Destination Host Unreachable". For the down host that was not on my network I received nothing. Next I manually ran the check_ping command for each host. See the Original check_ping[2]. As expected the up hosts and host on my network are fine, the plug-in returns OK and "Host Unreachable". The problem is the host that is down and not on my network, the plug-in returns "CRITICAL - Plugin timed out after 10 seconds". When really it should return some sort of "CRITICAL PING 100% packet loss" error, i.e. there is a ping issue, not an issue with the plug-in. On a very quick inspection, if the plug-in has a 10 second time-out then it also sets the pings time-out to 10. Which means that it never quite lets ping finish in time, i.e. if the ping does not receive a icmp unreachable its killed before the pings time-out is reached. I changed the time-out for check_ping to be the timeout + 1, then it seems to behave itself better. See the Modified check_ping[2]. Where the plug-in now correctly returns "PING CRITICAL - Packet loss = 100%". --- nagios-plugins-HEAD-200611080052/plugins/check_ping.c 2006-11-08 11:07:47.000000000 +0000 +++ nagios-plugins-HEAD-200611080052/plugins/check_ping.c.orig 2006-11-08 11:07:36.000000000 +0000 @@ -104,7 +104,7 @@ } /* handle timeouts gracefully */ - alarm (timeout_interval + 1); + alarm (timeout_interval); for (i = 0 ; i < n_addresses ; i++) { [1] Ping Commands $ ping -n -c 1 -w 10 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.559 ms --- 192.168.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.559/0.559/0.559/0.000 ms $ ping -n -c 1 -w 10 192.168.0.10 PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data. >From 192.168.0.206 icmp_seq=1 Destination Host Unreachable >From 192.168.0.206 icmp_seq=2 Destination Host Unreachable >From 192.168.0.206 icmp_seq=3 Destination Host Unreachable --- 192.168.0.10 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2010ms , pipe 3 $ ping -n -c 1 -w 10 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.514 ms --- 192.168.1.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.514/0.514/0.514/0.000 ms $ ping -n -c 1 -w 10 192.168.1.10 PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data. --- 192.168.1.10 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9009ms [2] Original check_ping $ ./check_ping -H 192.168.0.1 -w 5000,100% -c 5000,100% -p 1 PING OK - Packet loss = 0%, RTA = 0.54 ms $ ./check_ping -H 192.168.0.10 -w 5000,100% -c 5000,100% -p 1 CRITICAL - Host Unreachable (192.168.0.10) $ ./check_ping -H 192.168.1.1 -w 5000,100% -c 5000,100% -p 1 PING OK - Packet loss = 0%, RTA = 0.70 ms $ ./check_ping -H 192.168.1.10 -w 5000,100% -c 5000,100% -p 1 CRITICAL - Plugin timed out after 10 seconds [3]Modified check_ping $ ./check_ping -H 192.168.0.1 -w 5000,100% -c 5000,100% -p 1 PING OK - Packet loss = 0%, RTA = 0.56 ms $ ./check_ping -H 192.168.0.10 -w 5000,100% -c 5000,100% -p 1 CRITICAL - Host Unreachable (192.168.0.10) $ ./check_ping -H 192.168.1.1 -w 5000,100% -c 5000,100% -p 1 PING OK - Packet loss = 0%, RTA = 0.55 ms $ ./check_ping -H 192.168.1.10 -w 5000,100% -c 5000,100% -p 1 PING CRITICAL - Packet loss = 100% Regards -- Tom ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-04 06:37 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592605&group_id=29880 From noreply at sourceforge.net Thu Jan 4 12:51:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Jan 2007 03:51:17 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1574863 ] check_real does not accept the '-v' option Message-ID: Bugs item #1574863, was opened at 2006-10-10 18:28 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1574863&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: CVS >Status: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: check_real does not accept the '-v' option Initial Comment: The help message for check_real says that '-v' is a valid option, but it is not recognized by the plugin: $ plugins/check_real -h | grep -A 1 -- '-v,' -v, --verbose Show details for command-line debugging (Nagios may truncate output) $ plugins/check_real -v plugins/check_real: invalid option -- v check_real: Unknown argument - (null) Usage:check_real -H host [-e expect] [-p port] [-w warn] [-c crit] [-t timeout] [-v] Attached is a patch against CVS to recognize the '-v' option. Chris ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-04 06:51 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1574863&group_id=29880 From flo at bier.homeip.net Thu Jan 4 13:07:50 2007 From: flo at bier.homeip.net (Florian Gleixner) Date: Thu, 04 Jan 2007 13:07:50 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459CD1BC.9000105@op5.se> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> <459BB0E8.9050304@bier.homeip.net> <459CD1BC.9000105@op5.se> Message-ID: <459CEE16.8030304@bier.homeip.net> Andreas Ericsson wrote: > Florian Gleixner wrote: >> Andreas Ericsson wrote: >>> Florian Gleixner wrote: >>>> True, leaks and crashes could make nagios more unstable. dl-plugins >>>> should be used with care. "Worker threads" could isolate some of the risk. >>>> >>>> The performance gain is simply the time a C plugin needs to create a >>>> process. You could say, that this is not very much time, but some nagios >>>> setups make thousands of checks per minute. Here is a very simple test: >>>> The bash has the echo command build in. On most linux systems you will >>>> find a /bin/echo program with same functionality too. So compare: >>>> >>>> time for ((i=0 ; i< 10000 ; i++)) ; do echo bla ; done >>>> real 0m1.536s >>>> user 0m0.172s >>>> sys 0m0.020s >>>> >>>> time for ((i=0 ; i< 10000 ; i++)) ; do /bin/echo bla ; done >>>> real 0m34.047s >>>> user 0m8.761s >>>> sys 0m15.365s >>>> >>>> I think some default plugins like ping or tcp-check could be made as dl >>>> module, the more complicated or the plugins that are usually executed at >>>> the monitored nodes should be "normal" plugins. >>>> >>>> I never had a look at the nagios code, it was just a idea popping up. >>>> >>> A lower hanging apple is to make Nagios use fork() / execve() instead of >>> using popen(), which does a double fork() / exec() thing. >>> >> or use the popen() call from popen.{h,c} from the nagios plugins. > > > That doesn't leave room for passing the environment though, which will > break a very valuable feature in Nagios atm. Btw, popen.[hc] have been > replaced by runcmd.[hc]. How old a version are you running? > 1.4.5 has some spopen calls in check_fping.c check_hpjd.c check_load.c check_ping.c check_procs.c check_snmp.c check_swap.c and check_users.c. > >> The nagios plugins also call external programs via this call. So at the >> moment one plugin check usually creates a shell process, the plugin >> executable process and if the plugin creates a process we have three >> process created for one simple ping. > > No, there is the fork()/execve() in nagios (done through popen(3)) which > spawns a shell. Then there's the fork()/execve() in the shell, and > finally the plugin is run, so it's always three processes per plugin > invocation. If the plugin spawns fe /bin/ps or /bin/df we have four > processes for one plugin. > >> Ideally a dynamically loaded plugin, that does not call external >> programs but has the code of for example "ping" complied in, does not >> create a single process. >> > > This is a Bad Idea beacuse the core program can't block on read()'s, > which means all plugins that work over the network will have their > timing values skewed unless you run each check in a separate thread or > fork() a new nagios daemon for each check to run dynamically, in which > case you've already lost 90% of the gain and ended up with a wicked > burden of maintainability. That's without considering the initial cost > (in developer time) to rewrite all plugins to never use signals[1] (or > alarm(3)), which will be huge. True. But i think a threaded approach could give a huge performance boost. Aren't alarms mostly used to timeout a external call? But true: it would cost very much initially to rewrite that all. I think nobody wants to do that without a need. > > Also, for PING checks you're opening a new can of worms, since > implementing the ICMP protocol generally requires access to raw sockets, > which is, on almost all systems, restricted to the super-user. It's > possible to work around this by obtaining one[2] raw socket prior to > dropping the root privileges at startup, but then you'd be up for a > fairly complex ping program that needs to keep track of all the hosts > that currently has echo requests pending and assign each response to the > right check. > Got me. Yes. ICMP is a problem. > > [1] All module-based checks would want to catch the same signals, so the > signal-handlers would be overwritten. alarm(3) is sometimes implemented > through signals, so that's not usable. > > [2] Obtaining one socket per ping-check at start-up and keeping them is > not feasible, since most systems normally only allow 1024 > file-descriptors / process. > From noreply at sourceforge.net Thu Jan 4 15:26:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Jan 2007 06:26:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1455619 ] check_procs segfaults with zombies Message-ID: Patches item #1455619, was opened at 2006-03-21 21:03 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1455619&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: gerhard lausser (lausser) Assigned to: Ton Voon (tonvoon) Summary: check_procs segfaults with zombies Initial Comment: Hi, under solaris, ps produces output like this for zombie processes: Z 55618 28898 15263 0 0 0.0 The statement cols = sscanf (input_line, PS_FORMAT, PS_VARLIST); which is actually this one: ...sscanf (input_line, "%s %d %d %d %d %d %f %s%n", procstat,&procuid,&procpid,&procpid,&procvsz,&procrss, &procpcpu,procprog,&pos); does not fill the pos variable with a value because there is no match for the last %s. pos keeps the value it got when the last time a non-zombie process was found. pos points to the arguments following procprog which is senseless in this case anyway. but later it is used to initialize the procargs array. asprintf (&procargs, "%s", input_line + pos); In the case of a zombie pos has a value related to the last input_line but not the current one, so an illegal byte beyond the strings end may be accessed. I made a patch which takes this into account. Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: gerhard lausser (lausser) Date: 2007-01-04 15:26 Message: Logged In: YES user_id=613416 Originator: YES Sorry for the "delay". The same problems with zombies killing check_procs occurred under 1.4.5. The patch is identical to the one i submitted nearly a year ago for 1.4.2. Again, it solves the issue. File Added: check_procs.c-1.4.5-zombies-patch ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-04-06 04:20 Message: Logged In: YES user_id=1312539 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: 2006-03-22 14:15 Message: Logged In: YES user_id=664364 Gerhard, Thanks for the patch. For the upcoming 1.4.3 release, Solaris processes will be read differently. A new executable, pst, will be created which will return the equivalent ps output. Please can you try this and see if it fixes your zombie issues. If not, I'll be happy to accept a patch against that. Please try the snapshot at http://nagiosplug.sourceforge.net/snapshot/ Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1455619&group_id=29880 From ae at op5.se Thu Jan 4 17:08:53 2007 From: ae at op5.se (Andreas Ericsson) Date: Thu, 04 Jan 2007 17:08:53 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459CEE16.8030304@bier.homeip.net> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> <459BB0E8.9050304@bier.homeip.net> <459CD1BC.9000105@op5.se> <459CEE16.8030304@bier.homeip.net> Message-ID: <459D2695.5060702@op5.se> Florian Gleixner wrote: > Andreas Ericsson wrote: >> >> That doesn't leave room for passing the environment though, which will >> break a very valuable feature in Nagios atm. Btw, popen.[hc] have been >> replaced by runcmd.[hc]. How old a version are you running? >> > > 1.4.5 has some spopen calls in check_fping.c check_hpjd.c check_load.c > check_ping.c check_procs.c check_snmp.c check_swap.c and check_users.c. > Ah, righto. I don't use the official version myself and I've hacked those instances away in our version. >> >>> Ideally a dynamically loaded plugin, that does not call external >>> programs but has the code of for example "ping" complied in, does not >>> create a single process. >>> >> This is a Bad Idea beacuse the core program can't block on read()'s, >> which means all plugins that work over the network will have their >> timing values skewed unless you run each check in a separate thread or >> fork() a new nagios daemon for each check to run dynamically, in which >> case you've already lost 90% of the gain and ended up with a wicked >> burden of maintainability. That's without considering the initial cost >> (in developer time) to rewrite all plugins to never use signals[1] (or >> alarm(3)), which will be huge. > > True. But i think a threaded approach could give a huge performance > boost. Aren't alarms mostly used to timeout a external call? Yes and no. They're also used to timeout socket reads and whatnot. This isn't a *big* problem, because it's easy to make the plugins read (even from external applications) in non-blocking mode and poll() the descriptors for input. > But true: it would cost very much initially to rewrite that all. I think > nobody wants to do that without a need. > Yes. It all piles up rather quickly. To be honest, I like the fact that plugins are external programs. Mainly because it allows fast and free-style development in any language the system you're on can run, but also because it allows drop-in replacement of plugins without having to restart Nagios. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Thu Jan 4 17:41:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 04 Jan 2007 08:41:14 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1627970 ] check_disk performance output for more then one partition Message-ID: Bugs item #1627970, was opened at 2007-01-04 17:41 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=1627970&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: Sebastian Schubert (bauchi) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk performance output for more then one partition Initial Comment: The Performancedata generated by check_disk seems to inherit the warning/critical values for the last partitions from one of the previous partitions Version: check_disk (nagios-plugins 1.4.5) 1.79 Example: /check_disk -w 80% -c 90% DISK CRITICAL - free space: / 6772 MB (72% inode=90%); /boot 61 MB (66% inode=99%); /dev/shm 1267 MB (100% inode=99%); /usr/WebSphere 2322 MB (62% inode=92%); /var 26311 MB (93% inode=99%);| /=2584MB;1971;985;0;9858 /boot=31MB;19;9;0;98 /dev/shm=0MB;19;9;0;1267 /usr/WebSphere=1414MB;19;9;0;3937 /var=1732MB;19;9;0;29544 another example: DISK OK - free space: / 6833 MB (98% inode=-); /dev/shm 442 MB (100% inode=99%); /boot 55 MB (59% inode=-); /data 12583 MB (99% inode=-); /tmp 3134 MB (98% inode=-); /usr 4076 MB (91% inode=-); /var 5407 MB (97% inode=-);| /=93MB;6233;6579;0;6926 /dev/shm=0MB;397;419;0;442 /boot=38MB;84;89;0;94 /data=76MB;84;89;0;12660 /tmp=34MB;84;89;0;3168 /usr=355MB;84;89;0;4431 /var=129MB;84;89;0;5537 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1627970&group_id=29880 From dermoth at aei.ca Thu Jan 4 23:46:50 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 04 Jan 2007 17:46:50 -0500 Subject: [Nagiosplug-devel] check_ping timeout calculation Message-ID: <459D83DA.3060802@aei.ca> While testing the previous patch for check_ping I noticed the the max_seconds calculation was way off what it could calculate as max_seconds. The part shown in the patch below is to increase the timeout_interval used in alarm() if the other ping parameters does not make sense with the supplied or default timeout value set. In the patch below I calculate max_seconds my simply multiplying the critical time by the number of packets. If max_seconds is not an integer I round it up to the higher value. In the previous patch I comited I also add one second to the alarm so that it does not trigger it when ping take the expected time for a non-responding host (when max_seconds == timeout_interval). Alternatively I could undo the last patch and add one second in the part below if max_seconds == (int)max_seconds, but I fear that it trigger the alarm in some cases, like if max_seconds == 1.9999.. which is very close to the 2 seconds that would be set in the alarm. Any comments before I submit this patch? Thomas diff -u -r1.54 check_ping.c --- plugins/check_ping.c 4 Jan 2007 11:35:56 -0000 1.54 +++ plugins/check_ping.c 4 Jan 2007 22:32:24 -0000 @@ -399,7 +399,11 @@ if (max_packets == -1) max_packets = DEFAULT_MAX_PACKETS; - max_seconds = crta / 1000.0 * max_packets + max_packets; + max_seconds = crta * max_packets; + /* Round up max_seconds because we use only the int part */ + if (max_seconds != (int)max_seconds) + max_seconds = (int)max_seconds + 1; + if (max_seconds > timeout_interval) timeout_interval = (int)max_seconds; From noreply at sourceforge.net Fri Jan 5 12:57:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jan 2007 03:57:55 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1627970 ] check_disk performance output for more then one partition Message-ID: Bugs item #1627970, was opened at 2007-01-04 17:41 Message generated for change (Comment added) made by hendrikb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1627970&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: Sebastian Schubert (bauchi) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk performance output for more then one partition Initial Comment: The Performancedata generated by check_disk seems to inherit the warning/critical values for the last partitions from one of the previous partitions Version: check_disk (nagios-plugins 1.4.5) 1.79 Example: /check_disk -w 80% -c 90% DISK CRITICAL - free space: / 6772 MB (72% inode=90%); /boot 61 MB (66% inode=99%); /dev/shm 1267 MB (100% inode=99%); /usr/WebSphere 2322 MB (62% inode=92%); /var 26311 MB (93% inode=99%);| /=2584MB;1971;985;0;9858 /boot=31MB;19;9;0;98 /dev/shm=0MB;19;9;0;1267 /usr/WebSphere=1414MB;19;9;0;3937 /var=1732MB;19;9;0;29544 another example: DISK OK - free space: / 6833 MB (98% inode=-); /dev/shm 442 MB (100% inode=99%); /boot 55 MB (59% inode=-); /data 12583 MB (99% inode=-); /tmp 3134 MB (98% inode=-); /usr 4076 MB (91% inode=-); /var 5407 MB (97% inode=-);| /=93MB;6233;6579;0;6926 /dev/shm=0MB;397;419;0;442 /boot=38MB;84;89;0;94 /data=76MB;84;89;0;12660 /tmp=34MB;84;89;0;3168 /usr=355MB;84;89;0;4431 /var=129MB;84;89;0;5537 ---------------------------------------------------------------------- Comment By: Hendrik B?cker (hendrikb) Date: 2007-01-05 12:57 Message: Logged In: YES user_id=906410 Originator: NO Hi all, it seems, that this just happens, if you want to give warning and critical threshold in percentage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1627970&group_id=29880 From noreply at sourceforge.net Fri Jan 5 20:20:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jan 2007 11:20:50 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1629008 ] check_ping fails to handle Packet filtered error Message-ID: Bugs item #1629008, was opened at 2007-01-05 19:20 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=1629008&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Allen (cdallen) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping fails to handle Packet filtered error Initial Comment: The current (CVS/1.4.5 both) version of check_ping fails to handle this output from ping (ping utility, iputils-ss020927) [chrisa at silver plugins]$ ping -c 5 -n 10.179.15.254 PING 10.179.15.254 (10.179.15.254) 56(84) bytes of data. >From 194.81.46.13 icmp_seq=3 Packet filtered >From 194.81.46.13 icmp_seq=4 Packet filtered --- 10.179.15.254 ping statistics --- 5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4001ms , pipe 2 and produces: [chrisa at silver plugins]$ ./check_ping -H 10.179.15.254 80 100 300.0 500.0 /bin/ping -n -U -w 10 -c 5 10.179.15.254 CRITICAL - Could not interpret output from ping command [chrisa at silver plugins]$ echo $? 3 I've attached a (bad) patch against CVS/1.4.5 which I believe fixes the issue in a safe and functional, but hideous manner. I look forward to this Just Working in future versions of Nagios. Thanks, Chris Allen Lancaster University Network Services Ltd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1629008&group_id=29880 From dermoth at aei.ca Sat Jan 6 06:10:39 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 06 Jan 2007 00:10:39 -0500 Subject: [Nagiosplug-devel] check_ping timeout calculation In-Reply-To: <459D83DA.3060802@aei.ca> References: <459D83DA.3060802@aei.ca> Message-ID: <459F2F4F.1060204@aei.ca> On 04/01/07 05:46 PM, Thomas Guyot-Sionnest wrote: > While testing the previous patch for check_ping I noticed the the > max_seconds calculation was way off what it could calculate as max_seconds. > > The part shown in the patch below is to increase the timeout_interval > used in alarm() if the other ping parameters does not make sense with > the supplied or default timeout value set. > > In the patch below I calculate max_seconds my simply multiplying the > critical time by the number of packets. If max_seconds is not an integer > I round it up to the higher value. In the previous patch I comited I > also add one second to the alarm so that it does not trigger it when > ping take the expected time for a non-responding host (when max_seconds > == timeout_interval). > > Alternatively I could undo the last patch and add one second in the part > below if max_seconds == (int)max_seconds, but I fear that it trigger the > alarm in some cases, like if max_seconds == 1.9999.. which is very close > to the 2 seconds that would be set in the alarm. > > Any comments before I submit this patch? > I committed the said patch, and have one more thing. The timeout help text in inaccurate, and the timeout parameter itself is useless. We should either: 1. Remove -t, leaving the code as a no-op to avoid breaking anything or 2. Fix the text. I didn't do it because I'm not sure if it'll break anything localization-related. Ton, do you think it make sense to just remove -t, leaving a comment like: "This check script has no timeout option. The actual timeout can be calculated as 'critical_threshold * packets'." That would be done without breaking backward compatibility, leaving -t as a no-op. Thomas From noreply at sourceforge.net Sat Jan 6 06:29:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jan 2007 21:29:57 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1629008 ] check_ping fails to handle Packet filtered error Message-ID: Bugs item #1629008, was opened at 2007-01-05 14:20 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1629008&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Allen (cdallen) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping fails to handle Packet filtered error Initial Comment: The current (CVS/1.4.5 both) version of check_ping fails to handle this output from ping (ping utility, iputils-ss020927) [chrisa at silver plugins]$ ping -c 5 -n 10.179.15.254 PING 10.179.15.254 (10.179.15.254) 56(84) bytes of data. >From 194.81.46.13 icmp_seq=3 Packet filtered >From 194.81.46.13 icmp_seq=4 Packet filtered --- 10.179.15.254 ping statistics --- 5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4001ms , pipe 2 and produces: [chrisa at silver plugins]$ ./check_ping -H 10.179.15.254 80 100 300.0 500.0 /bin/ping -n -U -w 10 -c 5 10.179.15.254 CRITICAL - Could not interpret output from ping command [chrisa at silver plugins]$ echo $? 3 I've attached a (bad) patch against CVS/1.4.5 which I believe fixes the issue in a safe and functional, but hideous manner. I look forward to this Just Working in future versions of Nagios. Thanks, Chris Allen Lancaster University Network Services Ltd ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-06 00:29 Message: Logged In: YES user_id=375623 Originator: NO While trying to reproduce I got one more: >From 192.168.1.2 icmp_seq=1 Destination Port Unreachable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1629008&group_id=29880 From noreply at sourceforge.net Sat Jan 6 07:42:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 05 Jan 2007 22:42:02 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1629008 ] check_ping fails to handle Packet filtered error Message-ID: Bugs item #1629008, was opened at 2007-01-05 14:20 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1629008&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Chris Allen (cdallen) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping fails to handle Packet filtered error Initial Comment: The current (CVS/1.4.5 both) version of check_ping fails to handle this output from ping (ping utility, iputils-ss020927) [chrisa at silver plugins]$ ping -c 5 -n 10.179.15.254 PING 10.179.15.254 (10.179.15.254) 56(84) bytes of data. >From 194.81.46.13 icmp_seq=3 Packet filtered >From 194.81.46.13 icmp_seq=4 Packet filtered --- 10.179.15.254 ping statistics --- 5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4001ms , pipe 2 and produces: [chrisa at silver plugins]$ ./check_ping -H 10.179.15.254 80 100 300.0 500.0 /bin/ping -n -U -w 10 -c 5 10.179.15.254 CRITICAL - Could not interpret output from ping command [chrisa at silver plugins]$ echo $? 3 I've attached a (bad) patch against CVS/1.4.5 which I believe fixes the issue in a safe and functional, but hideous manner. I look forward to this Just Working in future versions of Nagios. Thanks, Chris Allen Lancaster University Network Services Ltd ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-06 01:42 Message: Logged In: YES user_id=375623 Originator: NO I researched a bit more and here's all I could get on my Ubuntu box (Custom filtering done with netfilter on OpenWRT). >From 192.168.1.2 icmp_seq=1 Destination Net Unreachable >From 192.168.1.3 icmp_seq=1 Destination Host Unreachable >From 192.168.1.4 icmp_seq=1 Destination Port Unreachable >From 192.168.1.5 icmp_seq=1 Destination Protocol Unreachable >From 192.168.1.6 icmp_seq=1 Destination Net Prohibited >From 192.168.1.7 icmp_seq=1 Destination Host Prohibited >From 192.168.1.8 icmp_seq=1 Packet filtered They all fail except Host Unreachable. I patched it and here's what I get now: $ for i in 2 3 4 5 6 7 8; do plugins/check_ping -H 192.168.1.$i -w 0.01,10% -c 0.1,20% -p1 -t1;echo; done CRITICAL - Network Unreachable (192.168.1.2) CRITICAL - Host Unreachable (192.168.1.3) CRITICAL - Bogus ICMP: Port Unreachable (192.168.1.4) CRITICAL - Bogus ICMP: Protocol Unreachable (192.168.1.5) CRITICAL - Network Prohibited (192.168.1.6) CRITICAL - Host Prohibited (192.168.1.7) CRITICAL - Packet Filtered (192.168.1.8) It's now fixed in CVS. File Added: check_ping.response_handling.patch ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-06 00:29 Message: Logged In: YES user_id=375623 Originator: NO While trying to reproduce I got one more: >From 192.168.1.2 icmp_seq=1 Destination Port Unreachable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1629008&group_id=29880 From dermoth at aei.ca Sat Jan 6 08:06:25 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 06 Jan 2007 02:06:25 -0500 Subject: [Nagiosplug-devel] check_ping timeout calculation In-Reply-To: <459F2F4F.1060204@aei.ca> References: <459D83DA.3060802@aei.ca> <459F2F4F.1060204@aei.ca> Message-ID: <459F4A71.5020405@aei.ca> On 06/01/07 12:10 AM, Thomas Guyot-Sionnest wrote: > > I committed the said patch, and have one more thing. The timeout help > text in inaccurate, and the timeout parameter itself is useless. We > should either: > > 1. Remove -t, leaving the code as a no-op to avoid breaking anything > or > 2. Fix the text. I didn't do it because I'm not sure if it'll break > anything localization-related. > > Ton, do you think it make sense to just remove -t, leaving a comment like: > > "This check script has no timeout option. The actual timeout can be > calculated as 'critical_threshold * packets'." > > That would be done without breaking backward compatibility, leaving -t > as a no-op. Reverted it. I think I messed up my debug printf and misunderstood that part (and the base value of crta), and also didn't realized ping wait 1 sec between each probes (thus the "+ max_packets"). I still think the -t parameter is misleading, so my suggestion to change it or remove it still stands (of course with the right formula). Sorry for the spam, Thomas From s.urbanovski at ac-nancy-metz.fr Sat Jan 6 10:48:53 2007 From: s.urbanovski at ac-nancy-metz.fr (=?ISO-8859-1?Q?St=E9phane_Urbanovski?=) Date: Sat, 06 Jan 2007 10:48:53 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459995CE.6070008@bier.homeip.net> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> Message-ID: <459F7085.2030208@ac-nancy-metz.fr> Florian Gleixner a ?crit : > True, leaks and crashes could make nagios more unstable. dl-plugins > should be used with care. "Worker threads" could isolate some of the risk. > > The performance gain is simply the time a C plugin needs to create a > process. You could say, that this is not very much time, but some nagios > setups make thousands of checks per minute. [...] > I think some default plugins like ping or tcp-check could be made as dl > module, the more complicated or the plugins that are usually executed at > the monitored nodes should be "normal" plugins. Hello Just an idea - extending nrpe to be able to support builtin commonly used checks (ping, load, mem, disk, etc ...) and support permanent connection to Nagios (over Unix or TCP sockect) - make Nagios support directly this new "super" nrpe as dl module Security and memory management problems should be easier to fix, or at least have a lower impact if limited to nrpe. -- St?phane Urbanovski From noreply at sourceforge.net Sun Jan 7 08:14:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 06 Jan 2007 23:14:41 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1627970 ] check_disk performance output for more then one partition Message-ID: Bugs item #1627970, was opened at 2007-01-04 11:41 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1627970&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: Sebastian Schubert (bauchi) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk performance output for more then one partition Initial Comment: The Performancedata generated by check_disk seems to inherit the warning/critical values for the last partitions from one of the previous partitions Version: check_disk (nagios-plugins 1.4.5) 1.79 Example: /check_disk -w 80% -c 90% DISK CRITICAL - free space: / 6772 MB (72% inode=90%); /boot 61 MB (66% inode=99%); /dev/shm 1267 MB (100% inode=99%); /usr/WebSphere 2322 MB (62% inode=92%); /var 26311 MB (93% inode=99%);| /=2584MB;1971;985;0;9858 /boot=31MB;19;9;0;98 /dev/shm=0MB;19;9;0;1267 /usr/WebSphere=1414MB;19;9;0;3937 /var=1732MB;19;9;0;29544 another example: DISK OK - free space: / 6833 MB (98% inode=-); /dev/shm 442 MB (100% inode=99%); /boot 55 MB (59% inode=-); /data 12583 MB (99% inode=-); /tmp 3134 MB (98% inode=-); /usr 4076 MB (91% inode=-); /var 5407 MB (97% inode=-);| /=93MB;6233;6579;0;6926 /dev/shm=0MB;397;419;0;442 /boot=38MB;84;89;0;94 /data=76MB;84;89;0;12660 /tmp=34MB;84;89;0;3168 /usr=355MB;84;89;0;4431 /var=129MB;84;89;0;5537 ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-07 02:14 Message: Logged In: YES user_id=375623 Originator: NO This bug is due the the re-use of warning_high_tide and critical_high_tide variables in a loop. I moved their initialization into the loop so that get re-initialized at each run. What happens is that when we're looking for percent thresholds, we take the minimum value between warning_high_tide and some other calculation. It's ok on the first run, but on subsequent loops warning_high_tide still holds the value from the previous run. if (path->freespace_percent->warning != NULL) { warning_high_tide = abs( min( (double) warning_high_tide, (double) (1.0 - path->freespace_percent->warning->end/100)*dtotal_units )); I'm not sure though why it's done this way but resetting these variables at each loop can't hurt and fixes this bug. This has been committed in CVS. File Added: check_disk.multiple_perfdata.patch ---------------------------------------------------------------------- Comment By: Hendrik B?cker (hendrikb) Date: 2007-01-05 06:57 Message: Logged In: YES user_id=906410 Originator: NO Hi all, it seems, that this just happens, if you want to give warning and critical threshold in percentage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1627970&group_id=29880 From seanius at seanius.net Sun Jan 7 18:25:09 2007 From: seanius at seanius.net (sean finney) Date: Sun, 7 Jan 2007 12:25:09 -0500 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459D2695.5060702@op5.se> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> <459BB0E8.9050304@bier.homeip.net> <459CD1BC.9000105@op5.se> <459CEE16.8030304@bier.homeip.net> <459D2695.5060702@op5.se> Message-ID: <20070107172509.GA26990@cobija.connexer.com> hey guys, On Thu, Jan 04, 2007 at 05:08:53PM +0100, Andreas Ericsson wrote: > > 1.4.5 has some spopen calls in check_fping.c check_hpjd.c check_load.c > > check_ping.c check_procs.c check_snmp.c check_swap.c and check_users.c. > > > > Ah, righto. I don't use the official version myself and I've hacked > those instances away in our version. for the record, way back when i merged in the runcmd stuff (2004 or so?), a good number of the plugins either had trouble compiling or would segfault. iirc, the ones which had trouble i left with the spopen calls to have a later look, since at the time we were getting close to making a release. > > But true: it would cost very much initially to rewrite that all. I think > > nobody wants to do that without a need. > > > > Yes. It all piles up rather quickly. To be honest, I like the fact that > plugins are external programs. Mainly because it allows fast and > free-style development in any language the system you're on can run, but > also because it allows drop-in replacement of plugins without having to > restart Nagios. and also for posterity... around the time i mentioned above, andreas and i had a long and drawn out conversation about possibly "embedding" plugins by compiling them as .so libraries and use of dlopen(). this would allow for removing 2 of the 3 fork calls involved in each popen() type call (iirc), and would remove the need to exec() anything. unfortunately, this comes at the cost of many memory leaks (not many plugins bother to even call free()), possible crashing of the nagios daemon, and lots of code-rewriting... and the performance increase is only marginal since in most cases the real bottleneck is the first fork/exec call being done serially from the nagios daemon. better would be to remove/rewrite the fork/exec bottleneck by having a pool of worker threads that could do it in a more parallel fashion--this was also a result of the old discussion iirc. sean From ae at op5.se Sun Jan 7 20:14:19 2007 From: ae at op5.se (Andreas Ericsson) Date: Sun, 07 Jan 2007 20:14:19 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <20070107172509.GA26990@cobija.connexer.com> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459B8510.7010803@op5.se> <459BB0E8.9050304@bier.homeip.net> <459CD1BC.9000105@op5.se> <459CEE16.8030304@bier.homeip.net> <459D2695.5060702@op5.se> <20070107172509.GA26990@cobija.connexer.com> Message-ID: <45A1468B.5080202@op5.se> sean finney wrote: > hey guys, > >>> >> Yes. It all piles up rather quickly. To be honest, I like the fact that >> plugins are external programs. Mainly because it allows fast and >> free-style development in any language the system you're on can run, but >> also because it allows drop-in replacement of plugins without having to >> restart Nagios. > > and also for posterity... around the time i mentioned above, andreas and > i had a long and drawn out conversation about possibly "embedding" > plugins by compiling them as .so libraries and use of dlopen(). this > would allow for removing 2 of the 3 fork calls involved in each popen() > type call (iirc), and would remove the need to exec() anything. > > unfortunately, this comes at the cost of many memory leaks (not many > plugins bother to even call free()), possible crashing of the nagios daemon, > and lots of code-rewriting... and the performance increase is only > marginal since in most cases the real bottleneck is the first fork/exec > call being done serially from the nagios daemon. better would be to > remove/rewrite the fork/exec bottleneck by having a pool of worker > threads that could do it in a more parallel fashion--this was also a > result of the old discussion iirc. > Actually, the testprograms I wrote showed that spawning several processes from a single thread and multiplexing their output was by far the most scalable solution. With this method, it's possible to run up to (((ulimit -n) / 2) - 5) checks simultaneously (generally ~500, although the ulimit can be raised to as much as 1024 * 1024 on Linux). The threading model made certain requirements of the daemon program which made it unsuitable for use in Nagios, and on Linux with glibc 2.4 and the Native POSIX thread library the cap was hit at ~300 checks, irrespective of ulimit values. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Sun Jan 7 20:19:45 2007 From: ae at op5.se (Andreas Ericsson) Date: Sun, 07 Jan 2007 20:19:45 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <459F7085.2030208@ac-nancy-metz.fr> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459F7085.2030208@ac-nancy-metz.fr> Message-ID: <45A147D1.4000000@op5.se> St?phane Urbanovski wrote: > Florian Gleixner a ?crit : >> True, leaks and crashes could make nagios more unstable. dl-plugins >> should be used with care. "Worker threads" could isolate some of the risk. >> >> The performance gain is simply the time a C plugin needs to create a >> process. You could say, that this is not very much time, but some nagios >> setups make thousands of checks per minute. > > [...] > >> I think some default plugins like ping or tcp-check could be made as dl >> module, the more complicated or the plugins that are usually executed at >> the monitored nodes should be "normal" plugins. > > Hello > > Just an idea > > - extending nrpe to be able to support builtin commonly used checks (ping, load, mem, disk, etc ...) Supporting ICMP in a loadable module (or indeed in a daemon of any kind) has its problems as was stated in another mail in this thread. Supporting system load, memory usage and disk usage is, again, a different kind of worms. There's no standardized interface usable to obtain these metrics that reliably work on the set of systems supported by the current plugin-distribution. As such, it would be maintenance nightmare to try to keep it working on all those systems. For reference, download the GNU coreutils package and count the #ifdef lines. Not pretty. > and support permanent connection to Nagios (over Unix or TCP sockect) This would require a lot of hacking in Nagios to solve. > - make Nagios support directly this new "super" nrpe as dl module > > Security and memory management problems should be easier to fix, > or at least have a lower impact if limited to nrpe. > But you just said to load this newfangled dream-version of nrpe as a module? That sort of microsoft'ish thinking leads to "integrated" and very unstable code I'm afraid. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From stephane.urbanovski at ac-nancy-metz.fr Mon Jan 8 09:38:43 2007 From: stephane.urbanovski at ac-nancy-metz.fr (=?ISO-8859-15?Q?St=E9phane_Urbanovski?=) Date: Mon, 08 Jan 2007 09:38:43 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A147D1.4000000@op5.se> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459F7085.2030208@ac-nancy-metz.fr> <45A147D1.4000000@op5.se> Message-ID: <45A20313.8010208@ac-nancy-metz.fr> Andreas Ericsson a ?crit : >> - extending nrpe to be able to support builtin commonly used checks (ping, load, mem, disk, etc ...) > > Supporting ICMP in a loadable module (or indeed in a daemon of any kind) > has its problems as was stated in another mail in this thread. Yes, I read this > Supporting system load, memory usage and disk usage is, again, a > different kind of worms. There's no standardized interface usable to > obtain these metrics that reliably work on the set of systems supported > by the current plugin-distribution. As such, it would be maintenance > nightmare to try to keep it working on all those systems. For reference, > download the GNU coreutils package and count the #ifdef lines. Not pretty. Of course this "newnrpe" is be able to use traditionnal plugins if there is no internal support. >> and support permanent connection to Nagios (over Unix or TCP sockect) > > This would require a lot of hacking in Nagios to solve. > > >> - make Nagios support directly this new "super" nrpe as dl module >> >> Security and memory management problems should be easier to fix, >> or at least have a lower impact if limited to nrpe. >> > > But you just said to load this newfangled dream-version of nrpe as a > module? That sort of microsoft'ish thinking leads to "integrated" and > very unstable code I'm afraid. (Ok, my english is really poor ...) Not the "newnrpe", wich is a separate process, but only the communication with newnrpe part -- St?phane Urbanovski From ae at op5.se Mon Jan 8 13:02:34 2007 From: ae at op5.se (Andreas Ericsson) Date: Mon, 08 Jan 2007 13:02:34 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A20313.8010208@ac-nancy-metz.fr> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459F7085.2030208@ac-nancy-metz.fr> <45A147D1.4000000@op5.se> <45A20313.8010208@ac-nancy-metz.fr> Message-ID: <45A232DA.9020605@op5.se> St?phane Urbanovski wrote: > Andreas Ericsson a ?crit : > >> Supporting system load, memory usage and disk usage is, again, a >> different kind of worms. There's no standardized interface usable to >> obtain these metrics that reliably work on the set of systems supported >> by the current plugin-distribution. As such, it would be maintenance >> nightmare to try to keep it working on all those systems. For reference, >> download the GNU coreutils package and count the #ifdef lines. Not pretty. > > Of course this "newnrpe" is be able to use traditionnal plugins if there is no internal support. > Assuming "newnrpe" would be running on a remote host, it would almost always just be used to check local things (disk usage, uptime, memory usage, process info etc, etc). As those checks are very difficult to make portable, I frankly don't see the value for it. The network checks would be easy (although time-consuming) to slot in, but they wouldn't be used very much over nrpe. >>> and support permanent connection to Nagios (over Unix or TCP sockect) >> This would require a lot of hacking in Nagios to solve. >> >> >>> - make Nagios support directly this new "super" nrpe as dl module >>> >>> Security and memory management problems should be easier to fix, >>> or at least have a lower impact if limited to nrpe. >>> >> But you just said to load this newfangled dream-version of nrpe as a >> module? That sort of microsoft'ish thinking leads to "integrated" and >> very unstable code I'm afraid. > > (Ok, my english is really poor ...) > > Not the "newnrpe", wich is a separate process, but only the communication with newnrpe part > Ah, I see what you mean now. I'm afraid that fairly drastically reduces the scalability of Nagios. Assume for a second that you have 1500 hosts to monitor, all of which use NRPE for checking local stuff. Keeping up the connection with those 1500 hosts requires 1500 open file-descriptors at all times. Most systems can have a lot more files than that open per process at any given time, but there is still a hard limit lurking somewhere which means Nagios can no longer check an arbitrary number of hosts and services. The worst part is that that hard limit will be set differently on different systems. I'm afraid you'll find that this just isn't useful enough to warrant the massive developer effort it would take to write it and seeing as you're the only one arguing your case, you'd have to write it yourself to get it implemented. Either way, further discussion is fairly pointless until you have some code available. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Mon Jan 8 23:51:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 08 Jan 2007 14:51:03 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1630970 ] Fix for buffer overflow of check_procs procprog string Message-ID: Bugs item #1630970, was opened at 2007-01-08 22:51 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=1630970&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Hoos (jhoos) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for buffer overflow of check_procs procprog string Initial Comment: Line 196 of the file check_procs.c contains a line that, if executed often enough, will cause the procprog pointer variable to run past the end of its originally-allocated buffer, which in turn causes erratic program behavior. The line in question reads: procprog = base_name(procprog); which, depending on the implementation of base_name, will either assign procprog to point to a deeper location within its original buffer, or may cause it to point to some other static memory entirely. The attached patch changes this to use: strcpy(base_name(procprog)); to avoid this problem. This solved erratic behavior on a Solaris 8 system that was using the system's 'ps' command instead of 'pst3'. This patch is related to bug 1578214, and possibly to bug 1595449 (particularly the part that recommends changing MAX_INPUT_BUFFER to 4096). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1630970&group_id=29880 From dermoth at aei.ca Tue Jan 9 14:00:58 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 09 Jan 2007 08:00:58 -0500 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A232DA.9020605@op5.se> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459F7085.2030208@ac-nancy-metz.fr> <45A147D1.4000000@op5.se> <45A20313.8010208@ac-nancy-metz.fr> <45A232DA.9020605@op5.se> Message-ID: <45A3920A.6050109@aei.ca> On 08/01/07 07:02 AM, Andreas Ericsson wrote: > St?phane Urbanovski wrote: >> Andreas Ericsson a ?crit : >> >>> But you just said to load this newfangled dream-version of nrpe as a >>> module? That sort of microsoft'ish thinking leads to "integrated" and >>> very unstable code I'm afraid. >> (Ok, my english is really poor ...) >> >> Not the "newnrpe", wich is a separate process, but only the communication with newnrpe part >> > > Ah, I see what you mean now. I'm afraid that fairly drastically reduces > the scalability of Nagios. Assume for a second that you have 1500 hosts > to monitor, all of which use NRPE for checking local stuff. Keeping up > the connection with those 1500 hosts requires 1500 open file-descriptors > at all times. Most systems can have a lot more files than that open per > process at any given time, but there is still a hard limit lurking > somewhere which means Nagios can no longer check an arbitrary number of > hosts and services. The worst part is that that hard limit will be set > differently on different systems. > > I'm afraid you'll find that this just isn't useful enough to warrant the > massive developer effort it would take to write it and seeing as you're > the only one arguing your case, you'd have to write it yourself to get > it implemented. Either way, further discussion is fairly pointless until > you have some code available. Actually I think now it's getting interesting. If done properly, this could be a nice way of doing distributed active checking. Using the same system St?phane described Nagios could have open connections to remote execution hosts that runs the checks and read back results. Different services properties would determine if the service can be run directly on the host (if Nagios has an open connection to it) or if it has to be remote. Check execution load could be run on dedicated servers, or even be spread out across monitored hosts. On big setups this had the clear advantage of scalability, but on smaller setups it can also be interesting as one could use very cheap servers for running the Nagios daemon in HA, and provide redundancy by spreading the checks across monitored servers themselves. Thomas From ae at op5.se Tue Jan 9 14:38:55 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 09 Jan 2007 14:38:55 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A3920A.6050109@aei.ca> References: <458AD7D0.1090902@nagios.org> <459850DC.4050606@bier.homeip.net> <45992C3B.1000609@aei.ca> <459995CE.6070008@bier.homeip.net> <459F7085.2030208@ac-nancy-metz.fr> <45A147D1.4000000@op5.se> <45A20313.8010208@ac-nancy-metz.fr> <45A232DA.9020605@op5.se> <45A3920A.6050109@aei.ca> Message-ID: <45A39AEF.7090401@op5.se> Thomas Guyot-Sionnest wrote: > On 08/01/07 07:02 AM, Andreas Ericsson wrote: >> St?phane Urbanovski wrote: >>> Andreas Ericsson a ?crit : >>> >>>> But you just said to load this newfangled dream-version of nrpe as a >>>> module? That sort of microsoft'ish thinking leads to "integrated" and >>>> very unstable code I'm afraid. >>> (Ok, my english is really poor ...) >>> >>> Not the "newnrpe", wich is a separate process, but only the communication with newnrpe part >>> >> Ah, I see what you mean now. I'm afraid that fairly drastically reduces >> the scalability of Nagios. Assume for a second that you have 1500 hosts >> to monitor, all of which use NRPE for checking local stuff. Keeping up >> the connection with those 1500 hosts requires 1500 open file-descriptors >> at all times. Most systems can have a lot more files than that open per >> process at any given time, but there is still a hard limit lurking >> somewhere which means Nagios can no longer check an arbitrary number of >> hosts and services. The worst part is that that hard limit will be set >> differently on different systems. >> >> I'm afraid you'll find that this just isn't useful enough to warrant the >> massive developer effort it would take to write it and seeing as you're >> the only one arguing your case, you'd have to write it yourself to get >> it implemented. Either way, further discussion is fairly pointless until >> you have some code available. > > Actually I think now it's getting interesting. If done properly, this > could be a nice way of doing distributed active checking. > > Using the same system St?phane described Nagios could have open > connections to remote execution hosts that runs the checks and read back > results. Different services properties would determine if the service > can be run directly on the host (if Nagios has an open connection to it) > or if it has to be remote. Check execution load could be run on > dedicated servers, or even be spread out across monitored hosts. > Yes, but a distributed static mesh redundancy thing is pretty different from an NRPE-daemon with an option to keep connections alive. A nice example of where "think big" doesn't work, but "think bigger" does. I'm working on a module that does just that, but it requires a fullblown Nagios installation on each of the poller nodes and the decision of which host is monitored by what system is determined by hostgroups instead of through some automagic solution that could possibly (and would probably) get things wrong from time to time. > On big setups this had the clear advantage of scalability, but on > smaller setups it can also be interesting as one could use very cheap > servers for running the Nagios daemon in HA, and provide redundancy by > spreading the checks across monitored servers themselves. > Yup. That's the plan. Especially the scalability bit. The idea is to get an infinite number of layers of pollers/masters, as each poller can in turn have pollers connected to it. Now I'm just hoping we'll release it publicly soon so I can get the nagios community to test and patch it for me while I lounge and drink beer ;-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From Thomas at zango.com Tue Jan 9 20:00:27 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 9 Jan 2007 11:00:27 -0800 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A39AEF.7090401@op5.se> Message-ID: <804160344192334BB21922E8082EA6C0437B23@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Andreas Ericsson > Sent: January 9, 2007 8:39 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] RFC: Nagios 3 and Embedded > Perl Plugins > > Thomas Guyot-Sionnest wrote: > > Actually I think now it's getting interesting. If done > properly, this > > could be a nice way of doing distributed active checking. > > > > Using the same system St?phane described Nagios could have open > > connections to remote execution hosts that runs the checks > and read back > > results. Different services properties would determine if > the service > > can be run directly on the host (if Nagios has an open > connection to it) > > or if it has to be remote. Check execution load could be run on > > dedicated servers, or even be spread out across monitored hosts. > > > > > Yes, but a distributed static mesh redundancy thing is pretty > different > from an NRPE-daemon with an option to keep connections alive. A nice > example of where "think big" doesn't work, but "think bigger" does. > > I'm working on a module that does just that, but it requires > a fullblown > Nagios installation on each of the poller nodes and the decision of > which host is monitored by what system is determined by hostgroups > instead of through some automagic solution that could possibly (and > would probably) get things wrong from time to time. Sounds great. Just to make things clear my idea wasn't a NRPE replacement but rather an addition. For ex. you could have something like this (Lets't call my thing NRCE, Nag[...] Command Executor): +---------+ | Nagios | +---------+ | | +---------+ | NRCE | +---------+ | | +---------+ | NRPE | +---------+ The NRCE host could be a monitored host as well and remote network checks could be either coming from Nagios itself or from another NRCE host. It wouldn't require a full blown Nagios but your solution has the advantage of cascading checks. With that and by reducing the logic involved in the main Nagios process your solution is much more scalable. Do you plan on having the "child" Nagios processes receive their config automatically from the main process? That would simplify a lot the setup. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Wed Jan 10 08:51:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Jan 2007 23:51:42 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632072 ] pointer error in plugins/netutils.c Message-ID: Patches item #1632072, was opened at 2007-01-10 07:51 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=1632072&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: pointer error in plugins/netutils.c Initial Comment: In np_net_connect() a pointer to the value returned by socket() is compared against zero rather than the value itself. Patch against CVS HEAD is below. Chris Index: plugins/netutils.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/netutils.c,v retrieving revision 1.32 diff -r1.32 netutils.c 228c228 < if(sd < 0){ --- > if(*sd < 0){ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632072&group_id=29880 From noreply at sourceforge.net Wed Jan 10 08:59:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Jan 2007 23:59:02 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632078 ] critical threshold % incorrectly displayed by check_icmp Message-ID: Patches item #1632078, was opened at 2007-01-10 07:59 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=1632078&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: critical threshold % incorrectly displayed by check_icmp Initial Comment: A misplaced paren causes a bogus value to be displayed as the default critical threshold percent. Patch is below. Chris Index: plugins-root/check_icmp.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins-root/check_icmp.c,v retrieving revision 1.8 diff -r1.8 check_icmp.c 1204c1204 < printf ("%0.3fms,%u%%)\n", (float)crit.rta), crit.pl; --- > printf ("%0.3fms,%u%%)\n", (float)crit.rta, crit.pl); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632078&group_id=29880 From noreply at sourceforge.net Wed Jan 10 09:25:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Jan 2007 00:25:39 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632091 ] printf format string typos Message-ID: Patches item #1632091, was opened at 2007-01-10 08:25 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=1632091&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: printf format string typos Initial Comment: A couple of misplaced commas in format strings and a missing '%s' in the usage message of check_ldap. The latter prevented the flags for selecting the LDAP and IP protocol versions from being displayed. Patch against CVS HEAD is attached. Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632091&group_id=29880 From ae at op5.se Wed Jan 10 11:15:27 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 10 Jan 2007 11:15:27 +0100 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <804160344192334BB21922E8082EA6C0437B23@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C0437B23@seaex01.180solutions.com> Message-ID: <45A4BCBF.20400@op5.se> Thomas Guyot-Sionnest wrote: >> -----Original Message----- >> From: nagiosplug-devel-bounces at lists.sourceforge.net >> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >> Behalf Of Andreas Ericsson >> Sent: January 9, 2007 8:39 >> To: Nagios Plugin Development Mailing List >> Subject: Re: [Nagiosplug-devel] RFC: Nagios 3 and Embedded >> Perl Plugins >> >> Thomas Guyot-Sionnest wrote: >>> Actually I think now it's getting interesting. If done >> properly, this >>> could be a nice way of doing distributed active checking. >>> >>> Using the same system St?phane described Nagios could have open >>> connections to remote execution hosts that runs the checks >> and read back >>> results. Different services properties would determine if >> the service >>> can be run directly on the host (if Nagios has an open >> connection to it) >>> or if it has to be remote. Check execution load could be run on >>> dedicated servers, or even be spread out across monitored hosts. >>> >> >> Yes, but a distributed static mesh redundancy thing is pretty >> different >> from an NRPE-daemon with an option to keep connections alive. A nice >> example of where "think big" doesn't work, but "think bigger" does. >> >> I'm working on a module that does just that, but it requires >> a fullblown >> Nagios installation on each of the poller nodes and the decision of >> which host is monitored by what system is determined by hostgroups >> instead of through some automagic solution that could possibly (and >> would probably) get things wrong from time to time. > > Sounds great. Just to make things clear my idea wasn't a NRPE replacement but rather an addition. For ex. you could have something like this (Lets't call my thing NRCE, Nag[...] Command Executor): > > +---------+ > | Nagios | > +---------+ > | > | > +---------+ > | NRCE | > +---------+ > | > | > +---------+ > | NRPE | > +---------+ > Again, I believe "think big" isn't enough and "think bigger" is required. I'm probably biased though ;-) > The NRCE host could be a monitored host as well and remote network checks could be either coming from Nagios itself or from another NRCE host. > > It wouldn't require a full blown Nagios but your solution has the advantage of cascading checks. With that and by reducing the logic involved in the main Nagios process your solution is much more scalable. > > Do you plan on having the "child" Nagios processes receive their config automatically from the main process? That would simplify a lot the setup. > Yes. Here's how it's supposed to work in a scenario with only one master and one poller: * Poller node starts (or is restarted). * It loads the module which connects to master and requests config, sending the timestamp of its own config-file (only one) along with the request. * The master checks if an update is necessary. - if yes: * The master runs an external helper-script which extracts the parts of the config that the poller needs to know and feeds it to the poller. * The poller restarts itself and reads the new configuration file. * The master disables active checks for the services and hosts monitored by the poller. * The poller periodically sends a pulse to the master, telling it it's alive. A check-result is considered to be an "I'm alive" message. * If the poller goes down the master enables checks for the hosts and services previously checked by the poller. In the case of more than one master, the check-results are sent to each master, and the one with the most recent configuration is considered to be the grand-master for the duration of it's uptime. In the case of more than one poller where the pollers are redundant, the pollers send check-results to each other as well as to the master, so as to save the network load of having to do the check twice (redundant poller nodes are expected to be physically close to each other, so network traffic between them is of no concern). In the case of pollers which in turn have pollers underneath them, the masters (including the grandmaster) is considered tier1, the pollers tier2 and the pollers' pollers tier3. In this case, tier2 nodes disables checks for hosts/services that are handled by tier3 nodes while those tier3 nodes are alive. The tier2 nodes also acts as masters for the tier3 nodes, while still forwarding all their results (including those from the tier3 nodes) to the tier1 nodes. This is all very neat, because you can use all of the tier1, tier2 and tier3 nodes as full-blown nagios installations by the simple expedient of also installing the GUI package on them. Think for example a large international corporation where there is a network operations centre that has the tier 1 nodes that the network infrastructure administrators work with. They see the whole picture. In each country where there's an office you have a redundant set of tier 2 nodes that are responsible for handling all the checks in that country. If you check the GUI for one of those, you only see the checks for that country, which is most likely appropriate as the admins working at that site don't really need the whole picture. The tier 3 nodes are placed at the various branch offices and are responsible for checking the everything there. The branch office IT staff can log in to their server (which is close by and has good network performance) and see what's important to their network. I realize that the "see what's important to their network" can just as easily be done by massaging the config at the NOC a bit, but it's very convenient to have several servers with their own GUI, as it comes for free and will provide good network speed for the people in Taiwan even if the NOC is in Finland. Note that any or all of the tiers in the above scenario can be redundant with as many servers as you like. Also note that this allows an arbitrarily large network to be monitored without using some monster of a computer, although the master nodes probably require fairly heavy equipment to be able to perform reasonably, GUI-wise, with the number of monitored nodes one could expect for a network of this size. The reason it scales more or less indefinitely is that the bottleneck (formerly the command-pipe) is much larger (generally 132KiB vs 4KiB) and spread out over as many nodes as you like. The *real* bottleneck is, in this scenario, the amount of data you can feed to the master-servers, which shouldn't be less than 10Mbit/second in a network of this size. Most likely it's 100Mbit from tier2 to tier1, which is what matters. The amount of data required to transmit for each check is, on average, 400 bytes (a bunch of timestamps, return-code, plugin output), so assuming all bandwidth is used for transmitting check-results, that would allow for 3125 checks per second. With an average check-interval of 3 minutes, that's 562500 checks for the 10Mbit case. For 100Mbit we can use a fifth of the bandwidth and still check well in excess of 1 million services with very frequent intervals. Sorry for the long mail. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From uemit.altan at degussa.com Wed Jan 10 18:00:14 2007 From: uemit.altan at degussa.com (uemit.altan at degussa.com) Date: Wed, 10 Jan 2007 18:00:14 +0100 Subject: [Nagiosplug-devel] check_UDP Message-ID: Hello, I have problems with using the nagios-plugin "check_udp". I have the version "check_UDP (nagios-plugins 1.4.4) 1.79". If I perform the command "./check_udp -H 193.100.46.13 -p 53 -4 -w 5 -c 8" on our Nagios-Server I get the following output: With UDP checks, a send/expect string must be specified. Usage: check_UDP -H host -p port [-w ] [-c ] [-s ] [-e ] [-q ] [-m ] [-d ] [-t ] [-r ] [-M ] [-v] [-4|-6] [-j] [-D ] [-S ] [-E] If I perform the command with send/except string like "./check_udp -H 193.100.46.13 -p 53 -4 -w 5 -c 8 -s test1 -e test2 -q test3 -v" I get the following output: Using service UDP Port: 53 flags: 0x1a Send string: test1 Quit string: test3 server_expect_count: 1 0: test2 CRITICAL - Socket timeout after 10 seconds So what is wrong with the syntax of my command and could you please send me an example command? Thank you in advance! Best regards ?mit Altan From noreply at sourceforge.net Thu Jan 11 00:58:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 10 Jan 2007 15:58:26 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632817 ] email_loop mod for ssl, forgetafter, trashall Message-ID: Patches item #1632817, was opened at 2007-01-10 23:58 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=1632817&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: miolinux (miolinux) Assigned to: Nobody/Anonymous (nobody) Summary: email_loop mod for ssl, forgetafter, trashall Initial Comment: Used Mail::POP3Client for SSL support Added trashall param to delete all mail on server Added forgetafter param to remove old lost/pending mail from database Allow multiple mail-servers (taken from nagiosexchange) Fixed lost mail stat file on timeout ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632817&group_id=29880 From ton.voon at altinity.com Fri Jan 12 15:52:46 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 12 Jan 2007 14:52:46 +0000 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds Message-ID: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> Hi! I'm canvassing opinions for this change to the developer guidelines re: command arguments to thresholds. I first brought this up at the Nagios Conference in Germany (http://www.netways.de/de/ nagios_konferenz/archiv_2006/programm/nagios_plugins/), but want to make sure there is a consensus in this mailing list. BACKGROUND There are three main problems: 1) when you have a check that wants to check multiple "things", the syntax is confusing. For example, free disk space in check_disk is - w/-c (in units or percent), but inode checking is -W/-K. In check_http, -w/-c is for time taken, -m is for page size. This is not very readable and inconsistent 2) the output and performance data is inconsistent with what is being checked. For instance, if I check my disks for inodes, I don't necessarily want perf data returned about disk free. This clogs up my graphs and muddies my output 3) I've started using common routines for threshold parsing and found that the way that parsing occurs between plugins is inconsistent. For instance, check_procs -c 1:1 means "critical if not 1 process". However, check_disk -c 5% means "critical if between 0 and 5%". Worse, the way the guidelines define ranges so the default is to alert outside a range, which looks wrong. I did this test to the audience at the Nagios Conference. Given a command 'check_stuff -w 30:50 -c 10:30' where the result of "stuff" is 15, what is the alert level raised? Go on, have a guess! The answer is Warning. I had two guesses of "Critical" by the crowd and I think this is because you immediately assume an alert **within** the range, not outside. I think this needs fixing. PROPOSAL So my proposal is to have a different, but complementary, method of specifying thresholds: --metric=crit/warn The crit and warn ranges are defined as min:max (max is optional, defaults to +infinity). Alert if the checked value is inside this range. If you want to alert on the outside of this range, prefix the range with a carat sign (^). Crit or warn can be blank, meaning no alert to be specified for that alert level. If the metric is specified, then output + perfdata will reflect. Eg, check_http --page_size=60K/40K --document_age=5s/3s will give output of the document age and the page size, but not the certificate age or the time taken. If you want output and perfdata without checking the result, specify the metric without any values, eg check_http -- certificate_age. I think the metric name should be composed of alphanumerics and underscore only, so it can map to RRD names. If there is a many-to- many mapping (eg, check_disk, looking at per mountpoint), use a key prefixed at the beginning with a separating colon, eg check_disk -- disk_free=2GB --inode_used=/0:500 -p / -p /var would have perf output of: /:disk_free=1.3GB;;2 /:inode_used=433;0:500; /var:disk_free=0.7GB;;2 / var:inode_used=700;0:500; Whatever processes the perf data can decide how to use the prefix (save to a separate RRD?). COMPLICATIONS As this is a new command syntax I can see this being acceptable, as long as the old syntax still works correctly. However, the performance data part will be a problem to current parsers since I'd like to redefine the meaning of warn and crit. One option is that the new perf data is outputted in XML format. This might help with structural changes in future. This also ties in with a request from Gerd Muller of Netways at NagConf where he wanted some metadata re: the plugin to be available (name=check_disk version=1.80). Any opinions? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bts2000dkdkdk at 163.com Mon Jan 15 12:00:01 2007 From: bts2000dkdkdk at 163.com (Ross Bu) Date: Mon, 15 Jan 2007 19:00:01 +0800 (CST) Subject: [Nagiosplug-devel] One question about check-procs Message-ID: <45AB5EB1.00005D.03358@bj163app94.163.com> Hi admin Does check_cpu has been replaced with check_procs --metric=cpu. So we can't find check_cpu in libexec , right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jan 15 22:30:13 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 15 Jan 2007 22:30:13 +0100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> Message-ID: <45ABF265.3040707@mailing.kaufland-informationssysteme.com> Hi Ton, hi list, > > > COMPLICATIONS > > As this is a new command syntax I can see this being acceptable, as long > as the old syntax still works correctly. However, the performance data > part will be a problem to current parsers since I'd like to redefine the > meaning of warn and crit. I really like your proposals but I think, keeping the perfdata working isn't possible without a --old flag. If I understood the perfdata prefixes correctly the : as a seperator isn't recognized by old-style parsers leading to a label like for example "/var:free_space=.." I guess many performance graphers rely on the label as an RRA name - which can neither be renamed nor added without recreating the rrd afaik. perfgrapher developers, please :) > One option is that the new perf data is outputted in XML format. This > might help with structural changes in future. This also ties in with a > request from Gerd Muller of Netways at NagConf where he wanted some > metadata re: the plugin to be available (name=check_disk version=1.80). I think xml is a bit to bloat for the limited pluginoutput of nagios prior 3.0 and imho the plugins need to work for every version. At least until 3.0 is spread wide enough - and there still seem to be a couple of installations < 2.0 according to nagios-users list postings. Apart from the in depth specifications: The plans look after hard work and the sf tracker still shows 90 patches and 68 Bugs. I guess you plan a gradual switch? matthias From gavin at openfusion.com.au Tue Jan 16 03:53:12 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 16 Jan 2007 13:53:12 +1100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> Message-ID: <20070116025312.GA28666@openfusion.com.au> Hi Ton, On Fri, Jan 12, 2007 at 02:52:46PM +0000, Ton Voon wrote: > There are three main problems: > > 1) when you have a check that wants to check multiple "things", the > syntax is confusing. For example, free disk space in check_disk is - > w/-c (in units or percent), but inode checking is -W/-K. In > check_http, -w/-c is for time taken, -m is for page size. This is not > very readable and inconsistent Agreed. > 2) the output and performance data is inconsistent with what is being > checked. For instance, if I check my disks for inodes, I don't > necessarily want perf data returned about disk free. This clogs up my > graphs and muddies my output > > 3) I've started using common routines for threshold parsing and found > that the way that parsing occurs between plugins is inconsistent. For > instance, check_procs -c 1:1 means "critical if not 1 process". > However, check_disk -c 5% means "critical if between 0 and 5%". > Worse, the way the guidelines define ranges so the default is to > alert outside a range, which looks wrong. > > I did this test to the audience at the Nagios Conference. Given a > command 'check_stuff -w 30:50 -c 10:30' where the result of "stuff" > is 15, what is the alert level raised? > > Go on, have a guess! > > The answer is Warning. I had two guesses of "Critical" by the crowd > and I think this is because you immediately assume an alert > **within** the range, not outside. I think this needs fixing. I think you can argue it a bit both ways. I agree it's confusing that different plugins are inconsistent on how they treat ranges; OTOH it seems to me that the default range semantics do differ for different plugins - with something like 'check_procs' it seems like exclusive ranges are more useful than inclusive ones. I guess that just means people would need to get used to making that explicit with a caret, but I'm a bit ambivalent on this one. > PROPOSAL > > So my proposal is to have a different, but complementary, method of > specifying thresholds: > > --metric=crit/warn > > The crit and warn ranges are defined as min:max (max is optional, > defaults to +infinity). Alert if the checked value is inside this > range. If you want to alert on the outside of this range, prefix the > range with a carat sign (^). > > Crit or warn can be blank, meaning no alert to be specified for that > alert level. > > If the metric is specified, then output + perfdata will reflect. Eg, > check_http --page_size=60K/40K --document_age=5s/3s will give output > of the document age and the page size, but not the certificate age or > the time taken. If you want output and perfdata without checking the > result, specify the metric without any values, eg check_http -- > certificate_age. > > I think the metric name should be composed of alphanumerics and > underscore only, so it can map to RRD names. Yech. Please allow hyphens in the arg names, and map them to underscores in the perf data. I think --page_size looks silly compared to --page-size - what do others think? > If there is a many-to- > many mapping (eg, check_disk, looking at per mountpoint), use a key > prefixed at the beginning with a separating colon, eg check_disk -- > disk_free=2GB --inode_used=/0:500 -p / -p /var would have perf output > of: > > /:disk_free=1.3GB;;2 /:inode_used=433;0:500; /var:disk_free=0.7GB;;2 / > var:inode_used=700;0:500; > > Whatever processes the perf data can decide how to use the prefix > (save to a separate RRD?). > > > > COMPLICATIONS > > As this is a new command syntax I can see this being acceptable, as > long as the old syntax still works correctly. However, the > performance data part will be a problem to current parsers since I'd > like to redefine the meaning of warn and crit. > > One option is that the new perf data is outputted in XML format. This > might help with structural changes in future. This also ties in with > a request from Gerd Muller of Netways at NagConf where he wanted some > metadata re: the plugin to be available (name=check_disk version=1.80). +1 on structured rather than parsed. Though I'm also less than keen on XML. Maybe YAML or JSON or something lighter instead? My 2c Aussie (from linux.conf.au 2007). Cheers Gavin From jaime_fernandez at jdv.com Tue Jan 16 02:36:57 2007 From: jaime_fernandez at jdv.com (Jaime Fernandez) Date: Tue, 16 Jan 2007 10:36:57 +0900 Subject: [Nagiosplug-devel] problems compiling new plugin versions for nagios Message-ID: Hi, I am currently having problems compiling the latest version of the nagios plugins on my RHES3 server. I am running the following SSL version: [root at nagios nagios-plugins-1.4.5]# rpm -qa |grep openssl openssl-0.9.7a-33.21 openssl-devel-0.9.7a-33.21 [root at nagios nagios-plugins-1.4.5]# cat /etc/redhat-release Red Hat Enterprise Linux ES release 3 (Taroon Update 6) I get the error message below when i run the make command after a successfully compiling the plugins with SSL support: then mv -f ".deps/netutils.Tpo" ".deps/netutils.Po"; else rm -f ".deps/netutils.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/local/ssl/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/root/nagios-plugins-1.4.5/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x37): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x98): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xc0): In function `dlfcn_load': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x141): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x16c): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x229): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x254): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x512): In function `dlfcn_unload': : undefined reference to `dlclose' collect2: ld returned 1 exit status make[2]: *** [check_http] Error 1 make[2]: Leaving directory `/root/nagios-plugins-1.4.5/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/nagios-plugins-1.4.5' make: *** [all] Error 2 You help would be greatly appreciated. Thanks, Jaime Fernandez System Administrator JDV Limited ABN 67 009 136 029 Level 7, 141 St Georges Terrace Perth WA Australia 6000 Phone: +61 8 9268 2766 Fax: +61 8 9266 0200 Mobile: 0411 685 720 Email: jaime_fernandez at jdv.com Visit our corporate website: www.jdv.com ------------------------------------------------------------------------------------------------------------------------------ This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply to us immediately and delete the document. It is the recipient's duty to virus-scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. JDV Limited does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. JDV Limited, and each of its related companies each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of JDV Limited. Your private information is only used and disclosed for the intention which you have provided it for. This information is not disclosed or used unless your consent has been provided or in the case that JDV Limited is permitted to do so under the Privacy Act of 1988. ----------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Tue Jan 16 12:35:14 2007 From: jfenal at gmail.com (=?UTF-8?Q?J=C3=A9r=C3=B4me_Fenal?=) Date: Tue, 16 Jan 2007 12:35:14 +0100 Subject: [Nagiosplug-devel] problems compiling new plugin versions for nagios In-Reply-To: References: Message-ID: <40a14bc10701160335i6f1e19cn1466f2d971b0e8eb@mail.gmail.com> 2007/1/16, Jaime Fernandez : > > > Hi, > > I am currently having problems compiling the latest version of the nagios > plugins on my RHES3 server. > I am running the following SSL version: > > [root at nagios nagios-plugins-1.4.5]# rpm -qa |grep openssl > openssl-0.9.7a-33.21 > openssl-devel-0.9.7a-33.21 > [root at nagios nagios-plugins-1.4.5]# cat /etc/redhat-release > Red Hat Enterprise Linux ES release 3 (Taroon Update 6) > > > I get the error message below when i run the make command after a > successfully compiling the plugins with SSL support: > > then mv -f ".deps/netutils.Tpo" ".deps/netutils.Po"; else rm -f > ".deps/netutils.Tpo"; exit 1; fi > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L. > -L/usr/local/ssl/lib -o check_http check_http.o sslutils.o netutils.o > utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl > -lcrypto > gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o > -L/root/nagios-plugins-1.4.5/plugins -L/usr/local/ssl/lib > ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto Add -ldl at the end of the compiler flags, and you should be OK. Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ From ae at op5.se Tue Jan 16 14:34:55 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 16 Jan 2007 14:34:55 +0100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> Message-ID: <45ACD47F.4030508@op5.se> Ton Voon wrote: > Hi! > > I'm canvassing opinions for this change to the developer guidelines re: > command arguments to thresholds. I first brought this up at the Nagios > Conference in Germany > (http://www.netways.de/de/nagios_konferenz/archiv_2006/programm/nagios_plugins/), > but want to make sure there is a consensus in this mailing list. > > > BACKGROUND > > There are three main problems: > > 1) when you have a check that wants to check multiple "things", the > syntax is confusing. For example, free disk space in check_disk is -w/-c > (in units or percent), but inode checking is -W/-K. In check_http, -w/-c > is for time taken, -m is for page size. This is not very readable and > inconsistent > > 2) the output and performance data is inconsistent with what is being > checked. For instance, if I check my disks for inodes, I don't > necessarily want perf data returned about disk free. This clogs up my > graphs and muddies my output > > 3) I've started using common routines for threshold parsing and found > that the way that parsing occurs between plugins is inconsistent. For > instance, check_procs -c 1:1 means "critical if not 1 process". However, > check_disk -c 5% means "critical if between 0 and 5%". Worse, the way > the guidelines define ranges so the default is to alert outside a range, > which looks wrong. > > I did this test to the audience at the Nagios Conference. Given a > command 'check_stuff -w 30:50 -c 10:30' where the result of "stuff" is > 15, what is the alert level raised? > > Go on, have a guess! > > The answer is Warning. I had two guesses of "Critical" by the crowd and > I think this is because you immediately assume an alert **within** the > range, not outside. I think this needs fixing. > I disagree, but see below. > > > PROPOSAL > > So my proposal is to have a different, but complementary, method of > specifying thresholds: > > --metric=crit/warn > Using '/' for argument separation makes it look completely insane when dealing with numerical thresholds. I'd much rather just abuse the common comma instead, and put warning before critical on the basis that it feels more right if the lower value comes first (which it will most of the time, I suspect). Otherwise it's a nice idea. > The crit and warn ranges are defined as min:max (max is optional, > defaults to +infinity). Alert if the checked value is inside this range. > If you want to alert on the outside of this range, prefix the range with > a carat sign (^). > Swapping the meaning of ranges around is just pure daft, because whether you want the value to be inside or outside the range is all down to context. When checking process counts, temperature, humidity you want the measured metric to be inside the ranges to be considered OK. I'm not really sure what kind of measured value you'd want to be outside the ranges to be considered OK, so this only holds true when you look at the argument without knowing what you're checking. It *might* be considered a bug that the warning range doesn't necessarily have to be "inside" the critical range, but that's just an implementation detail. > Crit or warn can be blank, meaning no alert to be specified for that > alert level. > > If the metric is specified, then output + perfdata will reflect. Eg, > check_http --page_size=60K/40K --document_age=5s/3s will give output of > the document age and the page size, but not the certificate age or the > time taken. If you want output and perfdata without checking the result, > specify the metric without any values, eg check_http --certificate_age. > > I think the metric name should be composed of alphanumerics and > underscore only, so it can map to RRD names. If there is a many-to-many > mapping (eg, check_disk, looking at per mountpoint), use a key prefixed > at the beginning with a separating colon, eg check_disk --disk_free=2GB > --inode_used=/0:500 -p / -p /var would have perf output of: > > /:disk_free=1.3GB;;2 /:inode_used=433;0:500; /var:disk_free=0.7GB;;2 > /var:inode_used=700;0:500; > > Whatever processes the perf data can decide how to use the prefix (save > to a separate RRD?). > Sounds sensible. Personally, I'd tack a massaged version of the disk-partition (or mountpoint) to the metric in the performance-data, so the above would be something like /_disk_free=... /_inode_used=.... /var_disk_free=... This way it can still be used in a single RRD-file without the parser having to modify it (I'm assuming RRD can handle / here). > > > COMPLICATIONS > > As this is a new command syntax I can see this being acceptable, as long > as the old syntax still works correctly. However, the performance data > part will be a problem to current parsers since I'd like to redefine the > meaning of warn and crit. > So long as things stay backwards compatible I have no objections. I'm not sure what you mean by "re-defining the meaning of warn and crit", as you haven't mentioned anything about it earlier. > One option is that the new perf data is outputted in XML format. This > might help with structural changes in future. This also ties in with a > request from Gerd Muller of Netways at NagConf where he wanted some > metadata re: the plugin to be available (name=check_disk version=1.80). > > > Any opinions? > XML output is not a good idea. <> sequences passed to the shell will play merry hell with peoples filesystems and result in seriously strange errors. Even though XML is supposed to be human-readable, it really isn't. There's no reason why plugin_name and plugin_version can't be in the perf-data output as it is today. Just consign the plugin_ prefix to be protected for meta-data in performance output. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Tue Jan 16 14:38:25 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 16 Jan 2007 14:38:25 +0100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: <20070116025312.GA28666@openfusion.com.au> References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> <20070116025312.GA28666@openfusion.com.au> Message-ID: <45ACD551.2020603@op5.se> Gavin Carr wrote: > I think --page_size looks silly compared > to --page-size - what do others think? > Agreed. nmap has completely gone from the former to the latter. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Wed Jan 17 06:30:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jan 2007 21:30:03 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1630970 ] Fix for buffer overflow of check_procs procprog string Message-ID: Bugs item #1630970, was opened at 2007-01-08 17:51 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1630970&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jason Hoos (jhoos) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for buffer overflow of check_procs procprog string Initial Comment: Line 196 of the file check_procs.c contains a line that, if executed often enough, will cause the procprog pointer variable to run past the end of its originally-allocated buffer, which in turn causes erratic program behavior. The line in question reads: procprog = base_name(procprog); which, depending on the implementation of base_name, will either assign procprog to point to a deeper location within its original buffer, or may cause it to point to some other static memory entirely. The attached patch changes this to use: strcpy(base_name(procprog)); to avoid this problem. This solved erratic behavior on a Solaris 8 system that was using the system's 'ps' command instead of 'pst3'. This patch is related to bug 1578214, and possibly to bug 1595449 (particularly the part that recommends changing MAX_INPUT_BUFFER to 4096). ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-17 00:30 Message: Logged In: YES user_id=375623 Originator: NO Thanks. It's now fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1630970&group_id=29880 From noreply at sourceforge.net Wed Jan 17 06:34:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jan 2007 21:34:28 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1578214 ] check_procs from crashes on Itanium2 SLES10 Message-ID: Bugs item #1578214, was opened at 2006-10-16 10:23 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1578214&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: wszenajch (wszenajch) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs from crashes on Itanium2 SLES10 Initial Comment: check_procs from HEAD-20061015 build crashes on Itanium2 SLES10. Line192: procprog = base_name(procprog); of check_procs.c is used incorrectly. With this line as it is compilation gives the following warning on all tested by me platforms: OpenSuSE 10.1 i386, SuSE 10.0 x86_64, SLES10 ia64, AIX 5.2: check_procs.c: In function `main': check_procs.c:192: warning: assignment makes pointer from integer without a cast but crashes only on Itanium2 platform. To fix problem comment out line: procprog = base_name(procprog); or use construction from 1.4.3 plugins (which was probably not active): main ... ... char *temp_string; ... temp_string = strdup(procprog); procprog = basename(temp_string); According to man 3 basename: "Both dirname() and basename() may modify the contents of path, so copies should be passed to these functions. Furthermore, dirname() and basename() may return pointers to statically allocated memory whi ch may be overwritten by subsequent calls." ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-17 00:34 Message: Logged In: YES user_id=375623 Originator: NO This was fixed in CVS using the strcpy function (1630970). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1578214&group_id=29880 From noreply at sourceforge.net Wed Jan 17 06:37:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jan 2007 21:37:53 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1595449 ] check_procs bus error, ... on Solaris 8, 9 & 10 Message-ID: Bugs item #1595449, was opened at 2006-11-13 03:23 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs bus error, ... on Solaris 8, 9 & 10 Initial Comment: check_procs bus error, segmentation fault or wrong output on Solaris 8, 9 & 10 Do first the next configure! ---------------------------- ./configure --with-ps_command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps_format='%s %d %d %d %d %d %f %s %s %n' --with-ps_cols=10 --with-ps_varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' --with-trusted-path=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin To solve the bus error and /or segmentation fault on Solaris 8: -------------------------------------------------- replace into check_procs.c if ( cols >= expected_cols ) { resultsum = 0; - asprintf (&procargs, "%s", input_line + pos); strip (procargs); with if ( cols >= expected_cols ) { resultsum = 0; + asprintf (&procargs, "%s", input_line); strip (procargs); To solve the wrong output on Solaris 8, 9 & 10: ----------------------------------------------- change into common.h MAX_INPUT_BUFFER 1024 to MAX_INPUT_BUFFER 4096 ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-17 00:37 Message: Logged In: YES user_id=375623 Originator: NO The wrong output bug should be fixed (1630970). I (or somebody else) will have to look further for the bus error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 From noreply at sourceforge.net Wed Jan 17 15:33:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 17 Jan 2007 06:33:18 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1637767 ] check_ping 1.4.5 on FreeBSD 5.4 fails Message-ID: Bugs item #1637767, was opened at 2007-01-17 17:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pentarh Udi (pentarh) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping 1.4.5 on FreeBSD 5.4 fails Initial Comment: Says "Could not open pipe: " for any command arguments. After some researching I found that "configure" script did not created appropriate defines as well. It only created #define PING_COMMAND="" So after patching config.h, removing the define above and placing following defines i get it worked: #define PING_COMMAND "/sbin/ping -t %u -c %u %s" #define PING_HAS_TIMEOUT #define PING_PACKETS_FIRST ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1637767&group_id=29880 From noreply at sourceforge.net Thu Jan 18 04:20:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 17 Jan 2007 19:20:04 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: <200701180320.l0I3K4B6008754@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1614164, was opened at 2006-12-12 09:38 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&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: alexus (a1exus) Assigned to: Ton Voon (tonvoon) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-01-17 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-01-03 01:50 Message: Logged In: YES user_id=664364 Originator: NO Alexus, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot? There has been a fix to the generation of alloca.h. Ton ---------------------------------------------------------------------- Comment By: alexus (a1exus) Date: 2006-12-26 07:13 Message: Logged In: YES user_id=227889 Originator: YES this is what i did for "work-around" alexus at d:/usr/local/src/nagios-plugins-1.4.5> cd lib alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ls -la alloca.h lrwxr-xr-x 1 root wheel 34 Dec 12 22:39 alloca.h -> /usr/src/gnu/usr.bin/sort/alloca.h alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ---------------------------------------------------------------------- Comment By: David (daspez) Date: 2006-12-26 00:13 Message: Logged In: YES user_id=1676837 Originator: NO Try compiling using the "--without-included-regex" parameter. I have had the same issue under FreeBSD 5.5 and it compiles using the above paramter. HIH. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From WebMonster at idsa.ch Thu Jan 18 08:32:26 2007 From: WebMonster at idsa.ch (Francois Pernet) Date: Thu, 18 Jan 2007 08:32:26 +0100 Subject: [Nagiosplug-devel] check_nwstat: Feature requested References: <45ADD325.50F3.00AE.0@idsa.ch> <45AF1148.50F3.00AE.0@idsa.ch> <45AF129F.50F3.00AE.0@idsa.ch> Message-ID: <45AF309C.50F3.00AE.0@idsa.ch> Hi, We have Nagios installed and monitoring many netware servers. It works fine. However, in some cases, when server beocme really busy (CPU is 100%) the agent (MRTG.NLM) is not able to answer to Nagios through check_nwstat. In fact, the checks return CRITICAL status but with the following info : CRITICAL SOCKET TIMEOUT I know that we can increase the timeout but I would like to know (and I guess that should be the normal behaviour) the check_nwstat should return error code 3 : UNKNOWN in such situations. The advantage is that therefore, we can manage differently these knids of errors through notifications (for instance in order to not send SMS but only mails). What is your opinion ? Many Thx in advance Francois From ae at op5.se Thu Jan 18 14:00:06 2007 From: ae at op5.se (Andreas Ericsson) Date: Thu, 18 Jan 2007 14:00:06 +0100 Subject: [Nagiosplug-devel] check_nwstat: Feature requested In-Reply-To: <45AF309C.50F3.00AE.0@idsa.ch> References: <45ADD325.50F3.00AE.0@idsa.ch> <45AF1148.50F3.00AE.0@idsa.ch> <45AF129F.50F3.00AE.0@idsa.ch> <45AF309C.50F3.00AE.0@idsa.ch> Message-ID: <45AF6F56.9070102@op5.se> Francois Pernet wrote: > Hi, > > We have Nagios installed and monitoring many netware servers. It works fine. However, in some cases, when server beocme really busy (CPU is 100%) the agent (MRTG.NLM) is not able to answer to Nagios through check_nwstat. In fact, the checks return CRITICAL status but with the following info : > CRITICAL SOCKET TIMEOUT > > I know that we can increase the timeout but I would like to know (and I guess that should be the normal behaviour) the check_nwstat should return error code 3 : UNKNOWN in such situations. The advantage is that therefore, we can manage differently these knids of errors through notifications (for instance in order to not send SMS but only mails). > > What is your opinion ? > Some plugins accept '-T Unknown' (or --on-timeout=UNKNOWN) to do just that. I'm not sure if check_nwstat is among them, but it's definitely worth checking. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From WebMonster at idsa.ch Thu Jan 18 14:46:53 2007 From: WebMonster at idsa.ch (Francois Pernet) Date: Thu, 18 Jan 2007 14:46:53 +0100 Subject: [Nagiosplug-devel] check_nwstat: Feature requested In-Reply-To: <45AF6F56.9070102@op5.se> References: <45ADD325.50F3.00AE.0@idsa.ch> <45AF1148.50F3.00AE.0@idsa.ch> <45AF129F.50F3.00AE.0@idsa.ch> <45AF309C.50F3.00AE.0@idsa.ch><45AF309C.50F3.00AE.0@idsa.ch> <45AF6F56.9070102@op5.se> Message-ID: <45AF885E.50F3.00AE.0@idsa.ch> Hi, Thanks Andreas...I'm glad to know that somebody thought about this kind of situations. Unfortunatly this plugin does not support this kind of feature so I would like to know if it is possible to implement it in the futur version (this could avoid me to create shellscript)... Thx again Francois >>> Andreas Ericsson 18.01.2007 14:00 >>> Francois Pernet wrote: > Hi, > > We have Nagios installed and monitoring many netware servers. It works fine. However, in some cases, when server beocme really busy (CPU is 100%) the agent (MRTG.NLM) is not able to answer to Nagios through check_nwstat. In fact, the checks return CRITICAL status but with the following info : > CRITICAL SOCKET TIMEOUT > > I know that we can increase the timeout but I would like to know (and I guess that should be the normal behaviour) the check_nwstat should return error code 3 : UNKNOWN in such situations. The advantage is that therefore, we can manage differently these knids of errors through notifications (for instance in order to not send SMS but only mails). > > What is your opinion ? > Some plugins accept '-T Unknown' (or --on-timeout=UNKNOWN) to do just that. I'm not sure if check_nwstat is among them, but it's definitely worth checking. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ 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 ton.voon at altinity.com Thu Jan 18 17:56:20 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 18 Jan 2007 16:56:20 +0000 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: <45ABF265.3040707@mailing.kaufland-informationssysteme.com> References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> <45ABF265.3040707@mailing.kaufland-informationssysteme.com> Message-ID: Hi all, Thanks for the feedback so far. Original post here: http:// thread.gmane.org/gmane.network.nagios.plugins.devel/4461/focus=4461 Summary: Matthias Eble suggests problems with perfdata and current performance graphing tools. Need more feedback from the graphing teams! Matthias also says output length of XML maybe a problem for < Nagios 3 systems. Good point. Matthias points out lots of current work on SF trackers. Yes, current tracker items is a big problem which I'm trying to address that. Any help always appreciated. Gavin Carr and Andreas Ericsson say that thresholds definitions could be "contextual" based on what is best for the plugin, eg, check_procs --processes=^1:1 to mean alert outside is . I think consistency is better - any more thoughts? Gavin and Andreas suggest that metric names are defined on command line with "-", but mapped to "_" in perf data output. I'm fine with that unless anyone objects. Gavin agrees with structured data, but suggests yaml or JSON. My feeling is that yaml is more for readable text files and doesn't work on single line output. JSON uses lots of symbols to convey its data, which I'm not sure would either be readable or easily parsed. I think the options are really XML or the current perf data style. Andreas disagrees with XML because of shell problems with "<" and ">". I guess this is for Nagios 1.x systems where perf data had to be sent via command lines. Since Nagios 2+ uses environment variables, this should be less of an issue. Andreas disagrees with the choice of "/" as the separator in -- metric=crit/warn and suggests comma instead. I want to avoid a comma because, in future, I can see ranges will be defined with comma to mean other ranges, such as current page ranges: 1-6,9. Also, I'd like to keep the crit and warn definition in the same syntax argument, rather than separating out to --metric-crit and --metric-warn. I'm all for a different delimiter if it makes sense and doesn't clash. I avoided semi-colon because of the shell meaning. Andreas suggests warn comes before crit. I favoured crit first because it is more important than warn, but I'm not fixed to this. Any other thoughts? Andreas suggests sticking plugin name and version in the current perf data format as reserved words. Good idea. There's no major disagreements about a more consistent syntax required for thresholds, so that sounds like an "okay". I'm starting to think that, with the Nagios/NRPE output limitations, that XML is too much right now and that we need to stick to the current output style. However, I think the warn and crit sections of the current perf data output is inconsistent to the point of being useless right now, but I would need some people from the graphing teams to tell me what they think. I'll drop the emails to various lists. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From WebMonster at idsa.ch Thu Jan 18 06:24:40 2007 From: WebMonster at idsa.ch (Francois Pernet) Date: Thu, 18 Jan 2007 06:24:40 +0100 Subject: [Nagiosplug-devel] check_nwstat: Feature requested References: <45ADD325.50F3.00AE.0@idsa.ch> <45AF1148.50F3.00AE.0@idsa.ch> Message-ID: <45AF129F.50F3.00AE.0@idsa.ch> Hi, We have Nagios installed and monitoring many netware servers. It works fine. However, in some cases, when server beocme really busy (CPU is 100%) the agent (MRTG.NLM) is not able to answer to Nagios through check_nwstat. In fact, the checks return CRITICAL status but with the following info : CRITICAL SOCKET TIMEOUT I know that we can increase the timeout but I would like to know (and I guess that should be the normal behaviour) the check_nwstat should return error code 3 : UNKNOWN in such situations. The advantage is that therefore, we can manage differently these knids of errors through notifications (for instance in order to not send SMS but only mails). What is your opinion ? Many Thx in advance Francois From Thomas at zango.com Thu Jan 18 23:13:53 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 18 Jan 2007 14:13:53 -0800 Subject: [Nagiosplug-devel] Nagios:Plugin feedback Message-ID: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> I just switched two of my checks (BigIP checks I put on NagiosExchange under the name 'dermoth') to Nagios::Plugin. Since it's still brand new I though you would like to hear some feedback :) First of all it's awesome! Most of my functions and multi-line conditional statements were replaced by one-liners. Makes the code much simpler thus leaving more room for debug code and enhancements. The interface is simple yet powerful. So far I came across only two glitches: 1. Installing Nagios::Plugins with CPAN on Slackware 11.0, there's one dependency that isn't installed, Test::Exception. 2. Default shortname, 'uc basename $0', return "P1" with ePN. I'm not sure if there's a way around this, but maybe using 'uc $np->plugin' (actually it won't be that, but you get the idea) so at least if plugin is set (it was in my case) there won't be need to explicitly define shortname. Questions: Is there a is_hostname function? is_ipaddr would be useful as well. What about passing argument check code directly in the add_arg() arguments? Would look like this (Not 100% sure about the syntax, I'm not a Perl guru ): $p->add_arg( spec => 'name|n=s', help => qq{-n, --name=) check => &namecheck failure => "Name argument must me a name" ); I will release these new checks as soon as I'm done with some more stuff (supporting v9 models, adding thresholds arguments...) Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ae at op5.se Fri Jan 19 03:00:13 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 19 Jan 2007 03:00:13 +0100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> <45ABF265.3040707@mailing.kaufland-informationssysteme.com> Message-ID: <45B0262D.7040705@op5.se> Ton Voon wrote: > > Andreas disagrees with XML because of shell problems with "<" and ">". I > guess this is for Nagios 1.x systems where perf data had to be sent via > command lines. Since Nagios 2+ uses environment variables, this should > be less of an issue. > Perhaps, but there's also a limit on how much data you can chuck into the environment. For the "small" plugins, I imagine this isn't a problem, but for those the current perf-data output already works very nicely, so I'm guessing this is for checking something like disk usage on systems with loads and loads of mounted disks. > Andreas disagrees with the choice of "/" as the separator in > --metric=crit/warn and suggests comma instead. I want to avoid a comma > because, in future, I can see ranges will be defined with comma to mean > other ranges, such as current page ranges: 1-6,9. Also, I'd like to keep > the crit and warn definition in the same syntax argument, rather than > separating out to --metric-crit and --metric-warn. I'm all for a > different delimiter if it makes sense and doesn't clash. I avoided > semi-colon because of the shell meaning. > I had assumed you wouldn't use ranges with crit/warn syntax, as those are generally hard enough to read anyways, especially if you're going to use multi-parameter ranges as suggested above. You'll end up with command_line variables looking like this 100/50!^15:25/^5:15,25:35 which is as readily readable as this little gem sed '1!G;h;$!d' and definitely not something you want to find lurking at line 839 at when you're looking for errors. > > I'm starting to think that, with the Nagios/NRPE output limitations, > that XML is too much right now and that we need to stick to the current > output style. However, I think the warn and crit sections of the current > perf data output is inconsistent to the point of being useless right > now, but I would need some people from the graphing teams to tell me > what they think. I'll drop the emails to various lists. > I've got a pretty good feeling about what they'll say: "You better make this change on a flag-day, cause everything will break". Otoh, I assume this would mean a 2.0 release of the plugins, so that'd be a sort of flag-day in and of itself. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Fri Jan 19 03:12:27 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 19 Jan 2007 03:12:27 +0100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> Message-ID: <45B0290B.2040301@op5.se> Thomas Guyot-Sionnest wrote: > I just switched two of my checks (BigIP checks I put on NagiosExchange under > the name 'dermoth') to Nagios::Plugin. Since it's still brand new I though > you would like to hear some feedback :) > > First of all it's awesome! Most of my functions and multi-line conditional > statements were replaced by one-liners. Makes the code much simpler thus > leaving more room for debug code and enhancements. The interface is simple > yet powerful. > > Questions: > > Is there a is_hostname function? is_ipaddr would be useful as well. This is a common misconception and thoroughly annoying when encountered. Resolver functions already recognize IP-addresses and return them immediately in case one is passed to them as a hostname, so detecting if something is a valid ip-address or not is not necessary. Properly detecting if something is a valid hostname is an equally bogus activity, because people invariably make such functions overly strict. Again, the resolver will tell you if the name you chuck at it resolves to an IP-address or not, and that's really all you need to know. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From dermoth at aei.ca Fri Jan 19 03:40:45 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 18 Jan 2007 21:40:45 -0500 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <45B0290B.2040301@op5.se> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <45B0290B.2040301@op5.se> Message-ID: <45B02FAD.7010606@aei.ca> On 18/01/07 09:12 PM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >> I just switched two of my checks (BigIP checks I put on NagiosExchange under >> the name 'dermoth') to Nagios::Plugin. Since it's still brand new I though >> you would like to hear some feedback :) >> >> First of all it's awesome! Most of my functions and multi-line conditional >> statements were replaced by one-liners. Makes the code much simpler thus >> leaving more room for debug code and enhancements. The interface is simple >> yet powerful. >> >> Questions: >> >> Is there a is_hostname function? is_ipaddr would be useful as well. > > This is a common misconception and thoroughly annoying when encountered. > Resolver functions already recognize IP-addresses and return them > immediately in case one is passed to them as a hostname, so detecting if > something is a valid ip-address or not is not necessary. That one actually isn't. In the particular script I was talking about I'm embedding an IP address into an OID, so that would be a good check. Same if you write a DNS check and when to match against an IP address. But it's also true that Nagios::Plugins shouldn't drive ppl into bad habits. I think I was too lazy to write something like '(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})' then check the range for $1, $2, $3 and $4 :) > Properly detecting if something is a valid hostname is an equally bogus > activity, because people invariably make such functions overly strict. > Again, the resolver will tell you if the name you chuck at it resolves > to an IP-address or not, and that's really all you need to know. > True and false. While a resolver will chuck on any badly-formated hostname, it's not bad practice when passing a hostname to a program to make sure it doesn't contain any shell-interpretable character. Ok, you make a point there. Can we have a is_shellclean function? :) Thomas From gavin at openfusion.com.au Fri Jan 19 04:46:58 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 19 Jan 2007 14:46:58 +1100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> Message-ID: <20070119034658.GA7415@openfusion.com.au> On Thu, Jan 18, 2007 at 02:13:53PM -0800, Thomas Guyot-Sionnest wrote: > I just switched two of my checks (BigIP checks I put on NagiosExchange under > the name 'dermoth') to Nagios::Plugin. Since it's still brand new I though > you would like to hear some feedback :) Absolutely! > First of all it's awesome! Most of my functions and multi-line conditional > statements were replaced by one-liners. Makes the code much simpler thus > leaving more room for debug code and enhancements. The interface is simple > yet powerful. Great, thanks. > So far I came across only two glitches: > > 1. Installing Nagios::Plugins with CPAN on Slackware 11.0, there's one > dependency that isn't installed, Test::Exception. Thanks - fixed in CVS. > 2. Default shortname, 'uc basename $0', return "P1" with ePN. Yes. Ethan has applied a patch to ePN to workaround this in CVS, I believe. > I'm not sure > if there's a way around this, but maybe using 'uc $np->plugin' (actually it > won't be that, but you get the idea) so at least if plugin is set (it was in > my case) there won't be need to explicitly define shortname. Yes, that's sensible too. I need to look at cleaning up the interaction between plugin and shortname. > Is there a is_hostname function? is_ipaddr would be useful as well. > What about passing argument check code directly in the add_arg() arguments? > > Would look like this (Not 100% sure about the syntax, I'm not a Perl guru ): > $p->add_arg( > spec => 'name|n=s', > help => qq{-n, --name=) > check => &namecheck > failure => "Name argument must me a name" > ); My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, largely because it's pretty well covered already in other CPAN modules. The idea of adding explicit checks to arguments is interesting though. I'll have to think about that. If we did this, we'd presumably want an interface that would allow multiple checks and messages though, I guess? Cheers, Gavin -- Gavin Carr - http://www.openfusion.com.au - Linux, Perl, and Web Consulting - http://www.xool.com.au - Xool, Australian property search engine * Fashion is a variable, but style is a constant - Programming Perl From dermoth at aei.ca Fri Jan 19 06:09:51 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 19 Jan 2007 00:09:51 -0500 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <20070119034658.GA7415@openfusion.com.au> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> Message-ID: <45B0529F.7010309@aei.ca> On 18/01/07 10:46 PM, Gavin Carr wrote: > On Thu, Jan 18, 2007 at 02:13:53PM -0800, Thomas Guyot-Sionnest wrote: >> >> Would look like this (Not 100% sure about the syntax, I'm not a Perl guru ): >> $p->add_arg( >> spec => 'name|n=s', >> help => qq{-n, --name=) >> check => &namecheck >> failure => "Name argument must me a name" >> ); > > My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, > largely because it's pretty well covered already in other CPAN modules. > > The idea of adding explicit checks to arguments is interesting though. > I'll have to think about that. If we did this, we'd presumably want > an interface that would allow multiple checks and messages though, I > guess? Oh BTW I meant : check => &$namecheck Though I think you can also do this (right?): check => sub { yada yada yada; if true return 1; return 0 } I'm not good at that kind of Perl programming, but can you check whenever you get a scalar or an array? A good compromise would be: if $failure is a scalar, then just test the sub ($check). if test fails (return 0) exit with $failure text. if $failure is an array, test the sub ($ret being the return code). If $failure[$ret] is defined, exit with failure[$ret] text I.e.: $p->add_arg( spec => 'name|n=s', help => qq{-n, --name=) check => sub { if bad return 1; if invalid return 2; return 0 }, failure => (undef, 'Bad name', 'Invalid name'), ); What do you think? Do you have a better idea? Thomas From gavin at openfusion.com.au Fri Jan 19 07:08:06 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 19 Jan 2007 17:08:06 +1100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <45B0529F.7010309@aei.ca> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> <45B0529F.7010309@aei.ca> Message-ID: <20070119060806.GA7902@openfusion.com.au> On Fri, Jan 19, 2007 at 12:09:51AM -0500, Thomas Guyot-Sionnest wrote: > Oh BTW I meant : > > check => &$namecheck You meant: check => \&namecheck > Though I think you can also do this (right?): > > check => sub { yada yada yada; if true return 1; return 0 } Right. > I'm not good at that kind of Perl programming, but can you check > whenever you get a scalar or an array? Sure. > A good compromise would be: > > if $failure is a scalar, then just test the sub ($check). if test fails > (return 0) exit with $failure text. > > if $failure is an array, test the sub ($ret being the return code). If > $failure[$ret] is defined, exit with failure[$ret] text > > I.e.: > > $p->add_arg( > spec => 'name|n=s', > help => qq{-n, --name=) > check => sub { if bad return 1; if invalid return 2; return 0 }, > failure => (undef, 'Bad name', 'Invalid name'), > ); > > What do you think? Do you have a better idea? I guess I'm not sure this actually adds much. Why not just do your checks after the argument parsing: die "Bad name\n" if bad($p->name); die "Invalid name\n" if invalid($p->name); etc.? Cheers, Gavin -- Gavin Carr - http://www.openfusion.com.au - Linux, Perl, and Web Consulting - http://www.xool.com.au - Xool, Australian property search engine * Fashion is a variable, but style is a constant - Programming Perl From ton.voon at altinity.com Fri Jan 19 10:05:21 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 19 Jan 2007 09:05:21 +0000 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <20070119034658.GA7415@openfusion.com.au> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> Message-ID: On 19 Jan 2007, at 03:46, Gavin Carr wrote: >> Is there a is_hostname function? is_ipaddr would be useful as well. >> What about passing argument check code directly in the add_arg() >> arguments? >> > > My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, > largely because it's pretty well covered already in other CPAN > modules. Agreed. CPAN is about reusing other bits of code. However, some pointers to "good implementations" in CPAN might be helpful. Longer term, we probably need to think about how to handle module dependencies for a given check_* script. Distributing a plugin to 100 boxes might prove problematic if there is a large list of dependencies. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From klausman at schwarzvogel.de Fri Jan 19 13:25:43 2007 From: klausman at schwarzvogel.de (Tobias Klausmann) Date: Fri, 19 Jan 2007 13:25:43 +0100 Subject: [Nagiosplug-devel] Patch for leading whitespace on comments Message-ID: <20070119122543.GA16248@eric.schwarzvogel.de> Hi! As of 2.6, Nagios recognizes leading whitespace only in the main config file. The attached patch fixes this. To illustrate, this piece of config does not work currently: define host { host_name eric.schwarzvogel.de alias eric.schwarzvogel.de address 194.97.4.250 #check_command check_host_alive check_command check_host_new max_check_attempts 3 retain_status_information 1 contact_groups Privat Klausmann notification_interval 30 notification_period 24x7 notification_options d,u,r passive_checks_enabled 1 } The reason is the commented-out check_command line. It would work like this: define host { ... # check_command check_host_alive check_command check_host_new ... } This is because (for non-main config files), Nagios first checks if the first char is "#" and *then* strips the line. For the main config file, this happens the other way around. I've attached a patch that makes this behaviour more consistent. I believe the check for '\0', '\n' etc. could be simplified to, *if* strip() removes some of the chars. I tried to be non-invasive as possible, so I didn't do that. I'd like it if this patch makes it into the 2.x series. Regards, Tobias -------------- next part -------------- --- base/config.c.orig 2007-01-19 13:15:52.000000000 +0100 +++ base/config.c 2007-01-19 13:17:00.000000000 +0100 @@ -1518,12 +1518,15 @@ current_line=thefile->current_line; + /* Strip line first so that a hash preceded by + * only whitespace is treated correctly + */ + strip(input); + /* skip blank lines and comments */ if(input[0]=='#' || input[0]=='\x0' || input[0]=='\n' || input[0]=='\r') continue; - strip(input); - /* get the variable name */ temp_ptr=my_strtok(input,"="); From dermoth at aei.ca Fri Jan 19 13:27:44 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 19 Jan 2007 07:27:44 -0500 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> Message-ID: <45B0B940.2040803@aei.ca> On 19/01/07 04:05 AM, Ton Voon wrote: > > On 19 Jan 2007, at 03:46, Gavin Carr wrote: > >>> Is there a is_hostname function? is_ipaddr would be useful as well. >>> >>> What about passing argument check code directly in the add_arg() >>> arguments? >>> >>> >> >> My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, >> >> largely because it's pretty well covered already in other CPAN modules. >> > > Agreed. CPAN is about reusing other bits of code. However, some pointers > to "good implementations" in CPAN might be helpful. > > Longer term, we probably need to think about how to handle module > dependencies for a given check_* script. Distributing a plugin to 100 > boxes might prove problematic if there is a large list of dependencies. There's many useful functions in the C API for Nagios plugins. I believe it wouldn't be a bad idea to have the same kind of function directly into Nagios::Plugin. By minimizing the use of external modules, you simplify plugin deployment. Nagios::Plugin could itself load external modules to do the checks, but those dependencies would be installed along with Nagios::Plugin. What I'm starting to realize is that there's nothing to check the validity of arguments. In C you have all those functions: is_integer is_intpos is_intneg is_intnonneg is_intpercent is_numeric is_positive is_negative is_nonnegative is_percentage Thomas From dermoth at aei.ca Fri Jan 19 13:27:51 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 19 Jan 2007 07:27:51 -0500 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <20070119060806.GA7902@openfusion.com.au> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> <45B0529F.7010309@aei.ca> <20070119060806.GA7902@openfusion.com.au> Message-ID: <45B0B947.2080309@aei.ca> On 19/01/07 01:08 AM, Gavin Carr wrote: > On Fri, Jan 19, 2007 at 12:09:51AM -0500, Thomas Guyot-Sionnest wrote: >> Oh BTW I meant : >> >> check => &$namecheck > > You meant: check => \&namecheck I guess so ;) >> [...] >> >> if $failure is a scalar, then just test the sub ($check). if test fails >> (return 0) exit with $failure text. >> >> if $failure is an array, test the sub ($ret being the return code). If >> $failure[$ret] is defined, exit with failure[$ret] text >> >> I.e.: >> >> $p->add_arg( >> spec => 'name|n=s', >> help => qq{-n, --name=) >> check => sub { if bad return 1; if invalid return 2; return 0 }, >> failure => (undef, 'Bad name', 'Invalid name'), >> ); >> >> What do you think? Do you have a better idea? > > I guess I'm not sure this actually adds much. Why not just do your checks > after the argument parsing: > > die "Bad name\n" if bad($p->name); > die "Invalid name\n" if invalid($p->name); Thats true and users could have the choice. I believe my proposal encourage cleaner code as people will more likely write subs to check arguments. It will also encourage users to test the arguments as they define them, or to keep appropriate check code when taking code from others plugins. Let's say there's a is_shellchean function (as I suggested in another reply), one could write: $p->add_arg( spec => 'name|n=s', help => '-n, --name=', check => sub { shift; return 1 if (is_shellclean); return 0 }, failure => 'Name must not contain any shell reserved characters.', ); When you see the definition for --name, you see right away what check is ran against it. Thomas From ton.voon at altinity.com Fri Jan 19 13:54:48 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 19 Jan 2007 12:54:48 +0000 Subject: [Nagiosplug-devel] Patch for leading whitespace on comments In-Reply-To: <20070119122543.GA16248@eric.schwarzvogel.de> References: <20070119122543.GA16248@eric.schwarzvogel.de> Message-ID: <4CECCAA9-2C63-4C56-B7DB-0926B5B4A22A@altinity.com> Sorry Tobias, wrong mailing list. You want nagios-devel. On 19 Jan 2007, at 12:25, Tobias Klausmann wrote: > Hi! > > As of 2.6, Nagios recognizes leading whitespace only in the main > config file. The attached patch fixes this. > > To illustrate, this piece of config does not work currently: > > define host { > host_name eric.schwarzvogel.de > alias eric.schwarzvogel.de > address 194.97.4.250 > #check_command check_host_alive > check_command check_host_new > max_check_attempts 3 > retain_status_information 1 > contact_groups Privat Klausmann > notification_interval 30 > notification_period 24x7 > notification_options d,u,r > passive_checks_enabled 1 > } > > The reason is the commented-out check_command line. It would work > like this: > > define host { > ... > # check_command check_host_alive > check_command check_host_new > ... > } > > This is because (for non-main config files), Nagios first checks > if the first char is "#" and *then* strips the line. For the main > config file, this happens the other way around. > > I've attached a patch that makes this behaviour more consistent. > I believe the check for '\0', '\n' etc. could be simplified to, > *if* strip() removes some of the chars. I tried to be > non-invasive as possible, so I didn't do that. > > I'd like it if this patch makes it into the 2.x series. > > Regards, > Tobias http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Fri Jan 19 14:55:39 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 19 Jan 2007 14:55:39 +0100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <45B0B940.2040803@aei.ca> References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> <45B0B940.2040803@aei.ca> Message-ID: <45B0CDDB.9050200@op5.se> Thomas Guyot-Sionnest wrote: > On 19/01/07 04:05 AM, Ton Voon wrote: >> On 19 Jan 2007, at 03:46, Gavin Carr wrote: >> >>>> Is there a is_hostname function? is_ipaddr would be useful as well. >>>> >>>> What about passing argument check code directly in the add_arg() >>>> arguments? >>>> >>>> >>> My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, >>> >>> largely because it's pretty well covered already in other CPAN modules. >>> >> Agreed. CPAN is about reusing other bits of code. However, some pointers >> to "good implementations" in CPAN might be helpful. >> >> Longer term, we probably need to think about how to handle module >> dependencies for a given check_* script. Distributing a plugin to 100 >> boxes might prove problematic if there is a large list of dependencies. > > There's many useful functions in the C API for Nagios plugins. I believe > it wouldn't be a bad idea to have the same kind of function directly > into Nagios::Plugin. By minimizing the use of external modules, you > simplify plugin deployment. > > Nagios::Plugin could itself load external modules to do the checks, but > those dependencies would be installed along with Nagios::Plugin. > > What I'm starting to realize is that there's nothing to check the > validity of arguments. In C you have all those functions: > > is_integer > is_intpos > is_intneg > is_intnonneg > is_intpercent > is_numeric > is_positive > is_negative > is_nonnegative > is_percentage > Please, pretty please, don't mention those. They are extremely bad examples of C programming. ALL of them can, even from the callers perspective be replaced with shorter versions that are already C89 compliant. Most of them also duplicate checks already implemented in the libc functions and *NONE* of them return the computed value to the caller. Each time you see one of those functions used, you will know for a fact that several operations are carried out at least twice. It's usually worse than that, because it's often done in subtly (and pointless) different ways that the compiler can't optimize away. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From Thomas at zango.com Fri Jan 19 16:53:54 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 19 Jan 2007 07:53:54 -0800 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <45B0CDDB.9050200@op5.se> Message-ID: <804160344192334BB21922E8082EA6C0487AB9@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Andreas Ericsson > Sent: January 19, 2007 8:56 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Nagios:Plugin feedback > > Thomas Guyot-Sionnest wrote: > > > > There's many useful functions in the C API for Nagios > plugins. I believe > > it wouldn't be a bad idea to have the same kind of function directly > > into Nagios::Plugin. By minimizing the use of external modules, you > > simplify plugin deployment. > > > > Nagios::Plugin could itself load external modules to do the > checks, but > > those dependencies would be installed along with Nagios::Plugin. > > > > What I'm starting to realize is that there's nothing to check the > > validity of arguments. In C you have all those functions: > > > > is_integer > > is_intpos > > is_intneg > > is_intnonneg > > is_intpercent > > is_numeric > > is_positive > > is_negative > > is_nonnegative > > is_percentage > > > > Please, pretty please, don't mention those. They are > extremely bad examples > of C programming. ALL of them can, even from the callers perspective > be replaced with shorter versions that are already C89 compliant. > > Most of them also duplicate checks already implemented in the > libc functions > and *NONE* of them return the computed value to the caller. > Each time you see > one of those functions used, you will know for a fact that > several operations > are carried out at least twice. It's usually worse than that, > because it's often > done in subtly (and pointless) different ways that the > compiler can't optimize > away. Oh, Thanks. I'm not a very experienced Perl programmer, and even worse C programmer, so that's good to know. It would be nice then to know the replacements, and possibly start a project to clean up those (And any other that need to go) so we can eventually remove that from utils.c/h. Or is there any reason why we wouldn't want to do that? This could be for a future v2 release, among with newer style tresholds args, etc... Meanwhile the devlopper guidelines could mention which functions not to use, and the recommended replacements. I often refer to other plugins to decide how I should do things and they apparently aren't always good examples. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ae at op5.se Fri Jan 19 18:05:20 2007 From: ae at op5.se (Andreas Ericsson) Date: Fri, 19 Jan 2007 18:05:20 +0100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: <804160344192334BB21922E8082EA6C0487AB9@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C0487AB9@seaex01.180solutions.com> Message-ID: <45B0FA50.4010300@op5.se> Thomas Guyot-Sionnest wrote: >> -----Original Message----- >> From: nagiosplug-devel-bounces at lists.sourceforge.net >> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >> Behalf Of Andreas Ericsson >> Sent: January 19, 2007 8:56 >> To: Nagios Plugin Development Mailing List >> Subject: Re: [Nagiosplug-devel] Nagios:Plugin feedback >> >> Thomas Guyot-Sionnest wrote: >>> There's many useful functions in the C API for Nagios >> plugins. I believe >>> it wouldn't be a bad idea to have the same kind of function directly >>> into Nagios::Plugin. By minimizing the use of external modules, you >>> simplify plugin deployment. >>> >>> Nagios::Plugin could itself load external modules to do the >> checks, but >>> those dependencies would be installed along with Nagios::Plugin. >>> >>> What I'm starting to realize is that there's nothing to check the >>> validity of arguments. In C you have all those functions: >>> >>> is_integer >>> is_intpos >>> is_intneg >>> is_intnonneg >>> is_intpercent >>> is_numeric >>> is_positive >>> is_negative >>> is_nonnegative >>> is_percentage >>> >> Please, pretty please, don't mention those. They are >> extremely bad examples >> of C programming. ALL of them can, even from the callers perspective >> be replaced with shorter versions that are already C89 compliant. >> >> Most of them also duplicate checks already implemented in the >> libc functions >> and *NONE* of them return the computed value to the caller. >> Each time you see >> one of those functions used, you will know for a fact that >> several operations >> are carried out at least twice. It's usually worse than that, >> because it's often >> done in subtly (and pointless) different ways that the >> compiler can't optimize >> away. > > Oh, Thanks. I'm not a very experienced Perl programmer, and even worse C > programmer, so that's good to know. > > It would be nice then to know the replacements, and possibly start a project > to clean up those (And any other that need to go) so we can eventually > remove that from utils.c/h. Or is there any reason why we wouldn't want to > do that? > It works, so there's no real *need* to modify it (we're not coding demoes for C64 here, so we have the option of doing nothing while the computer does loads). That's no excuse to encourage it though. > This could be for a future v2 release, among with newer style tresholds > args, etc... Meanwhile the devlopper guidelines could mention which > functions not to use, and the recommended replacements. I often refer to > other plugins to decide how I should do things and they apparently aren't > always good examples. > Not always, but sometimes. In the end you will decide to do things one way or another anyway, and if it *works* people won't whine at you. Just follow these guidelines and I'm sure you'll do OK. * Don't compute values you don't need. * Don't throw away computed values. * Don't compute values twice. * Don't be overly anal (is_ipaddr()/is_hostname() discussion). * Don't get overly clever with macros and wrapper functions. * Don't bloat your functions. One function well written, one task done well. * Don't use non-portable functions/procedures. * Don't break any of the above unless there are compelling reasons to do so. ;-) * Don't comply to a too-old standard (C99 is 8 years old in May, fe). I'm sure there are more complete lists on the web, and almost certainly some that are particular to perl as opposed to this one that applies to programming in general. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From gavin at openfusion.com.au Sat Jan 20 06:14:10 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Sat, 20 Jan 2007 16:14:10 +1100 Subject: [Nagiosplug-devel] Nagios:Plugin feedback In-Reply-To: References: <804160344192334BB21922E8082EA6C0487988@seaex01.180solutions.com> <20070119034658.GA7415@openfusion.com.au> Message-ID: <20070120051410.GA10260@openfusion.com.au> On Fri, Jan 19, 2007 at 09:05:21AM +0000, Ton Voon wrote: > > On 19 Jan 2007, at 03:46, Gavin Carr wrote: > > >>Is there a is_hostname function? is_ipaddr would be useful as well. > >>What about passing argument check code directly in the add_arg() > >>arguments? > >> > > > >My feeling is that we wouldn't add datatype stuff to Nagios::Plugin, > >largely because it's pretty well covered already in other CPAN > >modules. > > Agreed. CPAN is about reusing other bits of code. However, some > pointers to "good implementations" in CPAN might be helpful. Agreed. > Longer term, we probably need to think about how to handle module > dependencies for a given check_* script. Distributing a plugin to 100 > boxes might prove problematic if there is a large list of dependencies. The Right Way to do this, of course, is to use local package management systems for that. I guess it might be reasonable to provide a fallback system though, like say a script that scanned all the perl plugins in a directory and installed any missing dependencies from CPAN. But you're still going to need CPAN configured on all those boxes, which is non-trivial itself. Cheers, Gavin -- Gavin Carr - http://www.openfusion.com.au - Linux, Perl, and Web Consulting - http://www.xool.com.au - Xool, Australian property search engine * Fashion is a variable, but style is a constant - Programming Perl From noreply at sourceforge.net Sat Jan 20 07:08:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Jan 2007 22:08:31 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632072 ] pointer error in plugins/netutils.c Message-ID: Patches item #1632072, was opened at 2007-01-10 02:51 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632072&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: pointer error in plugins/netutils.c Initial Comment: In np_net_connect() a pointer to the value returned by socket() is compared against zero rather than the value itself. Patch against CVS HEAD is below. Chris Index: plugins/netutils.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/netutils.c,v retrieving revision 1.32 diff -r1.32 netutils.c 228c228 < if(sd < 0){ --- > if(*sd < 0){ ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-20 01:08 Message: Logged In: YES user_id=375623 Originator: NO Thanks for reporting. Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632072&group_id=29880 From noreply at sourceforge.net Sat Jan 20 07:28:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Jan 2007 22:28:24 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632078 ] critical threshold % incorrectly displayed by check_icmp Message-ID: Patches item #1632078, was opened at 2007-01-10 02:59 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632078&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: critical threshold % incorrectly displayed by check_icmp Initial Comment: A misplaced paren causes a bogus value to be displayed as the default critical threshold percent. Patch is below. Chris Index: plugins-root/check_icmp.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins-root/check_icmp.c,v retrieving revision 1.8 diff -r1.8 check_icmp.c 1204c1204 < printf ("%0.3fms,%u%%)\n", (float)crit.rta), crit.pl; --- > printf ("%0.3fms,%u%%)\n", (float)crit.rta, crit.pl); ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-20 01:28 Message: Logged In: YES user_id=375623 Originator: NO Thanks for reporting! Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632078&group_id=29880 From noreply at sourceforge.net Sat Jan 20 08:19:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 19 Jan 2007 23:19:01 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1632091 ] printf format string typos Message-ID: Patches item #1632091, was opened at 2007-01-10 03:25 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632091&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: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: printf format string typos Initial Comment: A couple of misplaced commas in format strings and a missing '%s' in the usage message of check_ldap. The latter prevented the flags for selecting the LDAP and IP protocol versions from being displayed. Patch against CVS HEAD is attached. Chris ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-20 02:19 Message: Logged In: YES user_id=375623 Originator: NO Thanks for reporting! Fixed in CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1632091&group_id=29880 From dermoth at aei.ca Sat Jan 20 08:25:01 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 20 Jan 2007 02:25:01 -0500 Subject: [Nagiosplug-devel] RFC: Nagios 3 and Embedded Perl Plugins In-Reply-To: <45A4BCBF.20400@op5.se> References: <804160344192334BB21922E8082EA6C0437B23@seaex01.180solutions.com> <45A4BCBF.20400@op5.se> Message-ID: <45B1C3CD.9060701@aei.ca> Thanks for the exhaustive answer. It looks very nice :) On 10/01/07 05:15 AM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >>> -----Original Message----- >>> From: nagiosplug-devel-bounces at lists.sourceforge.net >>> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >>> Behalf Of Andreas Ericsson >>> Sent: January 9, 2007 8:39 >>> To: Nagios Plugin Development Mailing List >>> Subject: Re: [Nagiosplug-devel] RFC: Nagios 3 and Embedded >>> Perl Plugins >>> >>> Thomas Guyot-Sionnest wrote: >>>> Actually I think now it's getting interesting. If done >>> properly, this >>>> could be a nice way of doing distributed active checking. >>>> >>>> Using the same system St?phane described Nagios could have open >>>> connections to remote execution hosts that runs the checks >>> and read back >>>> results. Different services properties would determine if >>> the service >>>> can be run directly on the host (if Nagios has an open >>> connection to it) >>>> or if it has to be remote. Check execution load could be run on >>>> dedicated servers, or even be spread out across monitored hosts. >>>> >>> Yes, but a distributed static mesh redundancy thing is pretty >>> different >>> from an NRPE-daemon with an option to keep connections alive. A nice >>> example of where "think big" doesn't work, but "think bigger" does. >>> >>> I'm working on a module that does just that, but it requires >>> a fullblown >>> Nagios installation on each of the poller nodes and the decision of >>> which host is monitored by what system is determined by hostgroups >>> instead of through some automagic solution that could possibly (and >>> would probably) get things wrong from time to time. >> Sounds great. Just to make things clear my idea wasn't a NRPE replacement but rather an addition. For ex. you could have something like this (Lets't call my thing NRCE, Nag[...] Command Executor): >> >> +---------+ >> | Nagios | >> +---------+ >> | >> | >> +---------+ >> | NRCE | >> +---------+ >> | >> | >> +---------+ >> | NRPE | >> +---------+ >> > > Again, I believe "think big" isn't enough and "think bigger" is > required. I'm probably biased though ;-) > >> The NRCE host could be a monitored host as well and remote network checks could be either coming from Nagios itself or from another NRCE host. >> >> It wouldn't require a full blown Nagios but your solution has the advantage of cascading checks. With that and by reducing the logic involved in the main Nagios process your solution is much more scalable. >> >> Do you plan on having the "child" Nagios processes receive their config automatically from the main process? That would simplify a lot the setup. >> > > Yes. Here's how it's supposed to work in a scenario with only one master > and one poller: > > * Poller node starts (or is restarted). > * It loads the module which connects to master and requests config, > sending the timestamp of its own config-file (only one) along with the > request. > * The master checks if an update is necessary. > - if yes: > * The master runs an external helper-script which extracts the > parts of the config that the poller needs to know and feeds it to the > poller. > * The poller restarts itself and reads the new configuration file. > * The master disables active checks for the services and hosts monitored > by the poller. > * The poller periodically sends a pulse to the master, telling it it's > alive. A check-result is considered to be an "I'm alive" message. > * If the poller goes down the master enables checks for the hosts and > services previously checked by the poller. > > > In the case of more than one master, the check-results are sent to each > master, and the one with the most recent configuration is considered to > be the grand-master for the duration of it's uptime. > > In the case of more than one poller where the pollers are redundant, the > pollers send check-results to each other as well as to the master, so as > to save the network load of having to do the check twice (redundant > poller nodes are expected to be physically close to each other, so > network traffic between them is of no concern). > > In the case of pollers which in turn have pollers underneath them, the > masters (including the grandmaster) is considered tier1, the pollers > tier2 and the pollers' pollers tier3. In this case, tier2 nodes disables > checks for hosts/services that are handled by tier3 nodes while those > tier3 nodes are alive. The tier2 nodes also acts as masters for the > tier3 nodes, while still forwarding all their results (including those > from the tier3 nodes) to the tier1 nodes. > > This is all very neat, because you can use all of the tier1, tier2 and > tier3 nodes as full-blown nagios installations by the simple expedient > of also installing the GUI package on them. > > Think for example a large international corporation where there is a > network operations centre that has the tier 1 nodes that the network > infrastructure administrators work with. They see the whole picture. > In each country where there's an office you have a redundant set of tier > 2 nodes that are responsible for handling all the checks in that > country. If you check the GUI for one of those, you only see the checks > for that country, which is most likely appropriate as the admins working > at that site don't really need the whole picture. > The tier 3 nodes are placed at the various branch offices and are > responsible for checking the everything there. The branch office IT > staff can log in to their server (which is close by and has good network > performance) and see what's important to their network. > > > I realize that the "see what's important to their network" can just as > easily be done by massaging the config at the NOC a bit, but it's very > convenient to have several servers with their own GUI, as it comes for > free and will provide good network speed for the people in Taiwan even > if the NOC is in Finland. > > Note that any or all of the tiers in the above scenario can be redundant > with as many servers as you like. Also note that this allows an > arbitrarily large network to be monitored without using some monster of > a computer, although the master nodes probably require fairly heavy > equipment to be able to perform reasonably, GUI-wise, with the number of > monitored nodes one could expect for a network of this size. > > The reason it scales more or less indefinitely is that the bottleneck > (formerly the command-pipe) is much larger (generally 132KiB vs 4KiB) > and spread out over as many nodes as you like. The *real* bottleneck is, > in this scenario, the amount of data you can feed to the master-servers, > which shouldn't be less than 10Mbit/second in a network of this size. > Most likely it's 100Mbit from tier2 to tier1, which is what matters. > > The amount of data required to transmit for each check is, on average, > 400 bytes (a bunch of timestamps, return-code, plugin output), so > assuming all bandwidth is used for transmitting check-results, that > would allow for 3125 checks per second. With an average check-interval > of 3 minutes, that's 562500 checks for the 10Mbit case. For 100Mbit we > can use a fifth of the bandwidth and still check well in excess of 1 > million services with very frequent intervals. > > Sorry for the long mail. > From seanius at seanius.net Sat Jan 20 12:07:14 2007 From: seanius at seanius.net (sean finney) Date: Sat, 20 Jan 2007 12:07:14 +0100 Subject: [Nagiosplug-devel] compiler warnings from -Wall -pedantic Message-ID: <1169291234.26679.25.camel@localhost> hey all, regardless of whether we make compilation with these flags a default thing, it's worth going over the current warning output: fsusage.c:183:1: warning: use of C99 long long integer constant fsusage.c:252:1: warning: use of C99 long long integer constant fsusage.c:253:1: warning: use of C99 long long integer constant fsusage.c:256:1: warning: use of C99 long long integer constant fsusage.c:257:1: warning: use of C99 long long integer constant In file included from regex.c:54: ./regex.h:654: warning: ISO C90 does not support ?static? or type qualifiers in parameter array declarators In file included from regex.c:55: regex_internal.h:340: warning: type of bit-field ?type? is a GCC extension In file included from regex.c:59: regexec.c: In function ?check_node_accept_bytes?: regexec.c:3915: warning: initializer element is not computable at load time utils_base.c: In function ?_set_thresholds?: utils_base.c:108: warning: ordered comparison of pointer with integer zero In file included from check_apt.c:46: ../lib/regex.h:654: warning: ISO C90 does not support ?static? or type qualifiers in parameter array declarators check_apt.c:448:11: warning: unknown escape sequence '\%' check_disk.c: In function ?main?: check_disk.c:162: warning: unused variable ?inode_space_pct? check_disk.c: At top level: check_disk.c:62: warning: ?inode_format? defined but not used In file included from check_http.c:77: ../lib/regex.h:654: warning: ISO C90 does not support ?static? or type qualifiers in parameter array declarators check_nwstat.c: In function ?print_help?: check_nwstat.c:1679: warning: ISO C does not support the ?%S? printf format check_nwstat.c:1679: warning: format ?%S? expects type ?wchar_t *?, but argument 2 has type ?char *? In file included from check_smtp.c:79: ../lib/regex.h:654: warning: ISO C90 does not support ?static? or type qualifiers in parameter array declarators In file included from check_mysql.c:51: /usr/include/mysql/mysql.h:114: warning: ISO C90 does not support ?long long? In file included from check_mysql_query.c:47: /usr/include/mysql/mysql.h:114: warning: ISO C90 does not support ?long long? check_procs.c: In function ?main?: check_procs.c:196: warning: implicit declaration of function ?base_name? check_procs.c:196: warning: passing argument 2 of ?strcpy? makes pointer from integer without a cast In file included from check_snmp.c:94: ../lib/regex.h:654: warning: ISO C90 does not support ?static? or type qualifiers in parameter array declarators check_fping.c: In function ?print_help?: check_fping.c:392: warning: too many arguments for format check_fping.c:394: warning: too many arguments for format check_dhcp.c: In function ?send_dhcp_discover?: check_dhcp.c:464: warning: format ?%lu? expects type ?long unsigned int?, but argument 2 has type ?uint32_t? check_dhcp.c: In function ?get_dhcp_offer?: check_dhcp.c:539: warning: format ?%lu? expects type ?long unsigned int?, but argument 2 has type ?uint32_t? check_dhcp.c:545: warning: format ?%lu? expects type ?long unsigned int?, but argument 2 has type ?uint32_t? check_dhcp.c:545: warning: format ?%lu? expects type ?long unsigned int?, but argument 3 has type ?u_int32_t? check_dhcp.c:489: warning: unused variable ?timeout? check_dhcp.c: In function ?send_dhcp_packet?: check_dhcp.c:596: warning: unused variable ?myname? check_icmp.c:116: warning: ISO C90 does not support ?long long? check_icmp.c:212: warning: ISO C90 does not support ?long long? check_icmp.c:481:9: warning: C++ style comments are not allowed in ISO C90 check_icmp.c:481:9: warning: (this will be reported only once per input file) check_icmp.c: In function ?main?: check_icmp.c:563: warning: ISO C90 does not support the ?ll? printf length modifier check_icmp.c:565: warning: ISO C90 does not support the ?ll? printf length modifier check_icmp.c: In function ?run_checks?: check_icmp.c:640: warning: ISO C90 does not support the ?ll? printf length modifier (sorry if my MUA wrapped those lines) fwiw, this is from gcc 4.0.3 on ubuntu dapper. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Mon Jan 22 05:11:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Jan 2007 20:11:10 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1472491 ] extra options for check_by_ssh Message-ID: Patches item #1472491, was opened at 2006-04-18 19:33 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1472491&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: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: extra options for check_by_ssh Initial Comment: Hi, if you use check_by_ssh and the hostkey of the server has changed, your /etc/ssh/ssh_known_hosts is poorly maintained or if you never made a successful connection to tihs server, then you will get the following: qqnagio at lt0073:~> check_by_ssh -H siapp11 - C 'nrpe/libexec/check_dummy 0' The authenticity of host 'siapp11 (160.50.85.56)' can't be established. RSA key fingerprint is de:84:1b:35:81:a7:11:5b:f7:45:d9:eb:62:e0:b1:dc. Are you sure you want to continue connecting (yes/no)? The service will time out and a warning will be issued. If you generate your configuration automatically, so at any time new hosts can appear, you would have to execute ssh manually and answer with yes. Now it will work until the host is reinstalled or its hostkey changes otherwise. You can suppress this question if you set the StrictHostKeyChecking to no either in your /etc/ssh/ssh_config or if you give this option to ssh. I made a patch fot check_by_ssh.c which adds the possibility to call ssh with such an option. qqnagio at lt0073:~> check_by_ssh -H siapp11 - o 'StrictHostKeyChecking =no' - C 'nrpe/libexec/check_dummy 0' Warning: Permanently added 'siapp11' (RSA) to the list of known hosts. Unfortunately you get this warning if you call the patches check_by_ssh for the first time. To prevent this i also added a '-q' option, which tells ssh to suppress warning and diagnostic messages. qqnagio at lt0073:~> check_by_ssh -H siapp11 - o 'StrictHostKeyChecking =no' -q - C 'nrpe/libexec/check_dummy 0' OK Now check_by_ssh no longer cares for inconsistencies in your known_hosts files. Keep in mind, that this makes you vulnerable to trojan horse attacks. Do not give secret information to the -a parameter. You can download the patch from http://people.consol.de/~lausser/nagios/patches.html Greetings from Munich, Gerhard ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2007-01-22 05:11 Message: Logged In: YES user_id=759506 Originator: NO I've updated your patch for the current CVS code, added the options to the help/usage output and committed it to CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1472491&group_id=29880 From noreply at sourceforge.net Mon Jan 22 05:17:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Jan 2007 20:17:19 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1618174 ] check_by_ssh adding -q option, to suppress MOTD Message-ID: Patches item #1618174, was opened at 2006-12-18 17:06 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1618174&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: DVG (davevg) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh adding -q option, to suppress MOTD Initial Comment: This patch adds the -q option for the ssh command to suppress the Message of the Day output on some hosts. The current skip lines flag does not skip this output which causes host checks on remote hosts to fail if they have a MOTD. ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2007-01-22 05:17 Message: Logged In: YES user_id=759506 Originator: NO The "-q" option was added to CVS today (via the patch supplied in 1472491). Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1618174&group_id=29880 From noreply at sourceforge.net Mon Jan 22 06:11:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 21 Jan 2007 21:11:43 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1090337 ] patch to make check_disk ignore zero size file systems Message-ID: Patches item #1090337, was opened at 2004-12-23 13:14 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1090337&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: None Priority: 5 Private: No Submitted By: Tim Wootton (tim_wootton1) Assigned to: Nobody/Anonymous (nobody) Summary: patch to make check_disk ignore zero size file systems Initial Comment: This patch makes check_disk ignore zero size file systems. I made this patch because when checking all disks (i.e. --path not specified) on solaris 8, a numer of zero length mounted file systems show up, like /proc (which is already ignored due to the AIX /proc handling) but also fd and mnttab. As I use this plugin is exclusively used to check real disks, as I think most people do, I expect it's fairly safe to ignore those with size 0. This is my 1st time submitting a patch so I hope that the format and info is sufficient, if not please let me know so that I can do better next time! This patch is against the 1.3.1 (1.7.2.4) check_disk plugin. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-22 06:11 Message: Logged In: YES user_id=759506 Originator: NO check_disk ignores zero size file systems by now. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1090337&group_id=29880 From waja at cyconet.org Sun Jan 21 21:56:11 2007 From: waja at cyconet.org (Jan Wagner) Date: Sun, 21 Jan 2007 21:56:11 +0100 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <20061012144024.24939.98423.reportbug@udaff.local> References: <20061012144024.24939.98423.reportbug@udaff.local> Message-ID: <200701212156.14416.waja@cyconet.org> On Thursday 12 October 2006 16:40, Alexey Bestchekov wrote: > ex: > root at udaff ~>/usr/lib/nagios/plugins/check_jabber -H localhost -p 5223 -w 1 > -c 2 JABBER WARNING - 0,007 second response time on port > 5223|time=0,007033s;0.0;0.0;0.0;0.0 Hey Guys, I can confirm this bug, since I'm also hit by it. nagios2:~# /usr/lib/nagios/plugins/check_tcp -H foobar -p 5223 TCP OK - 0,003 second response time on port 5223| time=0,003496s;0,000000;0,000000;0,000000;10,000000 nagios2:~# /usr/lib/nagios/plugins/check_jabber -H foobar -p 5223 JABBER WARNING - 0,021 second response time on port 5223| time=0,020542s;0.0;0.0;0.0;0.0 Maybe anybody on upstream can confirm it (any hopefully fix it :-)? With kind regards, Jan. P.S. I'm not on nagiosplug-devel, so please cc me! -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hyperactive at gmx.net Tue Jan 23 15:13:06 2007 From: hyperactive at gmx.net (Stefan Worm) Date: Tue, 23 Jan 2007 15:13:06 +0100 Subject: [Nagiosplug-devel] InfiniBand Network Check Plugin? Message-ID: <20070123141306.218340@gmx.net> Hello! I wrote a Perl script (see attached file) that checks and reports the status of InfiniBand Network Adapters (RcvErrors, LinkDowned, ExcBufOverrunErrors, etc.) and that is hopefully ready for some feedback. ;-) I just wanted to know if anyone is perhaps interested in something like that and if it is worth to develop it further - comments and suggestions welcome. :-) Features: - reports values via NSCA - vendor independent InfiniBand monitoring - can check the performance (error) counters remotely via InfinBand (very fast) or with the help of NRPE on the specific host Todo: - some minor bugs - improving the usability :-) - changes to fit to the new Nagios::Plugin modules Thanks in advance! Stefan -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail -------------- next part -------------- A non-text attachment was scrubbed... Name: check_iberr.pl Type: application/x-perl Size: 25987 bytes Desc: not available URL: From noreply at sourceforge.net Tue Jan 23 16:57:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 07:57:33 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642658 ] fix SEGV of check_radius Message-ID: Patches item #1642658, was opened at 2007-01-24 00:57 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=1642658&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: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: fix SEGV of check_radius Initial Comment: I got a segfault when I ran check_radius. So I read check_radius.c and found `data' was used uninitialized in main(). After fixing this problem, it looks ok. (I send the same patch to the nagiosplug-devel ML in Oct. 2006, but not fixed yet. Sorry for duplication.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642658&group_id=29880 From noreply at sourceforge.net Tue Jan 23 17:23:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 08:23:41 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642682 ] Fix -m (--maxbytes) option for check_tcp Message-ID: Patches item #1642682, was opened at 2007-01-24 01:23 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=1642682&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: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: Fix -m (--maxbytes) option for check_tcp Initial Comment: check_tcp.c has a fall-through bug in the switch-case block that handles the option `-m' (or `--maxbytes='), so optarg for `-m' is also passed for `-q'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642682&group_id=29880 From noreply at sourceforge.net Tue Jan 23 17:42:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 08:42:22 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642658 ] fix SEGV of check_radius Message-ID: Patches item #1642658, was opened at 2007-01-23 16:57 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642658&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: None Priority: 5 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: fix SEGV of check_radius Initial Comment: I got a segfault when I ran check_radius. So I read check_radius.c and found `data' was used uninitialized in main(). After fixing this problem, it looks ok. (I send the same patch to the nagiosplug-devel ML in Oct. 2006, but not fixed yet. Sorry for duplication.) ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-23 17:42 Message: Logged In: YES user_id=759506 Originator: NO Fixed in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642658&group_id=29880 From noreply at sourceforge.net Tue Jan 23 17:44:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 08:44:06 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642658 ] fix SEGV of check_radius Message-ID: Patches item #1642658, was opened at 2007-01-23 16:57 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642658&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: None Priority: 5 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: fix SEGV of check_radius Initial Comment: I got a segfault when I ran check_radius. So I read check_radius.c and found `data' was used uninitialized in main(). After fixing this problem, it looks ok. (I send the same patch to the nagiosplug-devel ML in Oct. 2006, but not fixed yet. Sorry for duplication.) ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-23 17:44 Message: Logged In: YES user_id=759506 Originator: NO Fixed in CVS. Thanks! ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-01-23 17:42 Message: Logged In: YES user_id=759506 Originator: NO Fixed in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642658&group_id=29880 From noreply at sourceforge.net Tue Jan 23 18:21:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 09:21:00 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642682 ] Fix -m (--maxbytes) option for check_tcp Message-ID: Patches item #1642682, was opened at 2007-01-23 17:23 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642682&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: None Priority: 5 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: Fix -m (--maxbytes) option for check_tcp Initial Comment: check_tcp.c has a fall-through bug in the switch-case block that handles the option `-m' (or `--maxbytes='), so optarg for `-m' is also passed for `-q'. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-23 18:21 Message: Logged In: YES user_id=759506 Originator: NO Fixed in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642682&group_id=29880 From noreply at sourceforge.net Tue Jan 23 19:02:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 10:02:43 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642780 ] --hostname option support for check_ssh Message-ID: Patches item #1642780, was opened at 2007-01-23 20:02 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=1642780&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: Ville Mattila (vmattila) Assigned to: Nobody/Anonymous (nobody) Summary: --hostname option support for check_ssh Initial Comment: Add support to check_ssh for the --hostname=ADDRESS command line option as promoted by `check_ssh --help'. The current check_ssh (rev. 1.30 from HEAD-200701231300) only recognizes --host=ADDRESS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642780&group_id=29880 From benoit.mortier at opensides.be Tue Jan 23 19:31:14 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue, 23 Jan 2007 19:31:14 +0100 Subject: [Nagiosplug-devel] InfiniBand Network Check Plugin? In-Reply-To: <20070123141306.218340@gmx.net> References: <20070123141306.218340@gmx.net> Message-ID: <200701231931.15797.benoit.mortier@opensides.be> Le Mardi 23 Janvier 2007 15:13, Stefan Worm a ?crit?: > Hello! > > I wrote a Perl script (see attached file) that checks and reports the > status of InfiniBand Network Adapters (RcvErrors, LinkDowned, > ExcBufOverrunErrors, etc.) and that is hopefully ready for some feedback. > ;-) > > I just wanted to know if anyone is perhaps interested in something like > that and if it is worth to develop it further - comments and suggestions > welcome. :-) Hello, the best place to publish your work is at http://www.nagiosexchange.org/ Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From noreply at sourceforge.net Tue Jan 23 19:35:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 23 Jan 2007 10:35:11 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1642780 ] --hostname option support for check_ssh Message-ID: Patches item #1642780, was opened at 2007-01-23 19:02 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642780&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: None Priority: 5 Private: No Submitted By: Ville Mattila (vmattila) Assigned to: Nobody/Anonymous (nobody) Summary: --hostname option support for check_ssh Initial Comment: Add support to check_ssh for the --hostname=ADDRESS command line option as promoted by `check_ssh --help'. The current check_ssh (rev. 1.30 from HEAD-200701231300) only recognizes --host=ADDRESS. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-23 19:35 Message: Logged In: YES user_id=759506 Originator: NO Fixed in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1642780&group_id=29880 From hyperactive at gmx.net Tue Jan 23 20:43:20 2007 From: hyperactive at gmx.net (Stefan Worm) Date: Tue, 23 Jan 2007 20:43:20 +0100 Subject: [Nagiosplug-devel] InfiniBand Network Check Plugin? Message-ID: <20070123194320.216260@gmx.net> Benoit Mortier wrote: > Le Mardi 23 Janvier 2007 15:13, Stefan Worm a ?crit : > > Hello! > > > > I wrote a Perl script (see attached file) that checks and reports the > > status of InfiniBand Network Adapters (RcvErrors, LinkDowned, > > ExcBufOverrunErrors, etc.) and that is hopefully ready for some > > feedback. ;-) > > > > I just wanted to know if anyone is perhaps interested in something like > > that and if it is worth to develop it further - comments and > > suggestions welcome. :-) > > Hello, > the best place to publish your work is at http://www.nagiosexchange.org/ Hello, I know about this website, but there is no place for discussing new plugins unless releasing one. The problem is, that I am not sure, if there is need of such a plugin or if a similar one already exists. I hoped that someone at this list has an overview about this and can tell me a sentence bevor I put more work in this. :-) btw: In terms of my analysis of my script it is not ready yet for the release on nagiosexchange.org, because I don't want to add another half-done piece of software to the world. ;-) Salut! Stefan PS: If I am right, this list is for "submitting new plugins"... ?!? -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From ae at op5.se Wed Jan 24 11:49:10 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 24 Jan 2007 11:49:10 +0100 Subject: [Nagiosplug-devel] InfiniBand Network Check Plugin? In-Reply-To: <20070123194320.216260@gmx.net> References: <20070123194320.216260@gmx.net> Message-ID: <45B739A6.8010507@op5.se> Stefan Worm wrote: > Benoit Mortier wrote: >> Le Mardi 23 Janvier 2007 15:13, Stefan Worm a ?crit : >>> Hello! >>> >>> I wrote a Perl script (see attached file) that checks and reports the >>> status of InfiniBand Network Adapters (RcvErrors, LinkDowned, >>> ExcBufOverrunErrors, etc.) and that is hopefully ready for some >>> feedback. ;-) >>> >>> I just wanted to know if anyone is perhaps interested in something like >>> that and if it is worth to develop it further - comments and >>> suggestions welcome. :-) >> Hello, >> the best place to publish your work is at http://www.nagiosexchange.org/ > > Hello, > > I know about this website, but there is no place for discussing new plugins unless releasing one. The problem is, that I am not sure, if there is need of such a plugin or if a similar one already exists. > I hoped that someone at this list has an overview about this and can tell me a sentence bevor I put more work in this. :-) > > btw: In terms of my analysis of my script it is not ready yet for the release on nagiosexchange.org, because I don't want to add another half-done piece of software to the world. ;-) > It's open source. Ideas are almost as useful as code. just release it. > Salut! Stefan > > PS: If I am right, this list is for "submitting new plugins"... ?!? -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Wed Jan 24 13:09:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Jan 2007 04:09:56 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1643463 ] Miscalculating thresholds check_disk Message-ID: Bugs item #1643463, was opened at 2007-01-24 12:09 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=1643463&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: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: Miscalculating thresholds check_disk Initial Comment: The Plugin check_disk calculates the wrong thresholds, if I use % definitions like this: ./check_disk -w25% -c10% -p /var The perfdata warning and critical values are not correctly calculated. Best Regards, FliTTi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1643463&group_id=29880 From noreply at sourceforge.net Thu Jan 25 06:12:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 24 Jan 2007 21:12:49 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614164 ] 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Message-ID: Bugs item #1614164, was opened at 2006-12-12 12:38 Message generated for change (Comment added) made by a1exus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&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: alexus (a1exus) Assigned to: Ton Voon (tonvoon) Summary: 1.4.4/5 - regex_internal.h:458:20: alloca.h: No such file or Initial Comment: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -I/usr/local/ssl/include -g -O2 -MT regex.o -MD -MP -MF ".deps/regex.Tpo" -c -o regex.o regex.c; \ then mv -f ".deps/regex.Tpo" ".deps/regex.Po"; else rm -f ".deps/regex.Tpo"; exit 1; fi In file included from regex.c:55: regex_internal.h:458:20: alloca.h: No such file or directory gmake[4]: *** [regex.o] Error 1 gmake[4]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4.5' gmake: *** [all] Error 2 d# find . -name regex.c ./lib/regex.c d# find . -name alloca.h d# ---------------------------------------------------------------------- >Comment By: alexus (a1exus) Date: 2007-01-25 00:12 Message: Logged In: YES user_id=227889 Originator: YES works fine with latest snapshot ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-01-17 22:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-01-03 04:50 Message: Logged In: YES user_id=664364 Originator: NO Alexus, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot? There has been a fix to the generation of alloca.h. Ton ---------------------------------------------------------------------- Comment By: alexus (a1exus) Date: 2006-12-26 10:13 Message: Logged In: YES user_id=227889 Originator: YES this is what i did for "work-around" alexus at d:/usr/local/src/nagios-plugins-1.4.5> cd lib alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ls -la alloca.h lrwxr-xr-x 1 root wheel 34 Dec 12 22:39 alloca.h -> /usr/src/gnu/usr.bin/sort/alloca.h alexus at d:/usr/local/src/nagios-plugins-1.4.5/lib> ---------------------------------------------------------------------- Comment By: David (daspez) Date: 2006-12-26 03:13 Message: Logged In: YES user_id=1676837 Originator: NO Try compiling using the "--without-included-regex" parameter. I have had the same issue under FreeBSD 5.5 and it compiles using the above paramter. HIH. David ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614164&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Thu Jan 25 12:20:56 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Thu, 25 Jan 2007 12:20:56 +0100 Subject: [Nagiosplug-devel] RFC: new style command arguments for thresholds In-Reply-To: References: <77560922-95E0-4EC6-B551-8EA2BB27227F@altinity.com> <45ABF265.3040707@mailing.kaufland-informationssysteme.com> Message-ID: <45B89298.9000907@mailing.kaufland-informationssysteme.com> Hi Ton, hi list, > Thanks for the feedback so far. Original post > here: http://thread.gmane.org/gmane.network.nagios.plugins.devel/4461/focus=4461 thanks for the summary. I like the way you manage the information from RFCs: ask, wait, summarize. > Matthias points out lots of current work on SF trackers. Yes, current > tracker items is a big problem which I'm trying to address that. Any > help always appreciated. Maybe I pointed this out a bit too unclearly. I meant that switching to the new arguments etc looks pretty time consuming to me. So my question is if the patches from the tracker need to/should be added first in terms of compliance and priorization. In short: Will the discussed changes break the patches? Which task has higher priority? Imo its important that submitted patches are included to the distribution because people who submit patches perhaps make more effort to include new features instead of creating their own way/plugin. I should stay on topic.. > > Gavin Carr and Andreas Ericsson say that thresholds definitions could be > "contextual" based on what is best for the plugin, eg, check_procs > --processes=^1:1 to mean alert outside is . I think consistency is > better - any more thoughts? I especially liked the threshold consistency. Defining arguments means to make the plugin do I want it to do. I don't want to examine if the plugin actually does with what I say. Of course forcing explicit ranges would break compatibility. > > Gavin and Andreas suggest that metric names are defined on command line > with "-", but mapped to "_" in perf data output. I'm fine with that > unless anyone objects. I prefer -, too. > Andreas disagrees with the choice of "/" as the separator in > --metric=crit/warn and suggests comma instead. I want to avoid a comma > because, in future, I can see ranges will be defined with comma to mean > other ranges, such as current page ranges: 1-6,9. Also, I'd like to keep > the crit and warn definition in the same syntax argument, rather than > separating out to --metric-crit and --metric-warn. I'm all for a > different delimiter if it makes sense and doesn't clash. I avoided > semi-colon because of the shell meaning. I disliked the / at first, too but I couldn't find another valuable character on my keyboard. :/ > > Andreas suggests warn comes before crit. I favoured crit first because > it is more important than warn, but I'm not fixed to this. Any other > thoughts? I always define warning first. But I think this is different from person to person. Maybe because for example check_disk first exits warning and then critical if nothing gets fixed. > > Andreas suggests sticking plugin name and version in the current perf > data format as reserved words. Good idea. > yes > There's no major disagreements about a more consistent syntax required > for thresholds, so that sounds like an "okay". > > I'm starting to think that, with the Nagios/NRPE output limitations, > that XML is too much right now and that we need to stick to the current > output style. However, I think the warn and crit sections of the current > perf data output is inconsistent to the point of being useless right > now, but I would need some people from the graphing teams to tell me > what they think. I'll drop the emails to various lists. > What do you think about an new major version of the plugins? New syntax and performance data could be acceptable to me in a new major version. What do you think? matthias From noreply at sourceforge.net Thu Jan 25 20:03:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 25 Jan 2007 11:03:28 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1593073 ] Check_Log problem with log rotation Message-ID: Bugs item #1593073, was opened at 2006-11-09 01:13 Message generated for change (Comment added) made by msparhawk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1593073&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: Mark Sparhawk (msparhawk) Assigned to: Nobody/Anonymous (nobody) Summary: Check_Log problem with log rotation Initial Comment: Release 1.4.5 In cases where a logfile being monitored is rotated, the matching contents of the oldlogfile (file being used for comparisons) will trigger an error even tho none exist in the active monitored log. On line 200 $DIFF $logfile $oldlog > $tempdiff # Count the number of matching log entries we have count=`$GREP -c "$query" $tempdiff` I'm no developer, but it looks like this doesn't differentiate between matches in oldlog and matches in logfile. ---------------------------------------------------------------------- >Comment By: Mark Sparhawk (msparhawk) Date: 2007-01-25 19:03 Message: Logged In: YES user_id=1640959 Originator: YES I tweaked line 198 to remove diff output from the RHS file (the old log) $DIFF $logfile $oldlog | $GREP -v "^>" > $tempdiff File Added: check_log ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1593073&group_id=29880 From lists at wolfram.schlich.org Sat Jan 27 14:20:48 2007 From: lists at wolfram.schlich.org (Wolfram Schlich) Date: Sat, 27 Jan 2007 14:20:48 +0100 Subject: [Nagiosplug-devel] check_mysql should support a command line option for a MySQL defaults file In-Reply-To: <20061123233746.ALLYOURBASEAREBELONGTOUS.A27375@bla.fasel.org> References: <20061123233746.ALLYOURBASEAREBELONGTOUS.A27375@bla.fasel.org> Message-ID: <20070127132048.ALLYOURBASEAREBELONGTOUS.A31378@bla.fasel.org> * Wolfram Schlich [2006-11-24 00:38]: > Hi! > > IMHO check_mysql currently lacks a command line option to specify an > alternate MySQL defaults file (aka ~/.my.cnf). > The 'mysql' command line program for example supports --defaults-file. > > 'check_mysql --help' itself warns about using '--password' in order > to supply a password for MySQL authentication. > > Thus, the only secure and sane way to supply a password, > and even more important, *different* passwords for checking *multiple* > databases or MySQL servers, is via multiple specific MySQL > defaults files. I believe found an ugly workaround :) Here is my original proposal on how the issue could be solved by extending check_mysql with an '-f' command line option to enable it to read a specific my.cnf: > define command{ > command_name check_mysql > command_line $USER1$/check_mysql -H $HOSTADDRESS$ -P $ARG1$ -u $ARG2$ -d $ARG3$ -f $ARG4$ > } > > define service{ > [...] > host_name db1.example.com > [...] > check_command check_mysql!3306!nagios!mysql!/var/nagios/mysql.db1.example.com.cnf > } > > define service{ > [...] > host_name db2.example.com > [...] > check_command check_mysql!3306!nagios!mysql!/var/nagios/mysql.db2.example.com.cnf > } Here is my workaround requiring no modification to check_mysql: > define command{ > command_name check_mysql > command_line /usr/bin/env HOME=$ARG4$ $USER1$/check_mysql -H $HOSTADDRESS$ -P $ARG1$ -u $ARG2$ -d $ARG3$ > } The idea is to supply an alternative HOME environment variable to check_mysql. The mysql client library then looks for my.cnf in that directory. I verified this using "strace -e stat64 /usr/nagios/libexec/check_mysql". Here are the services: > define service{ > [...] > host_name db1.example.com > [...] > check_command check_mysql!3306!nagios!mysql!/var/nagios/my.cnf.d/db1.example.com > } > > define service{ > [...] > host_name db2.example.com > [...] > check_command check_mysql!3306!nagios!mysql!/var/nagios/my.cnf.d/db2.example.com > } check_mysql should then, regarding the above two examples, read the files /var/nagios/my.cnf.d/db1.example.com/my.cnf resp. /var/nagios/my.cnf.d/db2.example.com/my.cnf. While this should do it's job, it would be much nicer to have a patched check_mysql command. Is still nobody willing to do it? :) Comments, please. -- Regards, Wolfram Schlich Gentoo Linux * http://dev.gentoo.org/~wschlich/ From noreply at sourceforge.net Sat Jan 27 22:52:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 27 Jan 2007 13:52:59 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1643463 ] Miscalculating thresholds check_disk Message-ID: Bugs item #1643463, was opened at 2007-01-24 07:09 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1643463&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: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: Miscalculating thresholds check_disk Initial Comment: The Plugin check_disk calculates the wrong thresholds, if I use % definitions like this: ./check_disk -w25% -c10% -p /var The perfdata warning and critical values are not correctly calculated. Best Regards, FliTTi ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-27 16:52 Message: Logged In: YES user_id=375623 Originator: NO File Added: check_disk.reverse_perfdata.patch ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-27 16:52 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1643463&group_id=29880 From seanius at seanius.net Sun Jan 28 13:01:52 2007 From: seanius at seanius.net (sean finney) Date: Sun, 28 Jan 2007 13:01:52 +0100 Subject: [Nagiosplug-devel] check_mysql should support a command line option for a MySQL defaults file In-Reply-To: <20070127132048.ALLYOURBASEAREBELONGTOUS.A31378@bla.fasel.org> References: <20061123233746.ALLYOURBASEAREBELONGTOUS.A27375@bla.fasel.org> <20070127132048.ALLYOURBASEAREBELONGTOUS.A31378@bla.fasel.org> Message-ID: <1169985712.5312.7.camel@localhost> hi there, On Sat, 2007-01-27 at 14:20 +0100, Wolfram Schlich wrote: > I believe found an ugly workaround :) > Here is my workaround requiring no modification to check_mysql: > > > define command{ > > command_name check_mysql > > command_line /usr/bin/env HOME=$ARG4$ $USER1$/check_mysql -H $HOSTADDRESS$ -P $ARG1$ -u $ARG2$ -d $ARG3$ > > } indeed, i've had to do something similar in an unrelated project for mysql/postgres database foo. ugly, but it works :) > While this should do it's job, it would be much nicer to have a > patched check_mysql command. > Is still nobody willing to do it? :) i think that there's been discussion about extending the nagiosplug api in a more general fashion which would solve this type of problem for every plugin, not just the mysql ones. however, i never heard if it made it anywhere. has anyone moved further forward with the stuff (ini-parsing for extra cmdline arguments) we discussed? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Sun Jan 28 15:15:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 28 Jan 2007 06:15:58 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-597028 ] Make check_disk check inodes Message-ID: Feature Requests item #597028, was opened at 2002-08-19 09:17 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=597028&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 Priority: 5 Private: No Submitted By: Andrew Pollock (apollock) Assigned to: Nobody/Anonymous (nobody) Summary: Make check_disk check inodes Initial Comment: I think it would be advantageous for the check_disk plugin to also be able to check inode availability as well as block availability. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-01-28 15:15 Message: Logged In: YES user_id=759506 Originator: NO check_disk by now checks inodes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=597028&group_id=29880 From ton.voon at altinity.com Mon Jan 29 10:45:48 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 29 Jan 2007 09:45:48 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) Message-ID: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Hi! I'm trying to wrap up this RFC from October last year (http:// thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we can have some text written in the developer-guidelines before starting work on implementing it. This is a summary of the thread on it. I think I have all the angles covered, but please let me know if not. PROBLEM There are security issues with passing user authentication information into some plugins via the command line. We would like the use of configuration files, secured at the file level, allowing configuration variables on a per-plugin basis. PROPOSED SOLUTION A new option is allowed: --extra-opts. The idea is this option is "replaced" with configuration options within a configuration file. The configuration file has a windows ini style format: [stanza name] option1=argument1 option2=argument2 There can be multiple stanzas in a configuration file. The options are directly mapped to the plugin parameter options. The configuration file has no concept of whether the options are valid or not for the specific plugin. The options can be the long or short options - the routine will assume all single letter options are short options. The --extra-opts parameter will take a value in the format: --extra-opts=[stanza_name][@config_filename] If stanza_name is missed out, will assume stanza_name = plugin name. If @config_filename is missed out, will search for the configuration file in default locations. EXAMPLE The default config file holds: [check_mysql] username=tonvoon password=secret [more_options] username=altinity warning=10 critical=15 An invocation of: ./check_mysql -S --extra-opts= --extra-opts=more_options -H localhost is effectively: ./check-mysql -S --username=tonvoon --password=secret --- username=altinity --warning=10 --critical=5 H localhost Note --username is listed twice. The function will just process arguments as if it was above. It is the responsibility of the plugin to handle duplicated options. IMPLEMENTATION DETAILS The configuration file would be searched for in default locations (specified at compile time). A stanza_name of "default" is reserved for future use. As this facility can be used beyond just authentication (for instance, common parameters on a plugin basis), it is up to the system administrator to ensure the file permissions on a configuration file is appropriate. If -v -v -v is specified, the config file routine will print the output of the equivalent command line options with all --extra-opts options replaced. The implementation should allow multiple specifications of --extra-opts. If no one disagrees with this, I'll add it to the developer- guidelines on Wednesday, and then we can move onto an implementation phase and see who wants to have a go at writing this in C or perl. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Jan 29 10:47:48 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 29 Jan 2007 09:47:48 +0000 Subject: [Nagiosplug-devel] check_mysql should support a command line option for a MySQL defaults file In-Reply-To: <1169985712.5312.7.camel@localhost> References: <20061123233746.ALLYOURBASEAREBELONGTOUS.A27375@bla.fasel.org> <20070127132048.ALLYOURBASEAREBELONGTOUS.A31378@bla.fasel.org> <1169985712.5312.7.camel@localhost> Message-ID: <7265A2D3-219D-44DA-BD90-0C2FA40EBC2E@altinity.com> Hi Sean, On 28 Jan 2007, at 12:01, sean finney wrote: > i think that there's been discussion about extending the nagiosplug > api > in a more general fashion which would solve this type of problem for > every plugin, not just the mysql ones. > > however, i never heard if it made it anywhere. has anyone moved > further > forward with the stuff (ini-parsing for extra cmdline arguments) we > discussed? Sorry, my fault - I haven't been pushing it forward. I've just sent a summary of the latest proposal to this list. If there's no objections, I'll get it into the dev guidelines and then we can start on implementations. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Mon Jan 29 11:39:05 2007 From: seanius at seanius.net (sean finney) Date: Mon, 29 Jan 2007 11:39:05 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <1170067145.32503.9.camel@localhost> On Mon, 2007-01-29 at 09:45 +0000, Ton Voon wrote: > This is a summary of the thread on it. I think I have all the angles > covered, but please let me know if not. sounds good to me! sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Mon Jan 29 15:18:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 29 Jan 2007 06:18:19 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1643463 ] Miscalculating thresholds check_disk Message-ID: Bugs item #1643463, was opened at 2007-01-24 07:09 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1643463&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: Wont Fix Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: Miscalculating thresholds check_disk Initial Comment: The Plugin check_disk calculates the wrong thresholds, if I use % definitions like this: ./check_disk -w25% -c10% -p /var The perfdata warning and critical values are not correctly calculated. Best Regards, FliTTi ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-01-29 09:18 Message: Logged In: YES user_id=375623 Originator: NO Reverted in CVS, this is the expected behavior. This may change along with some improvements to performance data format, but this is still a long way ahead. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-27 16:52 Message: Logged In: YES user_id=375623 Originator: NO File Added: check_disk.reverse_perfdata.patch ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-27 16:52 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1643463&group_id=29880 From rouilj at cs.umb.edu Mon Jan 29 17:09:14 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon, 29 Jan 2007 11:09:14 -0500 Subject: [Nagiosplug-devel] check_snmp tries to be too smart Message-ID: <200701291609.l0TG9EiE023748@mx1.cs.umb.edu> Hi all: I am using: check_snmp (nagios-plugins 1.4.3) 1.58 It looks like check_snmp tries to be too smart and as a result requires exposure of the snmp community names. I have a ~/.snmp/snmp.conf file set up with the contents: defCommunity XyXyXyXyXyXy defVersion 2c which allows: %snmpget localhost sysUpTime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (12766176) 1 day, 11:27:41.76 to work just fine. However when using check_snmp as: %/usr/lib/nagios/plugins/check_snmp -H localhost -o sysUpTime.0 it fails when it runs the command: /usr/bin/snmpget -t 1 -r 5 -m ALL -v 1 -c public localhost:161 sysUpTime.0 Can we modify the operation of -C so that an empty argument prevents the addition of '-c public' to the snmpget command. I don't think it is possible to have a null snmp password, so maybe setting an empty community string could do this. Currently "-C ''" generates an error by creating the command line: /usr/bin/snmpget -t 1 -r 5 -m ALL -v 1 -c localhost:161 sysUpTime.0 which is a syntax error for snmpget. So setting a null/empty community string causes a plugin failure currently, so changing it to be valid should be fine since I can't imagine anybody using the current functionality. (Also just a thought: what happens if the community string has a space in it? Is snmpget called via a shell or is argv created and exec'ed directly?) Also there is no way to modify the output format from snmpget/getnext. This leads to weirdness (lines split for readability) like: SNMP OK - Timeticks: (12862120) 1 day, 11:43:41.20 | SNMPv2-MIB::sysUpTime.0=Timeticks: (12862120) 1 day, 11:43:41.20;;;; definitely an invalid format for performance data and SNMP OK - up(1) | IF-MIB::ifOperStatus.1=up(1);;;; again something not easily graphable (although both could be handled by using regexp matching/extraction of the interesting data item). Compare that to: snmpget -t 1 -r 5 -m ALL -v 2c localhost:161 sysUpTime.0 ifOperStatus.1 SNMPv2-MIB::sysUpTime.0 = Timeticks: (12850236) 1 day, 11:41:42.36 IF-MIB::ifOperStatus.1 = INTEGER: up(1) which generates the output displayed above and: snmpget -t 1 -r 5 -m ALL -v 2c -OtQe localhost:161 sysUpTime.0 ifOperStatus.1 SNMPv2-MIB::sysUpTime.0 = 12849618 IF-MIB::ifOperStatus.1 = 1 which produces pure numerical output for the queried OID's. Maybe adding a '-O' option to check_snmp that allows passing output format arguments to the underlying snmpget/snmpgetnext would be useful. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj at cs.umb.edu Mon Jan 29 18:05:54 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon, 29 Jan 2007 12:05:54 -0500 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros) In-Reply-To: Your message of "Mon, 29 Jan 2007 09:45:48 GMT." <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <200701291706.l0TH6XCY006417@mx1.cs.umb.edu> In message <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD at altinity.com>, Ton Voon writes: >I'm trying to wrap up this RFC from October last year (http:// >thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we >can have some text written in the developer-guidelines before >starting work on implementing it. > >This is a summary of the thread on it. I think I have all the angles >covered, but please let me know if not. > > >PROBLEM > >There are security issues with passing user authentication >information into some plugins via the command line. We would like the >use of configuration files, secured at the file level, allowing >configuration variables on a per-plugin basis. > >PROPOSED SOLUTION > >A new option is allowed: --extra-opts. The idea is this option is >"replaced" with configuration options within a configuration file. Well, one thing that was discussed on the nagios list for nagios 3 was the ability to use host object specific macros (e.g. _snmp_community=private) to keep this data associated with the host as different hosts may have different info. My idea was to flag some of these macros to be sent on stdin and not passed in the environment. So the plugin would get: _snmp--community=private _snmp--username=fred on standard in to set '--community=private' and '--username=fred'. Could the RFC be extended to allow: --extra_opts=- that will read on stdin lines of the form above and parse them using the last -- seperated segment as the option name. It seems that there is a 1:1 correspondance between arguments to a plugin and the host object macro so that each macro would be used for only one plugin invocation. If there was a case where the same username had to be passed as various parameters: --name, --username, --account etc for different plugins then a small shell filter could be used: define host { name foo _admin-login-account nagios ... } define command { command_line filter mysql | check_mysql --extra-opts=- .... ... command_input _admin-login-account } define command { command_line filter snmp | check_snmp -v 3 --extra-opts=- .... ... command_input _admin-login-account } where "filter" is responsible for changing an input value of: _admin-login-account=nagios to '--username=nagios' when given the "mysql" argument, '--secname=nagios' when given the argument snmp etc. (or we may be able to define some mapping mechanism that can be done by nagios without the need for the filter: e.g. secname=$_admin-login-account(default)$ would produce secname=nagios if _admin-login-account is defined for the host or secname=default if the mcro is undefined.) Being able to inherit this info from nagios means that managemnt interfaces developed for nagios can display (and change) this info without having to develop an add on mechanism. The data is kept with the host allowing nice printouts of the data and automatic generation from higher level management tools (e.g. inventory databases). Granted using --extra-opts=$HOSTNAME$ also allows for per host definitions files, but being able to use the nagios provided capability when they are available would also be a big win. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From harold at alum.mit.edu Mon Jan 29 18:13:08 2007 From: harold at alum.mit.edu (Harold Naparst) Date: Mon, 29 Jan 2007 18:13:08 +0100 (CET) Subject: [Nagiosplug-devel] check_gpgsig Message-ID: <20070129171308.76D414F4046@desire.netways.de> I wrote this shell script to check if a file, such as one of your web pages, has been altered. I use it to monitor whether my home page has been hacked. #!/bin/sh # ------------------------------------------------------------------------------ # check_gpgsig.sh - verify gpg signature of a file. # usage: # ./check_gpgsig.sh your_file # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # ------------------------------------------------------------------------------ FC=3 STAT="UNKNOWN" if [ ! -e "$1" ]; then RW=$1" is missing." STAT="WARNING" FC=1 else RW=`gpg --verify $1` FC=$? if [ "$FC" == "1" ]; then STAT="CRITICAL" RW="Dude. Someone hacked you." FC=2 else STAT="OK" RW="Good." FC=0 fi fi echo $STAT": "$RW exit $FC - Harold Naparst (hnaparst) ----------------------- The mailing list archive is found here: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html From gavin at openfusion.com.au Tue Jan 30 00:06:27 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 30 Jan 2007 10:06:27 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <20070129230627.GA3295@openfusion.com.au> Hi Ton, On Mon, Jan 29, 2007 at 09:45:48AM +0000, Ton Voon wrote: > I'm trying to wrap up this RFC from October last year (http:// > thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we > can have some text written in the developer-guidelines before > starting work on implementing it. > > This is a summary of the thread on it. I think I have all the angles > covered, but please let me know if not. > > > PROBLEM > > There are security issues with passing user authentication > information into some plugins via the command line. We would like the > use of configuration files, secured at the file level, allowing > configuration variables on a per-plugin basis. > > > PROPOSED SOLUTION > > A new option is allowed: --extra-opts. The idea is this option is > "replaced" with configuration options within a configuration file. I made a first-pass at this back in November in perl, and the main piece that was tricky was the in-place replacement that you seemed to be keen on i.e. [plugin] username=bar --username=foo --extra-opts=plugin mapping to '--username=foo --username=bar'. I just wonder if anyone is going to need to do this in practice? Mostly it seems to me that, if anything, we'd just want to override config file parameters i.e. --extra-opts=plugin --username=foo but not --username=foo --extra-opts=plugin (if they're additive, of course, it doesn't make a difference). So what do you think about saying instead: --extra-opts arguments always precede explicit arguments i.e. --username=foo --extra-opts=plugin is in effect: --extra-opts=plugin --username=foo ? Cheers, Gavin From dermoth at aei.ca Tue Jan 30 04:47:23 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 29 Jan 2007 22:47:23 -0500 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <200701212156.14416.waja@cyconet.org> References: <20061012144024.24939.98423.reportbug@udaff.local> <200701212156.14416.waja@cyconet.org> Message-ID: <45BEBFCB.1080800@aei.ca> On 21/01/07 03:56 PM, Jan Wagner wrote: > On Thursday 12 October 2006 16:40, Alexey Bestchekov wrote: >> ex: >> root at udaff ~>/usr/lib/nagios/plugins/check_jabber -H localhost -p 5223 -w 1 >> -c 2 JABBER WARNING - 0,007 second response time on port >> 5223|time=0,007033s;0.0;0.0;0.0;0.0 > > Hey Guys, > > I can confirm this bug, since I'm also hit by it. > > nagios2:~# /usr/lib/nagios/plugins/check_tcp -H foobar -p 5223 > TCP OK - 0,003 second response time on port 5223| > time=0,003496s;0,000000;0,000000;0,000000;10,000000 > nagios2:~# /usr/lib/nagios/plugins/check_jabber -H foobar -p 5223 > JABBER WARNING - 0,021 second response time on port 5223| > time=0,020542s;0.0;0.0;0.0;0.0 > > Maybe anybody on upstream can confirm it (any hopefully fix it :-)? The jabber check sends data and waits for a response. To get the same with check_tcp you would need the following additional parameters (I copied that from C code so I'm not sure if the escapes are all good): --send="\n" --expect=" I'll see if there's an easy fix for that. I also see one more possible problem. Should it be CRITICAL instead of WARNING when the output doesn't match? And do you have an external jabber host to check against so I can make sure the send/expect rules are right? Thanks, Thomas From nagios at nagios.org Tue Jan 30 05:16:55 2007 From: nagios at nagios.org (Ethan Galstad) Date: Mon, 29 Jan 2007 22:16:55 -0600 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070129230627.GA3295@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> Message-ID: <45BEC6B7.4010609@nagios.org> Gavin Carr wrote: > Hi Ton, > > On Mon, Jan 29, 2007 at 09:45:48AM +0000, Ton Voon wrote: >> I'm trying to wrap up this RFC from October last year (http:// >> thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we >> can have some text written in the developer-guidelines before >> starting work on implementing it. >> >> This is a summary of the thread on it. I think I have all the angles >> covered, but please let me know if not. >> >> >> PROBLEM >> >> There are security issues with passing user authentication >> information into some plugins via the command line. We would like the >> use of configuration files, secured at the file level, allowing >> configuration variables on a per-plugin basis. >> >> >> PROPOSED SOLUTION >> >> A new option is allowed: --extra-opts. The idea is this option is >> "replaced" with configuration options within a configuration file. > > I made a first-pass at this back in November in perl, and the main piece > that was tricky was the in-place replacement that you seemed to be keen > on i.e. > > [plugin] > username=bar > > --username=foo --extra-opts=plugin > > mapping to '--username=foo --username=bar'. > > I just wonder if anyone is going to need to do this in practice? Mostly > it seems to me that, if anything, we'd just want to override config file > parameters i.e. > > --extra-opts=plugin --username=foo > > but not > > --username=foo --extra-opts=plugin > > (if they're additive, of course, it doesn't make a difference). > > So what do you think about saying instead: --extra-opts arguments always > precede explicit arguments i.e. > > --username=foo --extra-opts=plugin > > is in effect: > > --extra-opts=plugin --username=foo > > ? > > > Cheers, > Gavin > The proposed config file solution is a great idea! I would suggest that command-line arguments/variables always override those found in the config file, no matter where they're located in the command line. I would imagine the only reason someone would override default values is because they want to override them. :-) Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From nagios at nagios.org Tue Jan 30 05:33:17 2007 From: nagios at nagios.org (Ethan Galstad) Date: Mon, 29 Jan 2007 22:33:17 -0600 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros) In-Reply-To: <200701291706.l0TH6XCY006417@mx1.cs.umb.edu> References: <200701291706.l0TH6XCY006417@mx1.cs.umb.edu> Message-ID: <45BECA8D.2030703@nagios.org> John P. Rouillard wrote: > In message <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD at altinity.com>, > Ton Voon writes: > >> I'm trying to wrap up this RFC from October last year (http:// >> thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we >> can have some text written in the developer-guidelines before >> starting work on implementing it. >> >> This is a summary of the thread on it. I think I have all the angles >> covered, but please let me know if not. >> >> >> PROBLEM >> >> There are security issues with passing user authentication >> information into some plugins via the command line. We would like the >> use of configuration files, secured at the file level, allowing >> configuration variables on a per-plugin basis. >> >> PROPOSED SOLUTION >> >> A new option is allowed: --extra-opts. The idea is this option is >> "replaced" with configuration options within a configuration file. > > Well, one thing that was discussed on the nagios list for nagios 3 was > the ability to use host object specific macros > (e.g. _snmp_community=private) to keep this data associated with the > host as different hosts may have different info. My idea was to flag > some of these macros to be sent on stdin and not passed in the > environment. So the plugin would get: > > _snmp--community=private > _snmp--username=fred > > on standard in to set '--community=private' and '--username=fred'. > > Could the RFC be extended to allow: > > --extra_opts=- > > that will read on stdin lines of the form above and parse them using > the last -- seperated segment as the option name. > > It seems that there is a 1:1 correspondance between arguments to a > plugin and the host object macro so that each macro would be used for > only one plugin invocation. If there was a case where the same > username had to be passed as various parameters: --name, --username, > --account etc for different plugins then a small shell filter could be > used: > > define host { > name foo > _admin-login-account nagios > ... > } > > define command { > command_line filter mysql | check_mysql --extra-opts=- .... > ... > command_input _admin-login-account > } > > define command { > command_line filter snmp | check_snmp -v 3 --extra-opts=- .... > ... > command_input _admin-login-account > } > > > where "filter" is responsible for changing an input value of: > > _admin-login-account=nagios > > to '--username=nagios' when given the "mysql" argument, > '--secname=nagios' when given the argument snmp etc. (or we may be > able to define some mapping mechanism that can be done by nagios > without the need for the filter: > e.g. secname=$_admin-login-account(default)$ would produce > secname=nagios if _admin-login-account is defined for the host or > secname=default if the mcro is undefined.) > > Being able to inherit this info from nagios means that managemnt > interfaces developed for nagios can display (and change) this info > without having to develop an add on mechanism. The data is kept with > the host allowing nice printouts of the data and automatic generation > from higher level management tools (e.g. inventory databases). > > Granted using --extra-opts=$HOSTNAME$ also allows for per host > definitions files, but being able to use the nagios provided > capability when they are available would also be a big win. > > -- rouilj > John Rouillard I prefer using the proposed config file solution to store passwords, etc. over the idea of passing this info via stdin. In my opinion, the config file option is a much simpler/elegant solution. It requires no mods to the Nagios daemon or plugin API. Super-secret info can be stored in the config file and locked down with standard file permissions. And a standard library/function set can be created to allow Perl/C plugins to grab their appropriate entries out of the config file. Now that I'm thinking about it, this type of file format seems like it must be used by a number of apps. There's probably a GPL'ed library out there that can read/write config entries to a file in the proposed format. As for loosing the ability to keep private information in the Nagios host/service definitions... I guess that's a good reason to make sure the monitoring server isn't used by normal users. If its a dedicated box, it shouldn't matter what information is being passed on the command lines between the daemon and the plugins. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From dermoth at aei.ca Tue Jan 30 06:12:47 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 00:12:47 -0500 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <45BEBFCB.1080800@aei.ca> References: <20061012144024.24939.98423.reportbug@udaff.local> <200701212156.14416.waja@cyconet.org> <45BEBFCB.1080800@aei.ca> Message-ID: <45BED3CF.9040301@aei.ca> On 29/01/07 10:47 PM, Thomas Guyot-Sionnest wrote: > On 21/01/07 03:56 PM, Jan Wagner wrote: >> Hey Guys, >> >> I can confirm this bug, since I'm also hit by it. >> >> nagios2:~# /usr/lib/nagios/plugins/check_tcp -H foobar -p 5223 >> TCP OK - 0,003 second response time on port 5223| >> time=0,003496s;0,000000;0,000000;0,000000;10,000000 >> nagios2:~# /usr/lib/nagios/plugins/check_jabber -H foobar -p 5223 >> JABBER WARNING - 0,021 second response time on port 5223| >> time=0,020542s;0.0;0.0;0.0;0.0 >> >> Maybe anybody on upstream can confirm it (any hopefully fix it :-)? > > The jabber check sends data and waits for a response. To get the same > with check_tcp you would need the following additional parameters (I > copied that from C code so I'm not sure if the escapes are all good): > > --send=" xmlns:stream=\'http://etherx.jabber.org/streams\'>\n" > > --expect=" xmlns:stream=\'http://etherx.jabber.org/streams\'" > > --quit="\n"; > > --ssl > > --jail > > > The confusion here comes from --jail which does not only remove the > output but also doesn't tell the reason of the warning. Without --jail > you would get: > > TCP WARNING - Unexpected response from host/socket: > > I'll see if there's an easy fix for that. > > I also see one more possible problem. Should it be CRITICAL instead of > WARNING when the output doesn't match? And do you have an external > jabber host to check against so I can make sure the send/expect rules > are right? The attached patch (Also in CVS) will fix the reporting problem. If there's any problem with the jabber check itself (i.e. warning status) I'll need a server to test with. I guess that a bad server response should mean a CRITICAL failure rather than a WARNING, right? Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_tcp.expect_reporting.patch Type: text/x-patch Size: 3081 bytes Desc: not available URL: From dermoth at aei.ca Tue Jan 30 06:16:51 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 00:16:51 -0500 Subject: [Nagiosplug-devel] check_gpgsig In-Reply-To: <20070129171308.76D414F4046@desire.netways.de> References: <20070129171308.76D414F4046@desire.netways.de> Message-ID: <45BED4C3.2010204@aei.ca> On 29/01/07 12:13 PM, Harold Naparst wrote: > I wrote this shell script to check if a file, > such as one of your web pages, has been altered. > I use it to monitor whether my home page has been > hacked. > > #!/bin/sh > # ------------------------------------------------------------------------------ > # check_gpgsig.sh - verify gpg signature of a file. > # usage: > # ./check_gpgsig.sh your_file > # > # This program is distributed in the hope that it will be useful, > # but WITHOUT ANY WARRANTY; without even the implied warranty of > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > # > # You should have received a copy of the GNU General Public License > # along with this program; if not, write to the Free Software > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > # ------------------------------------------------------------------------------ > > FC=3 > STAT="UNKNOWN" > if [ ! -e "$1" ]; then > RW=$1" is missing." > STAT="WARNING" > FC=1 > else > RW=`gpg --verify $1` > FC=$? > if [ "$FC" == "1" ]; then > STAT="CRITICAL" > RW="Dude. Someone hacked you." > FC=2 > else > STAT="OK" > RW="Good." > FC=0 > fi > fi > > echo $STAT": "$RW > exit $FC Hi, The best place to publish your work is at http://www.nagiosexchange.org/ Thanks, Thomas From dermoth at aei.ca Tue Jan 30 06:53:46 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 00:53:46 -0500 Subject: [Nagiosplug-devel] check_UDP In-Reply-To: References: Message-ID: <45BEDD6A.4040507@aei.ca> On 10/01/07 12:00 PM, uemit.altan at degussa.com wrote: > Hello, > > I have problems with using the nagios-plugin "check_udp". I have the > version "check_UDP (nagios-plugins 1.4.4) 1.79". > > If I perform the command "./check_udp -H 193.100.46.13 -p 53 -4 -w 5 -c 8" > on our Nagios-Server I get the following output: > > With UDP checks, a send/expect string must be specified. > Usage: check_UDP -H host -p port [-w ] [-c ] > [-s ] [-e ] [-q string>] > [-m ] [-d ] [-t ] > [-r ] [-M ] [-v] [-4|-6] > [-j] > [-D ] [-S ] [-E] > > > If I perform the command with send/except string like "./check_udp -H > 193.100.46.13 -p 53 -4 -w 5 -c 8 -s test1 -e test2 -q test3 -v" I get the > following output: > > Using service UDP > Port: 53 > flags: 0x1a > Send string: test1 > Quit string: test3 > > server_expect_count: 1 > 0: test2 > CRITICAL - Socket timeout after 10 seconds > > So what is wrong with the syntax of my command and could you please send me > an example command? > > Thank you in advance! To use check_udp you need to be able to "speak" the protocol you want to check. It also requires that the answer comes back to the same port is originated from. In the case of DNS it's pretty hard to make a real check, though maybe by sending more characters you would have gotten an answer, as in: /check_udp -H 193.100.46.13 -p 53 -4 -w 5 -c 8 -s test11111111 -e te For checking a DNS server you should rather use check_dns, which is able to send real queries and verify the response. Thomas From dermoth at aei.ca Tue Jan 30 07:06:37 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 01:06:37 -0500 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45BEC6B7.4010609@nagios.org> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> Message-ID: <45BEE06D.3080508@aei.ca> On 29/01/07 11:16 PM, Ethan Galstad wrote: > Gavin Carr wrote: >> Hi Ton, >> >> On Mon, Jan 29, 2007 at 09:45:48AM +0000, Ton Voon wrote: >>> I'm trying to wrap up this RFC from October last year (http:// >>> thread.gmane.org/gmane.network.nagios.plugins.devel/4199) so that we >>> can have some text written in the developer-guidelines before >>> starting work on implementing it. >>> >>> This is a summary of the thread on it. I think I have all the angles >>> covered, but please let me know if not. >>> >>> >>> PROBLEM >>> >>> There are security issues with passing user authentication >>> information into some plugins via the command line. We would like the >>> use of configuration files, secured at the file level, allowing >>> configuration variables on a per-plugin basis. >>> >>> >>> PROPOSED SOLUTION >>> >>> A new option is allowed: --extra-opts. The idea is this option is >>> "replaced" with configuration options within a configuration file. >> I made a first-pass at this back in November in perl, and the main piece >> that was tricky was the in-place replacement that you seemed to be keen >> on i.e. >> >> [plugin] >> username=bar >> >> --username=foo --extra-opts=plugin >> >> mapping to '--username=foo --username=bar'. >> >> I just wonder if anyone is going to need to do this in practice? Mostly >> it seems to me that, if anything, we'd just want to override config file >> parameters i.e. >> >> --extra-opts=plugin --username=foo >> >> but not >> >> --username=foo --extra-opts=plugin >> >> (if they're additive, of course, it doesn't make a difference). >> >> So what do you think about saying instead: --extra-opts arguments always >> precede explicit arguments i.e. >> >> --username=foo --extra-opts=plugin >> >> is in effect: >> >> --extra-opts=plugin --username=foo >> >> ? >> >> >> Cheers, >> Gavin >> > > The proposed config file solution is a great idea! > > I would suggest that command-line arguments/variables always override > those found in the config file, no matter where they're located in the > command line. I would imagine the only reason someone would override > default values is because they want to override them. :-) Hi there, I missed the discussion, but I noted some people are trying to set environment variables as well. Could this method allow setting environment variables as well? ex (proposal): [check_stuff] ENV { STUFF_NAME=foo STUFF_BLAH='foo bar' } range=12:20 Would set the STUFF_NAME and STUFF_COUNT environment variables in addition to setting --range to 12:20 Thomas From seanius at seanius.net Tue Jan 30 09:23:36 2007 From: seanius at seanius.net (sean finney) Date: Tue, 30 Jan 2007 09:23:36 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45BEE06D.3080508@aei.ca> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> Message-ID: <1170145416.12478.12.camel@localhost> On Tue, 2007-01-30 at 01:06 -0500, Thomas Guyot-Sionnest wrote: > I missed the discussion, but I noted some people are trying to set > environment variables as well. Could this method allow setting > environment variables as well? > > ex (proposal): > > [check_stuff] > ENV { > STUFF_NAME=foo > STUFF_BLAH='foo bar' > } > range=12:20 i'd like to make the suggestion that if we do this, instead of using the block-within-braces syntax (which doesn't aesthetically fit well with the ini format imo and would be harder to parse), we do something like [check_stuff] env STUFF_NAME=foo env STUFF_BLAH='foo bar' range=12:20 furthermore, you example brought up an issue which will need to be clarified... what's the specification for parsing quotes? i haven't been spending my fair share of time with n-p lately, so i'll volunteer to do the C side of this if there's agreement on the nitty-gritty... sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seanius at seanius.net Tue Jan 30 09:32:35 2007 From: seanius at seanius.net (sean finney) Date: Tue, 30 Jan 2007 09:32:35 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45BEC6B7.4010609@nagios.org> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> Message-ID: <1170145955.12478.22.camel@localhost> On Mon, 2007-01-29 at 22:16 -0600, Ethan Galstad wrote: > The proposed config file solution is a great idea! > > I would suggest that command-line arguments/variables always override > those found in the config file, no matter where they're located in the > command line. I would imagine the only reason someone would override > default values is because they want to override them. :-) fwiw, i agree with ethan on this. from the admin/user standpoint i think that the mostly likely situation when there is overlap between the cmdline and ini file is when the admin/user is trying to override something. does the dev reference currently say what should happen when config options are duplicated? if not i think we could make the clarification a moot point if we simply said that (for options that don't allow multiple declarations like -e in check_tcp, do we care about that?) the first option takes precedence, and require that the extra-config is parsed second. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ae at op5.se Tue Jan 30 09:50:22 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 30 Jan 2007 09:50:22 +0100 Subject: [Nagiosplug-devel] [Nagios-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros) In-Reply-To: <45BECA8D.2030703@nagios.org> References: <200701291706.l0TH6XCY006417@mx1.cs.umb.edu> <45BECA8D.2030703@nagios.org> Message-ID: <45BF06CE.20906@op5.se> Ethan Galstad wrote: > > I prefer using the proposed config file solution to store passwords, > etc. over the idea of passing this info via stdin. In my opinion, the > config file option is a much simpler/elegant solution. > Agreed. > It requires no mods to the Nagios daemon or plugin API. Super-secret > info can be stored in the config file and locked down with standard file > permissions. And a standard library/function set can be created to > allow Perl/C plugins to grab their appropriate entries out of the config > file. > Agreed again. > Now that I'm thinking about it, this type of file format seems like it > must be used by a number of apps. There's probably a GPL'ed library out > there that can read/write config entries to a file in the proposed format. > Yup, although it's not likely any API needs to actually write the files. Explaining to a user how to use a tool to configure their other tools is often harder than it is to just say "make sure your config has foo = bar in the nitfol section". I've got such a library which reads configs in the style of section-name { variable = value } in a very generic way. I'd be happy to share it if anyone's interested. > As for loosing the ability to keep private information in the Nagios > host/service definitions... I guess that's a good reason to make sure > the monitoring server isn't used by normal users. If its a dedicated > box, it shouldn't matter what information is being passed on the command > lines between the daemon and the plugins. > There's no real difference between having the private info in the nagios config or a separate file. If any, it'd be safer to have it in a separate file, as it'd be clear that that file needs protecting. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Tue Jan 30 10:03:15 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 30 Jan 2007 10:03:15 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170145416.12478.12.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> <1170145416.12478.12.camel@localhost> Message-ID: <45BF09D3.3010008@op5.se> sean finney wrote: > On Tue, 2007-01-30 at 01:06 -0500, Thomas Guyot-Sionnest wrote: >> I missed the discussion, but I noted some people are trying to set >> environment variables as well. Could this method allow setting >> environment variables as well? >> >> ex (proposal): >> >> [check_stuff] >> ENV { >> STUFF_NAME=foo >> STUFF_BLAH='foo bar' >> } >> range=12:20 > > i'd like to make the suggestion that if we do this, instead of using the > block-within-braces syntax (which doesn't aesthetically fit well with > the ini format But it does fit with the Nagios config syntax. > imo and would be harder to parse), we do something like > ... and it's not really harder to parse in any language I can think of. > [check_stuff] > env STUFF_NAME=foo > env STUFF_BLAH='foo bar' > range=12:20 > If you use ini-style, you end up with the problem of "how do we do with subsections?" such as when one plugin wants one environment (check_oracle) and another plugin needs something else. Compare check_stuff { env { STUFF_NAME = foo STUFF_BLAH = foo bar } range = 12:20 } with [check_stuff] [env] STUFF_NAME = foo STUFF_BLAH = foo bar range = 12:20 or [check_stuff] range = 12:20 [check_stuff env] STUFF_NAME = foo STUFF_BLAH = foo bar Using protected prefixes doesn't scale well, is error-prone and requires exception-handling for all the protected prefixes. > furthermore, you example brought up an issue which will need to be > clarified... what's the specification for parsing quotes? > Why use quotes? We're talking C/Perl here, aren't we? -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From waja at cyconet.org Tue Jan 30 10:00:39 2007 From: waja at cyconet.org (Jan Wagner) Date: Tue, 30 Jan 2007 10:00:39 +0100 Subject: [Nagiosplug-devel] =?iso-8859-6?q?=5BPkg-nagios-devel=5D_Bug=2339?= =?iso-8859-6?q?2610=3A=09nagios-plugins-basic=3A_check=5Fjabber_always_re?= =?iso-8859-6?q?turn_warning?= In-Reply-To: <45BED3CF.9040301@aei.ca> References: <20061012144024.24939.98423.reportbug@udaff.local> <45BEBFCB.1080800@aei.ca> <45BED3CF.9040301@aei.ca> Message-ID: <200701301000.43441.waja@cyconet.org> Hi Thomas, thanks for your help. On Tuesday 30 January 2007 06:12, Thomas Guyot-Sionnest wrote: > > The jabber check sends data and waits for a response. To get the same > > with check_tcp you would need the following additional parameters (I > > copied that from C code so I'm not sure if the escapes are all good): > > > > --send=" > xmlns:stream=\'http://etherx.jabber.org/streams\'>\n" > > > > --expect=" > xmlns:stream=\'http://etherx.jabber.org/streams\'" > > > > --quit="\n"; > > > > --ssl > > > > --jail > > > > > > The confusion here comes from --jail which does not only remove the > > output but also doesn't tell the reason of the warning. Without --jail > > you would get: > > > > TCP WARNING - Unexpected response from host/socket: # LANG=C ./check_tcp -H jabber.org -p 5223 --send="\n" --expect=" > I'll see if there's an easy fix for that. > > > > I also see one more possible problem. Should it be CRITICAL instead of > > WARNING when the output doesn't match? And do you have an external > > jabber host to check against so I can make sure the send/expect rules > > are right? > > The attached patch (Also in CVS) will fix the reporting problem. If > there's any problem with the jabber check itself (i.e. warning status) > I'll need a server to test with. I guess that a bad server response > should mean a CRITICAL failure rather than a WARNING, right? Try jabber.org as host to check your fixes, this one should be public available. Thanks and with kind regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seanius at seanius.net Tue Jan 30 10:28:28 2007 From: seanius at seanius.net (sean finney) Date: Tue, 30 Jan 2007 10:28:28 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45BF09D3.3010008@op5.se> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> <1170145416.12478.12.camel@localhost> <45BF09D3.3010008@op5.se> Message-ID: <1170149308.18658.9.camel@localhost> hey andreas, On Tue, 2007-01-30 at 10:03 +0100, Andreas Ericsson wrote: > But it does fit with the Nagios config syntax. well another option would be to make the file completely in nagios config syntax, but that's not what had been proposed, and mish-mashing them together just really stands out as a bad idea to me, anyway. > If you use ini-style, you end up with the problem of "how do we do with > subsections?" such as when one plugin wants one environment (check_oracle) > and another plugin needs something else. i believe that had already been at least partially addressed by the specification. namely, you could override the ini section name for a particular plugin, or which file was parsed at all. as for the syntax: > Compare one benefit of using the ini format is that it's made more clear where and how the configuration is used, as opposed to making it another nagios config object style thing, which would be a little confusing since it wouldn't/shouldn't be used by the nagios daemon. but otherwise, i'm not really strongly advocating any particulars, as long as it's consistant with itself (using one syntax completely, having a clear definition of prefixing vs. subsectioning stuff like env variables) > > furthermore, you example brought up an issue which will need to be > > clarified... what's the specification for parsing quotes? > > Why use quotes? We're talking C/Perl here, aren't we? > i didn't say we needed to, i was just pointing out that it hadn't been specified, and i felt that it would be a liability in the future not to do so--as the example i was responding to there were quotes in one of the settings. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From klausman at schwarzvogel.de Tue Jan 30 10:34:16 2007 From: klausman at schwarzvogel.de (Tobias Klausmann) Date: Tue, 30 Jan 2007 10:34:16 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) (Nagios V3 object macros) In-Reply-To: <45BECA8D.2030703@nagios.org> References: <200701291706.l0TH6XCY006417@mx1.cs.umb.edu> <45BECA8D.2030703@nagios.org> Message-ID: <20070130093416.GA5075@eric.schwarzvogel.de> Hi! On Mon, 29 Jan 2007, Ethan Galstad wrote: > Now that I'm thinking about it, this type of file format seems > like it must be used by a number of apps. There's probably a > GPL'ed library out there that can read/write config entries to > a file in the proposed format. As a data point: the Python stdlib contains a module that's capable of reading such [section] config files. I'm sure it isn't hard to find one for Perl. About C I'm not sure though. As for style, I prefer the [section] over section{}. The latter supports nesting which AFAICT we don't need. And it's a tiny bit mor complicated to parse (if you're, validating that is). Other than that, there's no difference between: [section1] foo=bar [section2] baz=barney and section1 { foo=bar section2 { baz=barney (Note the missing closing braces, if you're validating, that makes a difference. If you're parsing naively, it doesn't.) > As for loosing the ability to keep private information in the > Nagios host/service definitions... I guess that's a good > reason to make sure the monitoring server isn't used by normal > users. If its a dedicated box, it shouldn't matter what > information is being passed on the command lines between the > daemon and the plugins. Another argument for a monitoring server having no ordinary user (besides user accounts for the monitoring admins) is that such a box usually has elevated permissions packet-filter-wise. Also, users tend to "accidentally" create load peaks on machines. Something I'd rather not have on my Nagios box - re: check latencies and such. Also, generating a lot of mails (re: user cron jobs) can hamper notification delivery. Regards, Tobias -- Never touch a burning system. From ae at op5.se Tue Jan 30 10:44:07 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 30 Jan 2007 10:44:07 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170149308.18658.9.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> <1170145416.12478.12.camel@localhost> <45BF09D3.3010008@op5.se> <1170149308.18658.9.camel@localhost> Message-ID: <45BF1367.5080402@op5.se> sean finney wrote: >> If you use ini-style, you end up with the problem of "how do we do with >> subsections?" such as when one plugin wants one environment (check_oracle) >> and another plugin needs something else. > > i believe that had already been at least partially addressed by the > specification. namely, you could override the ini section name for a > particular plugin, or which file was parsed at all. > Ah, that makes sense. > >>> furthermore, you example brought up an issue which will need to be >>> clarified... what's the specification for parsing quotes? >> Why use quotes? We're talking C/Perl here, aren't we? >> > > i didn't say we needed to, i was just pointing out that it hadn't been specified, > and i felt that it would be a liability in the future not to do so--as the example > i was responding to there were quotes in one of the settings. > True. I'd say like this: Leading and trailing spaces are stripped from variables and values alike. Variable names may not start with [. Variable names may not contain =. = separates variable name and value. Spaces surrounding the first '=' on the line is ignored. A single backslash escapes the character following it [1]. Newlines aren't allowed in configuration variables. [*1*] This is needed to let variable values start with a space. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Tue Jan 30 15:41:41 2007 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 30 Jan 2007 14:41:41 +0000 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <45BF54E0.8080709@aei.ca> References: <20061012144024.24939.98423.reportbug@udaff.local> <45BEBFCB.1080800@aei.ca> <45BED3CF.9040301@aei.ca> <200701301000.43441.waja@cyconet.org> <45BF54E0.8080709@aei.ca> Message-ID: On 30 Jan 2007, at 14:23, Thomas Guyot-Sionnest wrote: > Aww, that's definitely a bug. Why '-j' works but not '--jail' is a > mistery for me though :/ > > Ton, do you have any idea why -j worked but not --jail? Should we use > all long options in "make test" scripts? It's because of the two ways of specifying required arguments. The long options definition said (before your patch) that if argument is required. However, when using short options, getopt_long uses the string "+hVv46EH:s:e:q:m:c:w:t:p:C:W:d:Sr:jD:M:" which does not specify an argument (no colon after the j). In tests, I vary between using short and long options. It is probably overkill to test every possible permutation, given this was a relatively small error. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From waja at cyconet.org Tue Jan 30 15:28:50 2007 From: waja at cyconet.org (Jan Wagner) Date: Tue, 30 Jan 2007 15:28:50 +0100 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <45BF54E0.8080709@aei.ca> References: <20061012144024.24939.98423.reportbug@udaff.local> <200701301000.43441.waja@cyconet.org> <45BF54E0.8080709@aei.ca> Message-ID: <200701301529.24523.waja@cyconet.org> On Tuesday 30 January 2007 15:23, Thomas Guyot-Sionnest wrote: > Aww, that's definitely a bug. Why '-j' works but not '--jail' is a > mistery for me though :/ > > Use the attached patch to fix your problem. Hi Thomas, my/our main problem here is, that check_jabber seems not working, since check_tcp does. Thanks and with kind regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dermoth at aei.ca Tue Jan 30 15:23:28 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 09:23:28 -0500 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <200701301000.43441.waja@cyconet.org> References: <20061012144024.24939.98423.reportbug@udaff.local> <45BEBFCB.1080800@aei.ca> <45BED3CF.9040301@aei.ca> <200701301000.43441.waja@cyconet.org> Message-ID: <45BF54E0.8080709@aei.ca> On 30/01/07 04:00 AM, Jan Wagner wrote: > Hi Thomas, > > thanks for your help. > > # LANG=C ./check_tcp -H jabber.org -p 5223 --send=" to=\'jabber.org\' xmlns=\'jabber:client\' > xmlns:stream=\'http://etherx.jabber.org/streams\'>\n" --expect=" version=\'1.0\'?> xmlns:stream=\'http://etherx.jabber.org/streams\'" --quit="\n" --ssl -j > TCP WARNING - Unexpected response from host/socket on port 5223| > time=0.703722s;0.000000;0.000000;0.000000;10.000000 > > # LANG=C ./check_tcp -H jabber.org -p 5223 --send=" to=\'jabber.org\' xmlns=\'jabber:client\' > xmlns:stream=\'http://etherx.jabber.org/streams\'>\n" --expect=" version=\'1.0\'?> xmlns:stream=\'http://etherx.jabber.org/streams\'" --quit="\n" --ssl --jail > ./check_TCP: option `--jail' requires an argument > > Hmm .. is there any trouble with "--jail" there? Aww, that's definitely a bug. Why '-j' works but not '--jail' is a mistery for me though :/ Use the attached patch to fix your problem. Ton, do you have any idea why -j worked but not --jail? Should we use all long options in "make test" scripts? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_tcp.jail_noargument.patch Type: text/x-patch Size: 664 bytes Desc: not available URL: From dermoth at aei.ca Wed Jan 31 04:29:44 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 22:29:44 -0500 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45BF09D3.3010008@op5.se> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> <1170145416.12478.12.camel@localhost> <45BF09D3.3010008@op5.se> Message-ID: <45C00D28.7070107@aei.ca> On 30/01/07 04:03 AM, Andreas Ericsson wrote: > sean finney wrote: >> On Tue, 2007-01-30 at 01:06 -0500, Thomas Guyot-Sionnest wrote: >>> I missed the discussion, but I noted some people are trying to set >>> environment variables as well. Could this method allow setting >>> environment variables as well? >>> >>> ex (proposal): >>> >>> [check_stuff] >>> ENV { >>> STUFF_NAME=foo >>> STUFF_BLAH='foo bar' >>> } >>> range=12:20 >> i'd like to make the suggestion that if we do this, instead of using the >> block-within-braces syntax (which doesn't aesthetically fit well with >> the ini format > > > But it does fit with the Nagios config syntax. I really didn't want to start an implementation war there ;) but my thoughts were that env must not be mistaken with parameters. If we go with blocks we might want one for params as well, like: [check_stuff] ENV { STUFF_NAME=foo } PARAMS { range=12:20 } Or just prefix everything: [check_stuff] ENV STUFF_NAME=foo PARAM range=12:20 Either way allows extensibility as unknown blocks/parameters could be ignored (possibly with warning). The other suggestion could be XML, as it seems to be the trend these days to have everything speak XML. Personally I'm fine with any format with slight preference to non-xml ones. Thomas From dermoth at aei.ca Wed Jan 31 05:45:59 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 30 Jan 2007 23:45:59 -0500 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <200701301000.43441.waja@cyconet.org> References: <20061012144024.24939.98423.reportbug@udaff.local> <45BEBFCB.1080800@aei.ca> <45BED3CF.9040301@aei.ca> <200701301000.43441.waja@cyconet.org> Message-ID: <45C01F07.9040609@aei.ca> On 30/01/07 04:00 AM, Jan Wagner wrote: > Hi Thomas, > >>> I also see one more possible problem. Should it be CRITICAL instead of >>> WARNING when the output doesn't match? And do you have an external >>> jabber host to check against so I can make sure the send/expect rules >>> are right? >> The attached patch (Also in CVS) will fix the reporting problem. If >> there's any problem with the jabber check itself (i.e. warning status) >> I'll need a server to test with. I guess that a bad server response >> should mean a CRITICAL failure rather than a WARNING, right? > > Try jabber.org as host to check your fixes, this one should be public > available. I tried it but I had to remove the SSL flag in the check_jabber-specific code. It is always possible to check with ssl with the --ssl command-line option so I guess I should consider removing that flag. Otherwise you don't have the option and must check with SSL. I also left the return code on mismatches to WARNING as it is the default for every other invocations of check_tcp that set expect strings. This can be changed as well, using the --mismatch (-M) switch. The patch I'm committing is attached. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_tcp.check_jabber-returns-warning.patch Type: text/x-patch Size: 901 bytes Desc: not available URL: From noreply at sourceforge.net Wed Jan 31 09:36:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Jan 2007 00:36:50 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp_errors Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 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=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp error by asking 2 dhcp_errors Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From noreply at sourceforge.net Wed Jan 31 09:37:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Jan 2007 00:37:12 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Settings changed) made by fhackenbmt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Nobody/Anonymous (nobody) >Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From waja at cyconet.org Wed Jan 31 08:47:26 2007 From: waja at cyconet.org (Jan Wagner) Date: Wed, 31 Jan 2007 08:47:26 +0100 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <45C01F07.9040609@aei.ca> References: <20061012144024.24939.98423.reportbug@udaff.local> <200701301000.43441.waja@cyconet.org> <45C01F07.9040609@aei.ca> Message-ID: <200701310847.29391.waja@cyconet.org> On Wednesday 31 January 2007 05:45, Thomas Guyot-Sionnest wrote: > I tried it but I had to remove the SSL flag in the check_jabber-specific > code. It is always possible to check with ssl with the --ssl > command-line option so I guess I should consider removing that flag. > Otherwise you don't have the option and must check with SSL. > > I also left the return code on mismatches to WARNING as it is the > default for every other invocations of check_tcp that set expect > strings. This can be changed as well, using the --mismatch (-M) switch. Hey Thomas! > The patch I'm committing is attached. # ./check_jabber -H jabber.org -p 5222 JABBER OK - 0,317 second response time on port 5222| time=0,317007s;0,000000;0,000000;0,000000;10,000000 It's working like a charm, thanks for fixing it. Will it be included in the upcoming release? Thanks and with kind regards, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ae at op5.se Wed Jan 31 13:14:58 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 31 Jan 2007 13:14:58 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45C00D28.7070107@aei.ca> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070129230627.GA3295@openfusion.com.au> <45BEC6B7.4010609@nagios.org> <45BEE06D.3080508@aei.ca> <1170145416.12478.12.camel@localhost> <45BF09D3.3010008@op5.se> <45C00D28.7070107@aei.ca> Message-ID: <45C08842.1080003@op5.se> Thomas Guyot-Sionnest wrote: > > The other suggestion could be XML, as it seems to be the trend these > days to have everything speak XML. Personally I'm fine with any format > with slight preference to non-xml ones. > XML is a definite nono for anything that ever has the possibility of being viewed by human eyes directly. XML is supposed to be human-readable, but it really isn't. I for one don't know a single person that can, from scratch, create a properly formatted XML-document. That precise possibility is very important in a configuration file. XML is very nice for passing information from one program to another, because it's a strict standard with no room for parser-specific details; You either follow the standard, and the standard only, or what you do isn't XML. It's absolutely horrendous for humans though. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From dermoth at aei.ca Wed Jan 31 13:28:57 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 31 Jan 2007 07:28:57 -0500 Subject: [Nagiosplug-devel] [Pkg-nagios-devel] Bug#392610: nagios-plugins-basic: check_jabber always return warning In-Reply-To: <200701310847.29391.waja@cyconet.org> References: <20061012144024.24939.98423.reportbug@udaff.local> <200701301000.43441.waja@cyconet.org> <45C01F07.9040609@aei.ca> <200701310847.29391.waja@cyconet.org> Message-ID: <45C08B89.1030201@aei.ca> On 31/01/07 02:47 AM, Jan Wagner wrote: > On Wednesday 31 January 2007 05:45, Thomas Guyot-Sionnest wrote: > > # ./check_jabber -H jabber.org -p 5222 > JABBER OK - 0,317 second response time on port 5222| > time=0,317007s;0,000000;0,000000;0,000000;10,000000 > > It's working like a charm, thanks for fixing it. Will it be included in the > upcoming release? Yes. From ton.voon at altinity.com Wed Jan 31 13:50:02 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 31 Jan 2007 12:50:02 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: Hi all, There's been lots of great feedback. Here's a summary and an updated RFC. COMMAND LINE OPTIONS There's been a shift from the "replacement inline" to "config file defines defaults override-able on command line". I think conceptually it is straightforward (and is equivalent to how mysql handle their my.cnf files), so there shouldn't be a problem understanding it. I still prefer "replacement" as I think it covers more possibilities and retains order of options, but I'll go with the majority :( I would propose that we rename from --extra-opts to --default-opts to reflect the new logic. DUPLICATED OPTIONS Sean Finney brings up a suggestion of dissuading the use of multiple options at the plugin level. There are some plugins that support duplicate options, such as check_disk -p, check_http -k, check_tcp's - e, most of the -v. Most of the time, duplicate options is the only "nice" way to define multiple things. I think this is best fixed by saying that the behaviour of multiple options is undefined using the config file, so you shouldn't use config files for these options. STDIN SUPPORT John P Rouillard requests stdin support for passing data from Nagios' config files. I think support for stdin (--default-opts=-) should be fine on condition that the input file is not processed any differently. John, would you still like this functionality? CONFIG FILE FORMAT FOR ENVIRONMENT VARIABLES I think everyone appeared happy with the ini style config file, until environment variables were brought in. I would prefer to avoid the development time in handling a new config file format, just so that it looks nicer or makes more semantical sense, and concentrate on providing the essential functionality. So I would propose that we have a prefix of "environment-" as the stanza name for environment variables, which will be processed differently. However, to stay on focus, the work to add "environment-" will be done after the option processing. By using other people's libraries, we can help patch their work if there is a case they haven't considered. CONFIG FILE IN XML FORMAT I'd like to discount XML because it cannot be easily read by humans. QUOTING IN CONFIG FILE It appears that there is not a specific standard for ini files (http://en.wikipedia.org/wiki/INI_file), so I think to move the conversation forward, I've described some common cases in the RFC below. These can form the basis of some unit tests which will be written in perl and C to check the implementations work as expected. I'd appreciate any other test cases which I can add - please add in the same format: a config file, a command to run, the expected results, plus a description of why it should be this way. NEXT STEPS - More test cases - I found it helps understand implementation issues (No single switch parameters, ordering possibly changed, number of options may change) - Agree on RFC for addition to dev guidelines UPDATED RFC ----- PROBLEM There are security issues with passing user authentication information into some plugins via the command line. We would like the use of configuration files, secured at the file level, allowing configuration variables on a per-plugin basis. PROPOSED SOLUTION A new option is allowed: --default-opts. The idea is this option reads in default values for configuration options from the configuration file. The configuration file has a windows ini style format: [stanza_name] option1=argument1 option2=argument2 There can be multiple stanzas in a configuration file. The options are directly mapped to the plugin parameter options. The configuration file has no concept of whether the options are valid or not for the specific plugin. The options can be the long or short options - the routine will assume all single letter options are short options. The --default-opts parameter will take a value in the format: --default-opts=[stanza_name][@config_filename] If stanza_name is missed out, will assume stanza_name = plugin name. If @config_filename is missed out, will search for the configuration file in default locations. A stanza_name prefixed with "environment-" is processed differently. It will set the environment variables within the current process. IMPLEMENTATION DETAILS The C routine is to be called np_getopt_long and has the same interface as getopt_long (from gnulib). The perl routine in Nagios::Plugin will not require any changes at the plugin level. Both the C and the perl routines do not require specification of -- default-opts to process that option - it is implicitly checked and processed. When processing options, there needs to be a first pass to extract all the --default-opts options and process the config files. Duplicate config options are removed, last one wins. Any options on command line will remove the default. Duplicates removal would include equivalent short and long options. For instance, a default config file of username=manager with a -u admin on command line would produce the equivalent of -u admin. The number of options will be guaranteed only for options on the command line as duplicate ones in configuration files will be removed. If you want a specific number of options, it is best to avoid --default-opts. The order of the options is not guaranteed - defaults maybe added at beginning or the end of processing. If you want to use options that could be positional dependant (such as check_disk's -p), it is recommended to avoid --default-opts. Only options with an argument will be in the configuration file. Switch parameters are not supported. The configuration file would be searched for in default locations (specified at compile time). A stanza_name of "default" and "environment-default" are reserved for future use. As this facility can be used beyond just authentication (for instance, common parameters on a plugin basis), it is up to the system administrator to ensure the file permissions on a configuration file is appropriate. If -v -v -v is specified, the config file routine will print the output of the equivalent command line options with the --default-opts options replaced. It is not defined whether long or short options will be displayed. Config file accepts # as a comment line. A ";" is acceptable for comments (some libraries will recognise), but discouraged. The implementation should allow multiple specifications of --default- opts. If default-opts is not found, return state unknown with appropriate message. If stanza is not found, return state unknown with appropriate message. If there is a parse error, return state unknown with appropriate message. EXAMPLES Assuming default config file holds: [check_mysql] username=tonvoon password=secret [more_options] username=altinity warning=10 critical=15 [check_disk] p=/tmp [check_2_disks] p=/tmp p=/var [funny_stuff] username="Ton Voon" p= expect=" space in front" An invocation of: ./check_mysql -S --default-opts= --default-opts=more_options -H localhost is effectively (order not necessarily preserved, see implementation details): ./check-mysql -S --username=altinity --password=secret --warning=10 --critical=5 -H localhost (Last invocation of --username is used from two config files) An invocation of: ./check_mysql --username=admin --default-opts=more_options --warning=5 is effectively: ./check_mysql --username=admin --critical=15 --warning=5 (command line overrides config file for --username) An invocation of: ./check_mysql --default-opts= -u admin is effectively: ./check_mysql --username=admin --password=secret (-u on command line overrides --username. It is not defined whether the effective command is -u or --username) An invocation of: ./check_disk --default-opts= -p=/home is effectively: ./check_disk -p /home (Handles single character options in config file correctly) An invocation of: ./check_disk --default-opts=check_2_disks is effectively: ./check_disk -p /var (p=/var is read last, so takes priority over p=/tmp) An invocation of: ./check_disk --default-opts= -p=/home -p=/users is effectively: ./check_disk -p /home -p /users (-p from config is overridden. Will retain the number of -p from command line) An invocation of: ./check_disk --default-opts=funny_stuff -p=/home -p=/users is effectively: ./check_disk --username "Ton Voon" -p "" --expect=" space in front" (-p has a value associated, but null. Space retained in username. Space in front retained in expect) An invocation of: ./check_disk --default-opts=@/non/existant/file returns UNKNOWN, with error message An invocation of: ./check_disk --default-opts=unknown-stanza returns UNKNOWN, with error message ----- Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From klausman at schwarzvogel.de Wed Jan 31 15:10:42 2007 From: klausman at schwarzvogel.de (Tobias Klausmann) Date: Wed, 31 Jan 2007 15:10:42 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <20070131141042.GA1369@eric.schwarzvogel.de> Hi! First off: Ton, nice RFC, I agree with just about everything, but I have one or two suggestions. What about Quoting? are only double quotes (") allowed? what about ''? Where is quoting needed? I.e. where will whitespace stripping happen? Second, comments. Will leading whitespace on comment lines be ignored? (I hope so). What about comments on non-comment-lines like here: [check_foo] username = default # temporary, will be change May 6th. Another corner case is this: Say a plugin has a default username. Now my defaults file specifies several things, among them the username I'd like to use. Will there be a provision to get back at the plugins default (besides explicitly specifying it on the command line)? I think it would be complicated/non-intuitive to implement, but maybe it's somebody's killer feature. Still, I don't need this myself, so shoot it down if you want :) Besides that, I'm d'accord. Regards, Tobias From seanius at seanius.net Wed Jan 31 16:19:59 2007 From: seanius at seanius.net (sean finney) Date: Wed, 31 Jan 2007 16:19:59 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <1170256799.5612.23.camel@localhost> hey ton, On Wed, 2007-01-31 at 12:50 +0000, Ton Voon wrote: > QUOTING IN CONFIG FILE i think we should be very, very clear on this. my opinion is that we shouldn't do any quote parsing/interpretation, and pass what is given verbatim to the plugin. so for example [check_myname] fullname=Sean Finney would be the equivalent of ./check_myname --fullname='Sean Finney' and [check_myname] fullname="Sean Finney" would be ./check_myname --fullname='"Sean Finney"' and that as andreas suggested, we allow for escaping single characters with a backslash character (which wouldn't be necessary in any of the above, but might be necessary for some other reason). maybe we should just pony-up and do a formal grammar for it? inifile := (discarded|stanza)* discarded := (whitespace)*(commentchar freetext)? newline freetext := [^(newline)]* newline := '\n' commentchar := "#" | ';' stanza := start declarations start := "[" name "]" newline name := [[:alnum:]]* declarations := (declaration declarations) | nothing declaration := whitespace name whitespace "=" freetext newline not sure if that covers everything... for example can a stanza have no declarations? > It appears that there is not a specific standard for ini files > (http://en.wikipedia.org/wiki/INI_file), so I think to move the fwiw, i took a look at the only C implementation mentioned in the wiki page there, and it definitely will not meet our needs. specifically there's no way to iterate across all of the declarations for a specific stanza (to use the terms given above). i also looked quickly through the debian package repository and didn't find any (C) libraries available for this, though there were some in perl which might work. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rouilj at cs.umb.edu Wed Jan 31 18:06:03 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 31 Jan 2007 12:06:03 -0500 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: Your message of "Wed, 31 Jan 2007 12:50:02 GMT." Message-ID: <200701311706.l0VH65ZI002941@mx1.cs.umb.edu> In message , Ton Voon writes: >STDIN SUPPORT > >John P Rouillard requests stdin support for passing data from Nagios' >config files. I think support for stdin (--default-opts=-) should be >fine on condition that the input file is not processed any >differently. John, would you still like this functionality? Yeah I think so. Even if Ethan doesn't like the concept of passing things on stdin, it could be used to allow: def_options $HOSTNAME$ $SERVICEDESC$ | check_something --default_opts=- ... where def_options pulls the data from a database or some other mechanism (e.g. encrypted config file using gpg key agent etc). I am also looking at using the def_options program to allow passing of environment variables such as SSH_AUTH_SOCK that allows passwordless ssh access using encrypted keys files. Keep meaning to fix the shell exec mechanism in nagios plugin library to allow the SSH auth variables through. Well that is for another thread. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj at cs.umb.edu Wed Jan 31 18:14:19 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 31 Jan 2007 12:14:19 -0500 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: Your message of "Wed, 31 Jan 2007 15:10:42 +0100." <20070131141042.GA1369@eric.schwarzvogel.de> Message-ID: <200701311714.l0VHELUp004683@mx1.cs.umb.edu> In message <20070131141042.GA1369 at eric.schwarzvogel.de>, Tobias Klausmann writes: >What about Quoting? are only double quotes (") allowed? what >about ''? Where is quoting needed? I.e. where will whitespace >stripping happen? Which also begs the question suppose I need to set the value: foo = He said "foo". How do I quote that? Does: foo= (arbitrary whitespace) " He said "foo"." (arbitrary whitespace) >Second, comments. Will leading whitespace on comment lines be >ignored? (I hope so). What about comments on non-comment-lines >like here: > >[check_foo] >username = default # temporary, will be change May 6th. If this is supported, "'s should be used to suppress the commentary meaning of # so that: username = "default # temporary, will be change May 6th." the username includes the entire phrase. Same if a ';' in a line is a comment character. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions.