From Ton.Voon at egg.com Mon Sep 1 00:57:10 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Mon Sep 1 00:57:10 2003 Subject: [Nagiosplug-devel] check_webapp plugin (very rough) Message-ID: Barry, Looks interesting, but what extra functionality does this provide over check_http? We don't really want to introduce a new plugin if the check can be done through an existing plugin (long-term, I think Karl is thinking of changing check_http to use curl). Ton > -----Original Message----- > From: Barry Roberts [mailto:manithree at crosswinds.net] > Sent: Saturday, August 30, 2003 12:52 AM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] check_webapp plugin (very rough) > > > I did this to replace Sitescope with nagios and it does 99% of what I > need right now. It uses curl to hit web apps and keep track of > cookies, search output etc. So it logs into my web apps, does things > to make sure all the backend servers (database, etc.) are all working. > > I would like to switch it over to pyCurl, but I don't know when I'll > have time for that. As is, I'm just looking for feedback on whether > there's any possibility or how much work it would take to get it > contributed as a standard plugin. > > Thanks, > Barry Roberts > > This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From Ton.Voon at egg.com Mon Sep 1 01:05:05 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Mon Sep 1 01:05:05 2003 Subject: [Nagiosplug-devel] porposal to clarify terms of submission Message-ID: I have setup a THANKS file in the top level of nagiosplug. This will take the list of contributors in ./AUTHORS and add it to THANKS.in. We can use this to keep a list of all contributors. I have gone through all CVS comments for all the code in plugins/ and plugin-scripts/ and code from March to get any names I could find. I still want to go through SF's tracker items, but I draw the line at the mailing list archives! When committing submissions or fixing bugs from a report, can I propose: - adding the contributor's name into the CVS comments - adding the contributor to the AUTHORS file I'll clarify this in the dev guidelines if everyone is happy about this. Ton > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Friday, August 22, 2003 1:11 PM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: RE: [Nagiosplug-devel] porposal to clarify terms of > submission > > > On Fri, 2003-08-22 at 06:33, Voon, Ton wrote: > > I don't fully understand all the copyright issues, but I > agree that the > > Nagios Plugin Development Group should bear the > responsibility, and thus the > > copyright, of all code distributed. > > > > As a former contributor, my only request was for a little > credit. I don't > > think this should be in the form of comments within the > code, but a clear > > document that says this person has made a contribution to > the project, like > > what Ethan has done at > http://www.nagios.org/contributors.php. This is why I > > always put down the contributor for bug reports or patches in CVS > > statements. > > Quite fair. > > I had in practice sort of pushed a certain anonnomity becuse in the > plugins the original practice hade been to attribute each > contribution. > The comments in some cases began to overwhelm the code, so that had to > stop. But in retrospect thaht should have causes me to put > more emphasis > on an external list like the one Ethan has. And into CVS > commits. I will > try to be more diligent about the latter. Perhaps we should > also make a > contrbutors page. > > > Ton > > > > > -----Original Message----- > > > From: Karl DeBisschop [mailto:karl at debisschop.net] > > > Sent: Friday, August 22, 2003 7:05 AM > > > To: NagiosPlug Devel > > > Subject: [Nagiosplug-devel] porposal to clarify terms of > submission > > > > > > > > > In the last round of cleanup, I have found a few times where > > > attribution > > > and current copyright has become murky. > > > > > > I'd like to clarify things in our public documents so > people know what > > > to expect. > > > > > > In my mind, this is the model under which we operate is as > > > follows. This > > > is a little scattershot, but should be a basis for comment. > > > Out of this > > > I hope to formulate some clearer policy statements to be > included with > > > the distribution. > > > > > > COPYRIGHT > > > > > > When a plugin is accepted, copyright is transferred to the 'Nagios > > > Plugin Developemnt Group." For our part, we will retain > credit to the > > > contributor preceding our copyright statement. But I > think we should > > > assert copyright as an entity to 1) protect changes we > make 2) be in a > > > position to defend copyright if need be [I fear that if > some sort of > > > challenge arose, we'd be so busy calrifying rights that > we'd be unable > > > to defend those rights]. > > > > > > A plugin becomes elegible for acceptance whenever a > > > contributor requests > > > that a plugin be placed in contrib (via deposit in the new plugins > > > tracker, or via request for inclusion to the list or to a > developer). > > > Simply posting code to the list does not make the plugin > eligible - > > > there may be a request to integrate. We should consider > > > adding a control > > > to the tracker allowing a contirbutor to indicate whether > or not the > > > plugin should be integrated. > > > > > > LICENSE > > > > > > The plugins are GPL. > > > > > > All tracker submissions should be GPL. > > > > > > Other open-source licenses will be tolerated on the > mailing lists, but > > > GPL is preferred. Any plugin that becomes integrated or > packaged with > > > the plugin must be GPL, however. > > > > > > RECONCILIATION > > > > > > When I took over development of the plugins a few years back, > > > there was > > > no sense of there being a development group. I made judgment > > > calls about > > > how to assign copyrights based on the degree to which I > had modified a > > > plugin. In retrospect I could/should have done better. But > > > that's water > > > under the bridge. > > > > > > Nonetheless, once these issues are documented, we should make > > > an effort > > > to contact the original contributors to be sure they do not > > > feel we are > > > infringing their rights. I'm not worried here - they were > submitted > > > under GPL. But I feel respect for other's contributions > requires us to > > > make the effort to document that there is no objection to our > > > asserting > > > copyright on the derived GPL'd work. > > > > > > INFRINGEMENT > > > > > > We should make explicit statements that no infringement of > > > intellectual > > > property will be tolerated. There should be some > indication of that on > > > the tracker used to submit contributed plugins. I am at a > loss for how > > > this might be 'enforced'. At a minimum, we should request > that if any > > > party sees a possible infringement, they should bring it to our > > > attention so it may be examined and corrected if need be. > > > > > > > > > > > > Any and all comments appreciated. > > > > > > -- > > > Karl This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From vfrpnah at t-dialin.net Mon Sep 1 02:53:03 2003 From: vfrpnah at t-dialin.net (Verona Hauser) Date: Mon Sep 1 02:53:03 2003 Subject: [Nagiosplug-devel] Livecam Botschaft für Nagiosplugdevel Message-ID: An HTML attachment was scrubbed... URL: From karl at debisschop.net Mon Sep 1 06:09:09 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Sep 1 06:09:09 2003 Subject: [Nagiosplug-devel] check_webapp plugin (very rough) In-Reply-To: References: Message-ID: <1062421629.2881.16.camel@miles.debisschop.net> On Mon, 2003-09-01 at 03:55, Voon, Ton wrote: > Barry, > > Looks interesting, but what extra functionality does this provide over > check_http? We don't really want to introduce a new plugin if the check can > be done through an existing plugin (long-term, I think Karl is thinking of > changing check_http to use curl). Yes. Long term, I'd like to replace the guts of check_http with rouintes in the curl libraries. That should give us acess to a great deal of functionality with fairly little programming required. -- Karl From karl at debisschop.net Mon Sep 1 06:11:02 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Sep 1 06:11:02 2003 Subject: [Nagiosplug-devel] porposal to clarify terms of submission In-Reply-To: References: Message-ID: <1062421769.2881.19.camel@miles.debisschop.net> On Mon, 2003-09-01 at 04:03, Voon, Ton wrote: > I have setup a THANKS file in the top level of nagiosplug. This will take > the list of contributors in ./AUTHORS and add it to THANKS.in. We can use > this to keep a list of all contributors. > > I have gone through all CVS comments for all the code in plugins/ and > plugin-scripts/ and code from March to get any names I could find. Saw your commit. Great work. > I still > want to go through SF's tracker items, but I draw the line at the mailing > list archives! > > When committing submissions or fixing bugs from a report, can I propose: > > - adding the contributor's name into the CVS comments > - adding the contributor to the AUTHORS file Agreed. > I'll clarify this in the dev guidelines if everyone is happy about this. As far as dev guidleines, let's go one step further - if you are reponding to a tracker submission, put the bug ID into CVS as well. -- Karl From manithree at crosswinds.net Mon Sep 1 07:03:10 2003 From: manithree at crosswinds.net (Barry Roberts) Date: Mon Sep 1 07:03:10 2003 Subject: [Nagiosplug-devel] check_webapp plugin (very rough) In-Reply-To: References: Message-ID: <20030901140151.GA6243@www.robertsr.us> Maybe I just couldn't figure out check_http, but there are 2 major things I couldn't make it do: First, I need to load several URL's in sequence in ONE check. For example, I have a test that logs in, loads up some data (through the web ui), changes it, does a calculation, then tests the result. It hits 10 urls, most of which have expressions to match in the resulting html. Second, the session cookie has to be maintained between these url hits. There's also another feature that I don't think check_http has that I CAN do with mine but haven't yet, and that is a dependent URL. The purpose of that is to load all the images, js, css etc. required for a page but including that in the performance info for the "main" url. I don't care how long each image, etc. load, just how long it takes to load the whole page. One minor thing I just remembered is that check_webapp can have a "must match" expression and a "must not match" expression for each URL. I only took a brief look at the check_http source, but it didn't seem to easily do everything I need to replace Sitecope. But if it will I would be happy to use it. The final thing I need to implement is another feature that Sitescope has. I have to have the capability to parse enough of the returned html to submit a form included in it. I think I can do that pretty easily in python. If I've underestimated check_http, I apologize. My plugin is pretty rough, but it was only a couple of hours of python hacking and an hour or so of testing. Would have been quicker if I knew Python already. And it is sure nice to be on nagios instead of expensive, flaky Sitescope. Thanks, Barry Roberts On Mon, Sep 01, 2003 at 08:55:43AM +0100, Voon, Ton wrote: > Barry, > > Looks interesting, but what extra functionality does this provide over > check_http? We don't really want to introduce a new plugin if the check can > be done through an existing plugin (long-term, I think Karl is thinking of > changing check_http to use curl). > > Ton From noreply at sourceforge.net Tue Sep 2 02:43:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 02:43:10 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-796661 ] New plugin : Apache/SOAP. Message-ID: New Plugins item #796661, was opened at 2003-08-28 15:17 Message generated for change (Comment added) made by rkarlsba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=796661&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Minati jean-michel (mr_magnet) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin : Apache/SOAP. Initial Comment: this plugin is used to test if a apache server running soap cgi , is working. there are 2 tests, one is a basic http POST (user supplied , the other is a call to a soap method( user supplied ). ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-09-02 11:42 Message: Logged In: YES user_id=145309 AFACS, this'll this work against other webservers, such as IIS. right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=796661&group_id=29880 From noreply at sourceforge.net Tue Sep 2 05:11:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 05:11:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-799098 ] mod for check_nt to fail if wrong client version Message-ID: Patches item #799098, was opened at 2003-09-02 12:10 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=799098&group_id=29880 Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Hanselman (stevehan) Assigned to: Nobody/Anonymous (nobody) Summary: mod for check_nt to fail if wrong client version Initial Comment: This patch amends check_nt to (optionally) support the -l parameter for the client version check, if the client is not running the version given as the parameter then it will enter a warning state. Makes for easier rollout of upgraded clients. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=799098&group_id=29880 From karl at debisschop.net Tue Sep 2 20:30:19 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Sep 2 20:30:19 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps? In-Reply-To: References: Message-ID: <1062559743.17150.55.camel@miles.debisschop.net> On Tue, 2003-09-02 at 22:27, Dag Wieers wrote: > On Wed, 3 Sep 2003, Peter Kiem wrote: > > 2. The /usr/share/doc/nagios-plugins-1.3.1/command.cfg file from the > > plugins package is the old non-template format and nagios from the package > > above complained about syntax errors in the command.cfg file and refused > > to run. > > The nagios-plugins project should ship an updated one then. Plugin developers - I think he's right - 1.4 should ship with templated format. Maybe we should grab a copy of the converter from nagios so we can continue to provide the old format without the need to maintain two config files? -- Karl From karl at debisschop.net Wed Sep 3 06:00:24 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Sep 3 06:00:24 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps? In-Reply-To: References: Message-ID: <1062593950.17150.150.camel@miles.debisschop.net> On Wed, 2003-09-03 at 08:22, Dag Wieers wrote: > You can look at the changes I've made at: > > http://dag.wieers.com/packages/nagios-plugins/nagios-plugins.spec > > It's not at all closed to the public :) I realize that. But without the explanations that you provide below, it can be hard to decide if changes need to be pushed back upstream, or it upstrem can do anything to help you. Thanks for your feedback. > Let me summarize the changes I've made: > > + I added some directives that my buildsystem uses as it seems that > %configure has a problem with Soapbox and I can't build nagios-plugins > parallellized. what is soapbox? > + I added a lot of BuildRequires (RH specific) to help people building > for RH. We try to keep our spec useful for Mandrake and Suse as well. But any BuidlRequires that apply generally should probably be pushed upstream (it looks like most or all can be). > + I had to disable INSTALL_OPTS for building as a user. Should probably be pushed upstream as well. Wonder what you're seeing that I did not, since I've alway built for RedHat. > + I change the location for the perl-binary and for the location of the > plugins. The Makefile does this. If it does not work, a bug report would help for perl location. For location of plugins, you do not configure in the libexecdir, so that's why it does not work for you. > + I also added something to compile 2 extra plugins that came in source. Those are in contrib, right? We typically don't package contirb plugins, but I'd like to set a goal for the 1.5 development cycle to try and move a variety of plugins from contrib to core. > + During the %install phase I add the utils.pm module to the perl module > path. (The alternative was to add -I flag to every perl-script that > needs it.) Now that CPAN has a Nagios namespace, we need to redo that, as will you (though your changes will be smaller than ours). > Not that many, but most are crucial for a working package. > > > > Dag, no offense, but why build your own spec? I have not yet compared > > your spec with CVS in sufficient detail, but I assume you've put some > > thought into it. Have we spoken? Have you brought the things you see as > > shortcomings to the attention of the developers so your improvements can > > be incorporated into the main code base? > > I have not. Not for the nagios-plugins anyway. I've mentioned the SPEC > file on the (nagios) mailinglist though, when I announced the packages. I'd like to go through this same excercise for nagios as well, if we could. Maybe after we release the plugins 1.4 alpha, I'll ask for a summary of what you see as shortcomings in that spec and build process. > > Since you clearly have access to a RedHat 7.3 machine, couldn't you > > engage with the devlopers to improve the spec in CVS and still also > > provide the service of testing releases on the the various releases and > > maikng those builds available? > > Actually I just have a 10GB partition that has 4 chroot-installed Red Hat > distributions. (RH62, RH73, RH80 and RH9) If you send me the tarball a > couple of days before releaseing, I can test-build and give you feedback > so that we can fix those things in the resulting release. That would be great. > > > I had to do a LOT of customisation to get this to run under Red Hat 7.3 > > > Although I understand Nagios is not for the novice users, these problems > > > with the plugins proved quite challenging to get it running! > > > > I submit that nagios and the plugins will be more advanced by working > > from the RPMs that are maintained by Ethan and by the nagios plugins > > development group. > > Well, Ethan doesn't build any RPM packages and I think the reported > problems are not different for the official packages or my packages. > > Nevertheless any feedback to improve the configuration or my packages > specifically is very welcome. I've learned that maybe I should put an > updated commands.cfg (from the nagios-plugins package) into /etc/nagios/ > (given that they work and consist of more plugins). But I will not let the > nagios-plugins package change files from the nagios-package. So I guess > the 2 projects have to agree on what files and what configuration they > ship to make it work without manual intervention :) We have always done exactly that - that is why nagios ships checkcommands.cfg and plugins ship commands.cfg - so the packages are independent. The two projects do agree on what file names to use - the agrrement is that nagios provides chackcommands, which tries to work across many plugin releases, while the plugins may provide more bleeding edge examples, but in a different file which the user must select. t occurs to me now that if the plugins chose command names that were non-overlapping with the names in nagios checkcommands.cfg, then both files could be included at the same time - that might further reduce the need for manual intervention. Many nagios would create an empty commands.cfg file in %post so the config would parse, but plugins would overwrite it? Just a half-formed thought, but maybe it would help. Thanks again. -- Karl From karl at debisschop.net Wed Sep 3 06:22:08 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Sep 3 06:22:08 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps? In-Reply-To: <1062593950.17150.150.camel@miles.debisschop.net> References: <1062593950.17150.150.camel@miles.debisschop.net> Message-ID: <1062595238.17150.159.camel@miles.debisschop.net> On Wed, 2003-09-03 at 08:59, Karl DeBisschop wrote: > On Wed, 2003-09-03 at 08:22, Dag Wieers wrote: > > + I had to disable INSTALL_OPTS for building as a user. > > Should probably be pushed upstream as well. Wonder what you're seeing > that I did not, since I've alway built for RedHat. Actually, I think the setting of AM_INSTALL_PROGRAM_FLAGS in the distibuted spec takes care of the issue. make \ AM_INSTALL_PROGRAM_FLAGS="" \ DESTDIR=${RPM_BUILD_ROOT} \ install I see that you use %makeinstall - does that provide any real utility? (I should go and find a description of what rpm macros are OK in LSB, unless there's a clear benefit otherwise, we try and keep the distribution spec compatible with LSB). -- Karl From dag at wieers.com Wed Sep 3 06:27:39 2003 From: dag at wieers.com (Dag Wieers) Date: Wed Sep 3 06:27:39 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps? In-Reply-To: <1062593950.17150.150.camel@miles.debisschop.net> Message-ID: On Wed, 3 Sep 2003, Karl DeBisschop wrote: > On Wed, 2003-09-03 at 08:22, Dag Wieers wrote: > > You can look at the changes I've made at: > > > > http://dag.wieers.com/packages/nagios-plugins/nagios-plugins.spec > > > > It's not at all closed to the public :) > > I realize that. But without the explanations that you provide below, it > can be hard to decide if changes need to be pushed back upstream, or it > upstrem can do anything to help you. Thanks for your feedback. I agree. > > Let me summarize the changes I've made: > > > > + I added some directives that my buildsystem uses as it seems that > > %configure has a problem with Soapbox and I can't build nagios-plugins > > parallellized. > > what is soapbox? A sandbox system I wrote to make building packages 'more' secure. See: http://dag.wieers.com/home-made/soapbox/ > > + I added a lot of BuildRequires (RH specific) to help people building > > for RH. > > We try to keep our spec useful for Mandrake and Suse as well. But any > BuidlRequires that apply generally should probably be pushed upstream > (it looks like most or all can be). I understand, conflict of interest ;) Beware that Mandrake mostly uses the lib%{name}-devel convention, so most BuildRequires will conflict ! > > + I had to disable INSTALL_OPTS for building as a user. > > Should probably be pushed upstream as well. Wonder what you're seeing > that I did not, since I've alway built for RedHat. Maybe it doesn't apply anymore. ;) > > + I change the location for the perl-binary and for the location of the > > plugins. > > The Makefile does this. If it does not work, a bug report would help for > perl location. For location of plugins, you do not configure in the > libexecdir, so that's why it does not work for you. Oh, but I do. The %configure macro expands to something that does --libexecdir="%{_libexecdir}". Maybe that is fixed by now, but it used to be a problem. You can look in the _buildlogs/ to see what it expands too and see if that is ok. > > + I also added something to compile 2 extra plugins that came in source. > > Those are in contrib, right? We typically don't package contirb plugins, > but I'd like to set a goal for the 1.5 development cycle to try and move > a variety of plugins from contrib to core. Well, I'm also not in favor of the check_cluster plugin, but we're using that because this functionality is missing from Nagios. And we don't have buildtools on any of our servers, so... > > + During the %install phase I add the utils.pm module to the perl module > > path. (The alternative was to add -I flag to every perl-script that > > needs it.) > > Now that CPAN has a Nagios namespace, we need to redo that, as will you > (though your changes will be smaller than ours). Ah, nice to know there's progress there. I don't like this particular fix as we put a generic named module in a more generic location. But since it's packaged, I don't mind that much as people can see where it comes from. > > I have not. Not for the nagios-plugins anyway. I've mentioned the SPEC > > file on the (nagios) mailinglist though, when I announced the packages. > > I'd like to go through this same excercise for nagios as well, if we > could. Maybe after we release the plugins 1.4 alpha, I'll ask for a > summary of what you see as shortcomings in that spec and build process. That would be great. > > Nevertheless any feedback to improve the configuration or my packages > > specifically is very welcome. I've learned that maybe I should put an > > updated commands.cfg (from the nagios-plugins package) into /etc/nagios/ > > (given that they work and consist of more plugins). But I will not let the > > nagios-plugins package change files from the nagios-package. So I guess > > the 2 projects have to agree on what files and what configuration they > > ship to make it work without manual intervention :) > > We have always done exactly that - that is why nagios ships > checkcommands.cfg and plugins ship commands.cfg - so the packages are > independent. The two projects do agree on what file names to use - the > agrrement is that nagios provides chackcommands, which tries to work > across many plugin releases, while the plugins may provide more bleeding > edge examples, but in a different file which the user must select. Ok, that's what I expect too. But what I didn't know was that the config file was still in an old format and that people were actually using it ;) > It occurs to me now that if the plugins chose command names that were > non-overlapping with the names in nagios checkcommands.cfg, then both > files could be included at the same time - that might further reduce the > need for manual intervention. Many nagios would create an empty > commands.cfg file in %post so the config would parse, but plugins would > overwrite it? Just a half-formed thought, but maybe it would help. Yes, that's exactly what I would do. Even better would be if Nagios wouldn't halt if a config-file doesn't exist. (Complain but continu if possible) What I also would change is the name. 'commands.cfg' 'misccommands.cfg' and 'checkcommands.cfg'. That's what I previously mentioned as being very confusing. I would also make a good distinction between notify-commands and checks. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Wed Sep 3 06:32:08 2003 From: dag at wieers.com (Dag Wieers) Date: Wed Sep 3 06:32:08 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps? In-Reply-To: <1062595238.17150.159.camel@miles.debisschop.net> Message-ID: On Wed, 3 Sep 2003, Karl DeBisschop wrote: > On Wed, 2003-09-03 at 08:59, Karl DeBisschop wrote: > > On Wed, 2003-09-03 at 08:22, Dag Wieers wrote: > > > > + I had to disable INSTALL_OPTS for building as a user. > > > > Should probably be pushed upstream as well. Wonder what you're seeing > > that I did not, since I've alway built for RedHat. > > Actually, I think the setting of AM_INSTALL_PROGRAM_FLAGS in the > distibuted spec takes care of the issue. > > > make \ > AM_INSTALL_PROGRAM_FLAGS="" \ > DESTDIR=${RPM_BUILD_ROOT} \ > install > > I see that you use %makeinstall - does that provide any real utility? (I > should go and find a description of what rpm macros are OK in LSB, > unless there's a clear benefit otherwise, we try and keep the > distribution spec compatible with LSB). %makeinstall adds the autotool variables prepended with the %{buildroot} so that eg. $(bindir) becoms %{buildroot}%{_bindir}. This makes sure that projects that don't supply a DESTDIR are still packaged correctly. However in some cases people use these variables also to rewrite directories and scripts (in the install phase) which breaks everything of course ;) That's why it's important that the make-phase prepares everything and the makeinstall phase only moves things around. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From noreply at sourceforge.net Wed Sep 3 07:09:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 3 07:09:13 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-796661 ] New plugin : Apache/SOAP. Message-ID: New Plugins item #796661, was opened at 2003-08-28 13:17 Message generated for change (Comment added) made by mr_magnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=796661&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Minati jean-michel (mr_magnet) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin : Apache/SOAP. Initial Comment: this plugin is used to test if a apache server running soap cgi , is working. there are 2 tests, one is a basic http POST (user supplied , the other is a call to a soap method( user supplied ). ---------------------------------------------------------------------- >Comment By: Minati jean-michel (mr_magnet) Date: 2003-09-03 14:08 Message: Logged In: YES user_id=854131 yes, it should works without troubles.trought I didn t tested it on anything else than apache. ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-09-02 09:42 Message: Logged In: YES user_id=145309 AFACS, this'll this work against other webservers, such as IIS. right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=796661&group_id=29880 From jchiantera at wtfe.com Wed Sep 3 11:58:02 2003 From: jchiantera at wtfe.com (Ing. Jose Chiantera) Date: Wed Sep 3 11:58:02 2003 Subject: [Nagiosplug-devel] check_dns Message-ID: <044101c3724d$21946f10$1a01a8c0@josechxp> Hi I have problems with check_dns, but only with one address libexec/check_dns -H www.yahoo.com -s 200.41.119.110 Memory fault (core dumped) All other server tested work fine Any idea Thanks Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SecurityCheck.txt Type: text/ignore Size: 43 bytes Desc: not available URL: From tonvoon at mac.com Wed Sep 3 12:32:13 2003 From: tonvoon at mac.com (Ton Voon) Date: Wed Sep 3 12:32:13 2003 Subject: [Nagiosplug-devel] Re: Trouble installing plugins - not templatedperhaps? In-Reply-To: <1062559743.17150.55.camel@miles.debisschop.net> Message-ID: <00D275FB-DE45-11D7-A56E-000A27E41300@mac.com> On Wednesday, September 3, 2003, at 04:29 am, Karl DeBisschop wrote: > On Tue, 2003-09-02 at 22:27, Dag Wieers wrote: >> On Wed, 3 Sep 2003, Peter Kiem wrote: > >>> 2. The /usr/share/doc/nagios-plugins-1.3.1/command.cfg file from the >>> plugins package is the old non-template format and nagios from the >>> package >>> above complained about syntax errors in the command.cfg file and >>> refused >>> to run. >> >> The nagios-plugins project should ship an updated one then. > > Plugin developers - I think he's right - 1.4 should ship with templated > format. Maybe we should grab a copy of the converter from nagios so we > can continue to provide the old format without the need to maintain two > config files? > > -- > Karl > I think we should only send out the templated format. I think I'm going to be overruled on this though. Ton From karl at debisschop.net Wed Sep 3 15:32:07 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Sep 3 15:32:07 2003 Subject: [Nagiosplug-devel] check_dns In-Reply-To: <044101c3724d$21946f10$1a01a8c0@josechxp> References: <044101c3724d$21946f10$1a01a8c0@josechxp> Message-ID: <1062628242.15442.2.camel@miles.debisschop.net> On Wed, 2003-09-03 at 14:56, Ing. Jose Chiantera wrote: > Hi > I have problems with check_dns, but only with one address > > libexec/check_dns -H www.yahoo.com -s 200.41.119.110 > Memory fault (core dumped) > > All other server tested work fine > > Any idea > > Thanks > Jose What version? (check_dns --version) -- Karl From karl at debisschop.net Wed Sep 3 15:36:02 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Sep 3 15:36:02 2003 Subject: [Nagiosplug-devel] Re: Trouble installing plugins - not templatedperhaps? In-Reply-To: <00D275FB-DE45-11D7-A56E-000A27E41300@mac.com> References: <00D275FB-DE45-11D7-A56E-000A27E41300@mac.com> Message-ID: <1062628474.15442.7.camel@miles.debisschop.net> On Wed, 2003-09-03 at 15:29, Ton Voon wrote: > On Wednesday, September 3, 2003, at 04:29 am, Karl DeBisschop wrote: > > > On Tue, 2003-09-02 at 22:27, Dag Wieers wrote: > >> On Wed, 3 Sep 2003, Peter Kiem wrote: > > > >>> 2. The /usr/share/doc/nagios-plugins-1.3.1/command.cfg file from the > >>> plugins package is the old non-template format and nagios from the > >>> package > >>> above complained about syntax errors in the command.cfg file and > >>> refused > >>> to run. > >> > >> The nagios-plugins project should ship an updated one then. > > > > Plugin developers - I think he's right - 1.4 should ship with templated > > format. Maybe we should grab a copy of the converter from nagios so we > > can continue to provide the old format without the need to maintain two > > config files? > > > > -- > > Karl > > > > I think we should only send out the templated format. I think I'm going > to be overruled on this though. I won't (can't?) overrule you. If there is a groundswell against the old style, I will back down. In fact, I'm a little sympathetic. But since I still see reports of people switching from netsaint, I suggest we ship both. I'd prefer to make the templated the master, but that would require writing a different conversion tool to go from templated to old-style. -- Karl From karl at debisschop.net Wed Sep 3 16:50:02 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Sep 3 16:50:02 2003 Subject: [Nagiosplug-devel] check_dns In-Reply-To: <04c501c3726b$91783ff0$1a01a8c0@josechxp> References: <044101c3724d$21946f10$1a01a8c0@josechxp> <1062628242.15442.2.camel@miles.debisschop.net> <04c501c3726b$91783ff0$1a01a8c0@josechxp> Message-ID: <1062632910.15442.10.camel@miles.debisschop.net> On Wed, 2003-09-03 at 18:34, Ing. Jose Chiantera wrote: > Hi > #./check_dns --version > check_dns (nagios-plugins 1.3.1) 1.8.2.3 > The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute > copies of the plugins under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING. > # $ check_dns -H www.yahoo.com -s 200.41.119.110 DNS ok - 1 seconds response time, Address(es) is/are 216.109.118.77 $ check_dns --version check_dns (nagios-plugins 1.3.1) 1.8.2.3 On RedHat 9. What OS are you using? -- Karl > > ----- Original Message ----- > From: "Karl DeBisschop" > To: "Ing. Jose Chiantera" > Cc: "NagiosPlug Devel" > Sent: Wednesday, September 03, 2003 6:30 PM > Subject: Re: [Nagiosplug-devel] check_dns > > > > On Wed, 2003-09-03 at 14:56, Ing. Jose Chiantera wrote: > > > Hi > > > I have problems with check_dns, but only with one address > > > > > > libexec/check_dns -H www.yahoo.com -s 200.41.119.110 > > > Memory fault (core dumped) > > > > > > All other server tested work fine > > > > > > Any idea > > > > > > Thanks > > > Jose > > > > What version? (check_dns --version) > > > > -- > > Karl > > > > > > Este e-mail fue revisado por el Antivirus. > > > > > > Este e-mail fue revisado por el Antivirus. From noreply at sourceforge.net Wed Sep 3 18:07:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 3 18:07:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-800147 ] check_arping - check host via ARP ping Message-ID: New Plugins item #800147, was opened at 2003-09-03 19:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=800147&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kenny Root (kruton) Assigned to: Nobody/Anonymous (nobody) Summary: check_arping - check host via ARP ping Initial Comment: This plugin will check hosts via ARP ping. This is useful for checking the status of hosts that don't normally respond to ICMP pings such as firewalls. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=800147&group_id=29880 From noreply at sourceforge.net Wed Sep 3 18:08:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 3 18:08:13 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-800147 ] check_arping - check host via ARP ping Message-ID: New Plugins item #800147, was opened at 2003-09-03 19:06 Message generated for change (Comment added) made by kruton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=800147&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kenny Root (kruton) Assigned to: Nobody/Anonymous (nobody) Summary: check_arping - check host via ARP ping Initial Comment: This plugin will check hosts via ARP ping. This is useful for checking the status of hosts that don't normally respond to ICMP pings such as firewalls. ---------------------------------------------------------------------- >Comment By: Kenny Root (kruton) Date: 2003-09-03 19:08 Message: Logged In: YES user_id=299111 This requires the Perl module Net::Arping ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=800147&group_id=29880 From noreply at sourceforge.net Thu Sep 4 11:50:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 11:50:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-800634 ] rrdtool support in mrtg Message-ID: Feature Requests item #800634, was opened at 2003-09-04 18:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=800634&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Steve Hanselman (stevehan) Assigned to: Nobody/Anonymous (nobody) Summary: rrdtool support in mrtg Initial Comment: Has anybody looked at creating a check_mrtg that uses the rrdtool database? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=800634&group_id=29880 From MAILER-DAEMON at aol.com Fri Sep 5 01:27:02 2003 From: MAILER-DAEMON at aol.com (Mail Delivery Subsystem) Date: Fri Sep 5 01:27:02 2003 Subject: [Nagiosplug-devel] Returned mail: User unknown Message-ID: <200309050825.EAE20417@rly-xm06.mx.aol.com> The original message was received at Fri, 5 Sep 2003 04:24:43 -0400 (EDT) from [212.103.21.30] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xm02.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 650 bytes Desc: not available URL: From Postmaster at talk21.com Fri Sep 5 02:21:06 2003 From: Postmaster at talk21.com (Mail Administrator) Date: Fri Sep 5 02:21:06 2003 Subject: [Nagiosplug-devel] Mail System Error - Returned Mail Message-ID: <20030905092010.NROW637.wmpmta01-app.mail-store.com@wmpmta01-app> This Message was undeliverable due to the following reason: The user(s) account is temporarily over quota. Please reply to Postmaster at talk21.com if you feel this message to be in error. -------------- next part -------------- An embedded message was scrubbed... From: Subject: Thank you! Date: Fri, 5 Sep 2003 11:18:57 +0200 Size: 98704 URL: From manithree at crosswinds.net Fri Sep 5 12:48:07 2003 From: manithree at crosswinds.net (Barry Roberts) Date: Fri Sep 5 12:48:07 2003 Subject: [Nagiosplug-devel] check_webapp plugin (very rough) In-Reply-To: References: Message-ID: <20030905194650.GB1645@www.robertsr.us> Hmm. I sent this Monday, but I don't see it in the archive. Did you get it? Date: Mon, 1 Sep 2003 08:01:51 -0600 From: Barry Roberts To: "Voon, Ton" , nagiosplug-devel at lists.sourceforge.net Subject: Re: [Nagiosplug-devel] check_webapp plugin (very rough) Message-ID: <20030901140151.GA6243 at www.robertsr.us> Reply-To: Barry Roberts References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Content-Length: 2007 Maybe I just couldn't figure out check_http, but there are 2 major things I couldn't make it do: First, I need to load several URL's in sequence in ONE check. For example, I have a test that logs in, loads up some data (through the web ui), changes it, does a calculation, then tests the result. It hits 10 urls, most of which have expressions to match in the resulting html. Second, the session cookie has to be maintained between these url hits. There's also another feature that I don't think check_http has that I CAN do with mine but haven't yet, and that is a dependent URL. The purpose of that is to load all the images, js, css etc. required for a page but including that in the performance info for the "main" url. I don't care how long each image, etc. load, just how long it takes to load the whole page. One minor thing I just remembered is that check_webapp can have a "must match" expression and a "must not match" expression for each URL. I only took a brief look at the check_http source, but it didn't seem to easily do everything I need to replace Sitecope. But if it will I would be happy to use it. The final thing I need to implement is another feature that Sitescope has. I have to have the capability to parse enough of the returned html to submit a form included in it. I think I can do that pretty easily in python. If I've underestimated check_http, I apologize. My plugin is pretty rough, but it was only a couple of hours of python hacking and an hour or so of testing. Would have been quicker if I knew Python already. And it is sure nice to be on nagios instead of expensive, flaky Sitescope. Thanks, Barry Roberts On Mon, Sep 01, 2003 at 08:55:43AM +0100, Voon, Ton wrote: > Barry, > > Looks interesting, but what extra functionality does this provide over > check_http? We don't really want to introduce a new plugin if the check can > be done through an existing plugin (long-term, I think Karl is thinking of > changing check_http to use curl). > > Ton From Ton.Voon at egg.com Sun Sep 7 22:58:03 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Sun Sep 7 22:58:03 2003 Subject: [Nagiosplug-devel] check_webapp plugin (very rough) Message-ID: Barry, Sorry, I haven't got round to responding. I was also kinda waiting for direction from Karl ;) You've highlighted the differences between your plugin and check_http and there is some good extra functionality. We can certainly add it into the contrib/ directory, but to move into the main plugin distribution will probably require some work in the framework as we currently do not have a utils.py for python scripts. Can you add the plugin to SF (see the developer's guidelines at http://nagiosplug.sourceforge.net/developer-guidelines.html) and we'll get round to including it in the future release. Ton > -----Original Message----- > From: Barry Roberts [mailto:manithree at crosswinds.net] > Sent: Friday, September 05, 2003 8:47 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: Re: [Nagiosplug-devel] check_webapp plugin (very rough) > > > Hmm. I sent this Monday, but I don't see it in the archive. > Did you get it? > > Date: Mon, 1 Sep 2003 08:01:51 -0600 > From: Barry Roberts > To: "Voon, Ton" , > nagiosplug-devel at lists.sourceforge.net > Subject: Re: [Nagiosplug-devel] check_webapp plugin (very rough) > Message-ID: <20030901140151.GA6243 at www.robertsr.us> > Reply-To: Barry Roberts > References: > > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > In-Reply-To: > > User-Agent: Mutt/1.5.4i > Content-Length: 2007 > > Maybe I just couldn't figure out check_http, but there are 2 major > things I couldn't make it do: > > First, I need to load several URL's in sequence in ONE check. For > example, I have a test that logs in, loads up some data (through the > web ui), changes it, does a calculation, then tests the result. It > hits 10 urls, most of which have expressions to match in the resulting > html. > > Second, the session cookie has to be maintained between these > url hits. > > There's also another feature that I don't think check_http has that I > CAN do with mine but haven't yet, and that is a dependent URL. The > purpose of that is to load all the images, js, css etc. required for a > page but including that in the performance info for the "main" url. I > don't care how long each image, etc. load, just how long it takes to > load the whole page. > > One minor thing I just remembered is that check_webapp can have a > "must match" expression and a "must not match" expression for each > URL. > > I only took a brief look at the check_http source, but it didn't seem > to easily do everything I need to replace Sitecope. But if it will I > would be happy to use it. > > The final thing I need to implement is another feature that Sitescope > has. I have to have the capability to parse enough of the returned > html to submit a form included in it. I think I can do that pretty > easily in python. > > If I've underestimated check_http, I apologize. My plugin is pretty > rough, but it was only a couple of hours of python hacking and an hour > or so of testing. Would have been quicker if I knew Python already. > And it is sure nice to be on nagios instead of expensive, flaky > Sitescope. > > Thanks, > Barry Roberts > > On Mon, Sep 01, 2003 at 08:55:43AM +0100, Voon, Ton wrote: > > Barry, > > > > Looks interesting, but what extra functionality does this > provide over > > check_http? We don't really want to introduce a new plugin > if the check can > > be done through an existing plugin (long-term, I think Karl > is thinking of > > changing check_http to use curl). > > > > Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From janl at linpro.no Mon Sep 8 17:49:48 2003 From: janl at linpro.no (Nicolai Langfeldt) Date: Mon Sep 8 17:49:48 2003 Subject: [Nagiosplug-devel] Conserver plugin for nagios Message-ID: <3F5C2F83.1050208@linpro.no> Hi, I understand that this is the place to submitt new plugins - Nathan didn't want them directly. For: Conserver (http://www.conserver.com/) check_conserver: Check that all consoles are connected and up. This should need no customizations as long as it's run on the conserver host. Regards, Nicolai Langfeldt From sghosh at sghosh.org Mon Sep 8 18:02:07 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Sep 8 18:02:07 2003 Subject: [Nagiosplug-devel] Conserver plugin for nagios In-Reply-To: <3F5C2F83.1050208@linpro.no> Message-ID: On Mon, 8 Sep 2003, Nicolai Langfeldt wrote: > Hi, > > I understand that this is the place to submitt new plugins - Nathan > didn't want them directly. > > For: Conserver (http://www.conserver.com/) > check_conserver: Check that all consoles are connected and up. This > should need no customizations as long as it's run on the conserver host. > > Regards, > Nicolai Langfeldt > > Actually the best place is to post the plugins on SourceForge (you will need a SourceForge id) http://sourceforge.net/tracker/?atid=541465&group_id=29880&func=browse -- -sg From karl at debisschop.net Mon Sep 8 18:11:03 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Sep 8 18:11:03 2003 Subject: [Nagiosplug-devel] Conserver plugin for nagios In-Reply-To: <3F5C2F83.1050208@linpro.no> References: <3F5C2F83.1050208@linpro.no> Message-ID: <1063069736.29779.7.camel@miles.debisschop.net> On Mon, 2003-09-08 at 03:28, Nicolai Langfeldt wrote: > Hi, > > I understand that this is the place to submitt new plugins - Nathan > didn't want them directly. > > For: Conserver (http://www.conserver.com/) > check_conserver: Check that all consoles are connected and up. This > should need no customizations as long as it's run on the conserver host. > > Regards, > Nicolai Langfeldt did you mean to attach something? Actaully, the best thing is to post to the new plugins tracker at http://sf.net/projects/nagiosplug/ -- Karl From gesem at interbusiness.it Mon Sep 8 20:16:16 2003 From: gesem at interbusiness.it (Gerd Meier) Date: Mon Sep 8 20:16:16 2003 Subject: [Nagiosplug-devel] Livecam Botschaft für Nagiosplugdevel Message-ID: An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Sep 8 23:21:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 8 23:21:25 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-802950 ] Check if conserver is up and consoles connected Message-ID: New Plugins item #802950, was opened at 2003-09-09 08:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=802950&group_id=29880 Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolai Langfeldt (janl) Assigned to: Nobody/Anonymous (nobody) Summary: Check if conserver is up and consoles connected Initial Comment: Conserver (http://www.conserver.com/) does centralized serial console management. To ensure complete console logs and availability of consoles at all times I've found a need to monitor it. Nicolai ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=802950&group_id=29880 From herdm at vnn.vn Tue Sep 9 19:23:09 2003 From: herdm at vnn.vn (Gerd Meier) Date: Tue Sep 9 19:23:09 2003 Subject: [Nagiosplug-devel] Livecam Botschaft für Nagiosplugdevel Message-ID: An HTML attachment was scrubbed... URL: From karl at debisschop.net Thu Sep 11 01:15:14 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Sep 11 01:15:14 2003 Subject: [Nagiosplug-devel] perf data gudelines Message-ID: <1063267882.30367.8.camel@miles.debisschop.net> in the perfdata, we have a format like: 'label'=value[UOM];[warn];[crit];[min];[max] There is a parameter in check_http to show an warning status if the page is less than a given size. I assume that normally, if [crit] was less than [warn], it would be clear to whatever handled the data that the critical raneg ran from 0 to [crit]. In this case, there's no [crit] (I guess I could say that [crit] is 0. Or could modify check_http so a critical saze can be given also) But I'm wondering how we should show something where 2 through 10 was OK, but less than 2 or greater than 10 was a warning state (process counting often has that sort of threshold structure). Any thoughts? -- Karl From chris at netservers.co.uk Thu Sep 11 03:36:18 2003 From: chris at netservers.co.uk (Chris Wilson) Date: Thu Sep 11 03:36:18 2003 Subject: [Nagiosplug-devel] Check_http status codes bug Message-ID: Hi all, We've been using Nagios and the associated plugins for a long time with great success. Thank you all very much for your hard work. We think we have found a problem with the check_http plugin. RFC 2616, for HTTP/1.1, defines all codes such as 3xx as redirections, all 4xx as client errors, and all 5xx as server errors. [cf. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1] However, check_http only checks for certain specific values, for example, 301-304 for redirect codes. As a result, it will not always detect errors. For example, when our Sun/Chilisoft ASP servers go down, they start to return error 507, but the check_http plugin treats this as a completely normal status code and does not report an error to Nagios. Please find attached a patch which, I believe, will tighten up the handling of status codes to more closely match the RFC. Also, it should no longer be possible for a status line like HTTP/1.1 200 OK i want to confuse you 404 to be treated as a 404 error, and some other invalid status lines will be detected and flagged as errors, which previously were not. I have verified that the patched check_http correctly detects 200, 404, and 507 status codes in test cases, but it has not been tested much further yet. Nevertheless, it appears to work well enough that we plan to apply it to our production systems immediately. Please could you consider this patch for application to the official distribution of the check_http plugin. Cheers, Chris. -- ___ __ _ / __// / ,__(_)_ | Chris Wilson -- UNIX Firewall Lead Developer | / (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk | \ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 | -------------- next part -------------- diff -ru2 nagios-plugins-1.3.1/plugins/check_http.c nagios-plugins-1.3.1-chris/plugins/check_http.c --- nagios-plugins-1.3.1/plugins/check_http.c Mon Jun 30 12:56:08 2003 +++ nagios-plugins-1.3.1-chris/plugins/check_http.c Thu Sep 11 11:06:27 2003 @@ -540,4 +540,5 @@ char *msg = NULL; char *status_line = ""; + char *status_ptr; char *header = NULL; char *page = ""; @@ -551,4 +552,5 @@ char *orig_url = NULL; double elapsed_time; + int status_code; #ifdef HAVE_SSL int sslerr; @@ -713,26 +715,56 @@ /* check the return code */ /* server errors result in a critical state */ - if (strstr (status_line, "500") || - strstr (status_line, "501") || - strstr (status_line, "502") || - strstr (status_line, "503")) { - terminate (STATE_CRITICAL, "HTTP CRITICAL: %s\n", status_line); - } - /* client errors result in a warning state */ - if (strstr (status_line, "400") || - strstr (status_line, "401") || - strstr (status_line, "402") || - strstr (status_line, "403") || - strstr (status_line, "404")) { - terminate (STATE_WARNING, "HTTP WARNING: %s\n", status_line); + status_ptr = status_line; + + /* According to RFC 2616 (HTTP/1.1): + * Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase + * CRLF + */ + + /* we already checked that the version is HTTP/1.x, so + skip the HTTP-Version completely */ + + while (*status_ptr != 0 && *status_ptr != 32) + status_ptr++; + + if (*status_ptr != 32) + terminate (STATE_CRITICAL, + "HTTP CRITICAL: invalid status line: %s\n", + status_line); + + /* skip the space */ + status_ptr++; + + /* check that the next three characters are digits */ + for (i = 0; i < 3; i++) { + if (status_ptr[i] < '0' || status_ptr[i] > '9') { + terminate (STATE_CRITICAL, + "HTTP CRITICAL: invalid status code: " + "%s\n", status_line); + } } + /* check that the next character is a space */ + if (status_ptr[3] != 32) + terminate (STATE_CRITICAL, + "HTTP CRITICAL: invalid status line: %s\n", + status_line); + + /* it should now be safe to use atoi on the status_ptr */ + status_code = atoi(status_ptr); + + /* server errors (5xx) result in a critical state */ + if (status_ptr[0] == '5') + terminate (STATE_CRITICAL, "HTTP CRITICAL: %s\n", + status_line); + + /* client errors (4xx) result in a warning state */ + if (status_ptr[0] == '4') + terminate (STATE_WARNING, "HTTP WARNING: %s\n", + status_line); + /* check redirected page if specified */ - if (strstr (status_line, "300") || - strstr (status_line, "301") || - strstr (status_line, "302") || - strstr (status_line, "303") || - strstr (status_line, "304")) { + if (status_ptr[0] == '3') { if (onredirect == STATE_DEPENDENT) { @@ -805,5 +837,5 @@ (display_html ? "" : ""), elapsed_time); terminate (onredirect, msg); - } /* end if (strstr (status_line, "30[0-4]") */ + } /* end if (status_ptr[0] == 3) */ From Ton.Voon at egg.com Thu Sep 11 03:38:17 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Thu Sep 11 03:38:17 2003 Subject: [Nagiosplug-devel] perf data gudelines Message-ID: > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Thursday, September 11, 2003 9:11 AM > To: NagiosPlug Devel > Subject: [Nagiosplug-devel] perf data gudelines > > > in the perfdata, we have a format like: > > 'label'=value[UOM];[warn];[crit];[min];[max] > > There is a parameter in check_http to show an warning status > if the page > is less than a given size. > > I assume that normally, if [crit] was less than [warn], it would be > clear to whatever handled the data that the critical raneg > ran from 0 to > [crit]. I think this is a range issue, rather than a perfdata issue. Maybe we need a clarification on ranges in the dev guidelines. I think we should take the general case for ranges from check_procs: 1) alert if metric outside start:end where start < end, start (and ":") not required if 0 2) if end not specified, assume infinity 3) if start > end, then alert if inside this range (A few thoughts: I don't like the specification for (3) - I'd much prefer some identifier like "*start:end" to mean "inclusive alert"; also how do you specify negative infinity?) So the perf data ranges will take the same format as the warn and crit ranges with the same meaning. Shall I document this (with the proviso that not all plugins use this range definition yet)? > In this case, there's no [crit] (I guess I could say that [crit] is 0. > Or could modify check_http so a critical saze can be given also) I would put crit as undefined to mean there is no critical level. > But I'm wondering how we should show something where 2 through 10 was > OK, but less than 2 or greater than 10 was a warning state (process > counting often has that sort of threshold structure). With the ranges specified, I think a clever Nagiosplugins->RRD tool could draw the appropriate alert areas in yellow and red with the line of data in black. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From amoore at dekalbmemorial.com Thu Sep 11 08:35:09 2003 From: amoore at dekalbmemorial.com (Aaron Moore) Date: Thu Sep 11 08:35:09 2003 Subject: [Nagiosplug-devel] Changes to the check_apc_ups.pl script in contrib Message-ID: <3F604F0D.18257.3AD6BED@localhost> I've attached a diff file of changes I've made to the check_apc_ups.pl plugin. Improvements include using Net::SNMP instead of using the external snmpget program. And correcting the output of the plugin so that nagios will display all of the information that it returns. -- Aaron Moore Systems Support Specialist Information Systems DeKalb Memorial Hospital (260) 920-2808 -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: check_apc_ups.pl.diff Date: 11 Sep 2003, 10:26 Size: 2706 bytes. Type: Text -------------- next part -------------- A non-text attachment was scrubbed... Name: check_apc_ups.pl.diff Type: application/octet-stream Size: 2706 bytes Desc: not available URL: From p.allen at brandblue.co.uk Thu Sep 11 09:16:46 2003 From: p.allen at brandblue.co.uk (Patrick Allen) Date: Thu Sep 11 09:16:46 2003 Subject: [Nagiosplug-devel] check_ping patch for 'RedHat' Message-ID: <3F609BD4.4070706@brandblue.co.uk> After hacking away at the old netsaint check_ping plugin to patch for yet another ping format i eventually gave up and installed Nagios. To my pleasure the "OK" (success) message now works however under RedHat (9) i found that the "CRITICAL" message failed with a: > Error: Could not interpret output from ping command This was simply resolved with the following: > || sscanf (input_buffer, "%*d packets transmitted, %*d received, +%*d errors, %d%% packet loss", &pl) == 1 The fuller system profile is: RedHat 9.0 uname -a Linux 2.4.20-19.9 #1 Tue Jul 15 17:18:13 EDT 2003 i686 i686 i386 GNU/Linux ping -V ping utility, iputils-ss020927 -- "Let them eat cake, and run Windows and MacOS, I say! If they want to use Linux, they'll have to learn regular expressions. :)" Patrick Allen Brand Blue Ltd Web Developer T: 01865 762244 / F: 01865 768400 / E: p.allen at brandblue.co.uk From karl at debisschop.net Thu Sep 11 19:35:47 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Sep 11 19:35:47 2003 Subject: [Nagiosplug-devel] Check_http status codes bug In-Reply-To: References: Message-ID: <1063332164.22988.1.camel@miles.debisschop.net> On Thu, 2003-09-11 at 06:24, Chris Wilson wrote: > Hi all, > > We've been using Nagios and the associated plugins for a long time with > great success. Thank you all very much for your hard work. > > We think we have found a problem with the check_http plugin. RFC 2616, for > HTTP/1.1, defines all codes such as 3xx as redirections, all 4xx as client > errors, and all 5xx as server errors. > [cf. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1] > > However, check_http only checks for certain specific values, for example, > 301-304 for redirect codes. As a result, it will not always detect errors. > > For example, when our Sun/Chilisoft ASP servers go down, they start to > return error 507, but the check_http plugin treats this as a completely > normal status code and does not report an error to Nagios. > > Please find attached a patch which, I believe, will tighten up the > handling of status codes to more closely match the RFC. Also, it should no > longer be possible for a status line like > > HTTP/1.1 200 OK i want to confuse you 404 > > to be treated as a 404 error, and some other invalid status lines will be > detected and flagged as errors, which previously were not. > Thanks for the patch. Your read of the RFC seems corrct, and I will put some variant of that patch into the CVS HEAD shortly -- Karl From karl at debisschop.net Thu Sep 11 20:26:28 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Sep 11 20:26:28 2003 Subject: [Nagiosplug-devel] perf data gudelines In-Reply-To: References: Message-ID: <1063333116.22988.18.camel@miles.debisschop.net> On Thu, 2003-09-11 at 06:32, Voon, Ton wrote: > > -----Original Message----- > > From: Karl DeBisschop [mailto:karl at debisschop.net] > > Sent: Thursday, September 11, 2003 9:11 AM > > To: NagiosPlug Devel > > Subject: [Nagiosplug-devel] perf data gudelines > > > > > > in the perfdata, we have a format like: > > > > 'label'=value[UOM];[warn];[crit];[min];[max] > > > > There is a parameter in check_http to show an warning status > > if the page > > is less than a given size. > > > > I assume that normally, if [crit] was less than [warn], it would be > > clear to whatever handled the data that the critical raneg > > ran from 0 to > > [crit]. > > I think this is a range issue, rather than a perfdata issue. Maybe we need a > clarification on ranges in the dev guidelines. So the general case for [warn] and [crit] becomes [num]:[num] - makes parsing a little harder, but I guess it's logical. > I think we should take the general case for ranges from check_procs: > 1) alert if metric outside start:end where start < end, start (and ":") not > required if 0 > 2) if end not specified, assume infinity > 3) if start > end, then alert if inside this range > > (A few thoughts: I don't like the specification for (3) - I'd much prefer > some identifier like "*start:end" to mean "inclusive alert"; also how do you > specify negative infinity?) When I came up with the rules above, without realizing it, I assumed that all number were non-negative. Do you have a proposed fix for this that we should try and get in before we relase the 1.4.x alpha with its perf data fields? > So the perf data ranges will take the same format as the warn and crit > ranges with the same meaning. > > Shall I document this (with the proviso that not all plugins use this range > definition yet)? OK with me > > In this case, there's no [crit] (I guess I could say that [crit] is 0. > > Or could modify check_http so a critical saze can be given also) > > I would put crit as undefined to mean there is no critical level. since 0 is the lowest limit for page size, I think in this case it sort of works. In the general case you are right. > > But I'm wondering how we should show something where 2 through 10 was > > OK, but less than 2 or greater than 10 was a warning state (process > > counting often has that sort of threshold structure). > > With the ranges specified, I think a clever Nagiosplugins->RRD tool could > draw the appropriate alert areas in yellow and red with the line of data in > black. The definition of 'clever tool' keeps expanding here. Oh well, it won't be written in any case until there are rules on the inputs. > Ton > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. From karl at debisschop.net Fri Sep 12 04:50:25 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Sep 12 04:50:25 2003 Subject: [Nagiosplug-devel] perf data gudelines In-Reply-To: References: Message-ID: <1063366403.22988.37.camel@miles.debisschop.net> On Fri, 2003-09-12 at 07:08, Voon, Ton wrote: > > > I think this is a range issue, rather than a perfdata > > issue. Maybe we need a > > > clarification on ranges in the dev guidelines. > > > > So the general case for [warn] and [crit] becomes [num]:[num] - makes > > parsing a little harder, but I guess it's logical. > > This was the reason for using ";" as the delimiters - because ":" was > reserved for ranges. Good design choice. I kust missed that implication when it was proposed. > > > I think we should take the general case for ranges from check_procs: > > > 1) alert if metric outside start:end where start < end, > > start (and ":") not > > > required if 0 > > > 2) if end not specified, assume infinity > > > 3) if start > end, then alert if inside this range > > > > > > (A few thoughts: I don't like the specification for (3) - > > I'd much prefer > > > some identifier like "*start:end" to mean "inclusive > > alert"; also how do you > > > specify negative infinity?) > > > > When I came up with the rules above, without realizing it, I assumed > > that all number were non-negative. > > > > Do you have a proposed fix for this that we should try and > > get in before > > we relase the 1.4.x alpha with its perf data fields? > > I think this is starting to be like those obscure regex rules which no one > uses, but makes sense to define for completeness. > > I propose changing rule 3 and adding rule 2.5 so that: > 3) If range starts with an "@", then alert if inside this range Inclusive of the range endpoints? Since we are trying to be consistent with option parsing for the plugins, I assume we'd push this idea back into the plugins as well. So 3:5 would mean exactly he same as 5:3 ? Or would we retain the old syntax (for parsing --crit options) too ? > 2.5) to specify negative infinity, use ^ Why ^ ? Too many regexs, but that makes me thing of 'the beginning' whereas 'negatinve infinity' is not a definite number thus cannot be a place. Would ~ be OK as instead - I don't know that any symbol would be intuitive, but ~ does not feel counterintuitive or as overloaded to me. But if you might well have a logic for choosing ^ that I'm missing. > Of course, the next step is for a single plugin to have different metric > checks (eg, check_http --time-warn= --time-crit= --size-warn= --size-crit=). > Sigh. That is the step we are at - there is a min-size parameter, it was not implemented to look like a general warning threshols, but it clearly is a threshold, and I plan to generallize it. > > > With the ranges specified, I think a clever > > Nagiosplugins->RRD tool could > > > draw the appropriate alert areas in yellow and red with the > > line of data in > > > black. > > > > The definition of 'clever tool' keeps expanding here. Oh > > well, it won't > > be written in any case until there are rules on the inputs. > > > > I think if we have good standards, it should be relatively easy to write the > tool. I'm just avoiding doing it myself ;o) Take away the wink - that's why I'm trying to work this out - someone will need to write the tool. I don't know if it will be me, but it could be. -- Karl From Ton.Voon at egg.com Fri Sep 12 05:24:19 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Fri Sep 12 05:24:19 2003 Subject: [Nagiosplug-devel] perf data gudelines Message-ID: > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Friday, September 12, 2003 3:19 AM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: RE: [Nagiosplug-devel] perf data gudelines > > > On Thu, 2003-09-11 at 06:32, Voon, Ton wrote: > > > -----Original Message----- > > > From: Karl DeBisschop [mailto:karl at debisschop.net] > > > Sent: Thursday, September 11, 2003 9:11 AM > > > To: NagiosPlug Devel > > > Subject: [Nagiosplug-devel] perf data gudelines > > > > > > > > > in the perfdata, we have a format like: > > > > > > 'label'=value[UOM];[warn];[crit];[min];[max] > > > > > > There is a parameter in check_http to show an warning status > > > if the page > > > is less than a given size. > > > > > > I assume that normally, if [crit] was less than [warn], > it would be > > > clear to whatever handled the data that the critical raneg > > > ran from 0 to > > > [crit]. > > > > I think this is a range issue, rather than a perfdata > issue. Maybe we need a > > clarification on ranges in the dev guidelines. > > So the general case for [warn] and [crit] becomes [num]:[num] - makes > parsing a little harder, but I guess it's logical. This was the reason for using ";" as the delimiters - because ":" was reserved for ranges. > > I think we should take the general case for ranges from check_procs: > > 1) alert if metric outside start:end where start < end, > start (and ":") not > > required if 0 > > 2) if end not specified, assume infinity > > 3) if start > end, then alert if inside this range > > > > (A few thoughts: I don't like the specification for (3) - > I'd much prefer > > some identifier like "*start:end" to mean "inclusive > alert"; also how do you > > specify negative infinity?) > > When I came up with the rules above, without realizing it, I assumed > that all number were non-negative. > > Do you have a proposed fix for this that we should try and > get in before > we relase the 1.4.x alpha with its perf data fields? I think this is starting to be like those obscure regex rules which no one uses, but makes sense to define for completeness. I propose changing rule 3 and adding rule 2.5 so that: 3) If range starts with an "@", then alert if inside this range 2.5) to specify negative infinity, use ^ Of course, the next step is for a single plugin to have different metric checks (eg, check_http --time-warn= --time-crit= --size-warn= --size-crit=). Sigh. > > > So the perf data ranges will take the same format as the > warn and crit > > ranges with the same meaning. > > > > Shall I document this (with the proviso that not all > plugins use this range > > definition yet)? > > OK with me I'll add this in the next few days. > > > > In this case, there's no [crit] (I guess I could say that > [crit] is 0. > > > Or could modify check_http so a critical saze can be given also) > > > > I would put crit as undefined to mean there is no critical level. > > since 0 is the lowest limit for page size, I think in this > case it sort > of works. In the general case you are right. > > > > But I'm wondering how we should show something where 2 > through 10 was > > > OK, but less than 2 or greater than 10 was a warning > state (process > > > counting often has that sort of threshold structure). > > > > With the ranges specified, I think a clever > Nagiosplugins->RRD tool could > > draw the appropriate alert areas in yellow and red with the > line of data in > > black. > > The definition of 'clever tool' keeps expanding here. Oh > well, it won't > be written in any case until there are rules on the inputs. > I think if we have good standards, it should be relatively easy to write the tool. I'm just avoiding doing it myself ;o) Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From t.howat at linst.ac.uk Fri Sep 12 06:52:35 2003 From: t.howat at linst.ac.uk (Tony Howat) Date: Fri Sep 12 06:52:35 2003 Subject: [Nagiosplug-devel] check_nwstat.c alterations Message-ID: <3F61CB5B.4030508@linst.ac.uk> Hi there, I've altered check_nwstat.c from the 1.4 release to a) work without segfaulting b) add a PCBUFF option to return percentage of cache buffers remaining. My altered code is at http://www.i-r-genius.com/check_nwstat.c I'd appreciate it if the alterations could be merged into the build. We're now happily using nagios to monitor our infrastructure. Thanks guys :) -- Tony Howat UNIX Network Administrator The London Institute From matt.pounsett at cira.ca Fri Sep 12 11:27:20 2003 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Fri Sep 12 11:27:20 2003 Subject: [Nagiosplug-devel] -C arg to check_http loses data Message-ID: My apologies if this is a known problem.. I was unable to find any previous reports of this error in the nagiosplug-devel or nagiosplug-help list archives. It would appear that the certificate expiry data reported by the -C argument to check_http is being truncated. Unfortunately my C coding skill aren't up to the task of tracking down the cause, or supplying a fix for this. Here is some example output from my system: For a certificate which expires 06/21/2004 17:59:47 GMT: Certificate will expire on 06/21/2004 17:5. And for an old, expired cerificate (expired 22/06/2001 17:43:59 GMT): Certificate expired on 06/22/2001 17:4. This is using check_http (nagios-plugins 1.3.1) 1.24.2.4 compiled and run on RedHat 7.3. I'm perfectly willing to do further testing/troubleshooting, if anyone can think of more information which would be helpful in tracking down the error. Cheers, Matt Pounsett -- Matt Pounsett CIRA - Canadian Internet Registration Authority Technical Support Programmer 350 Sparks Street, Suite 1110 matt.pounsett at cira.ca Ottawa, Ontario, Canada 613.237.5335 ext. 231 http://www.cira.ca From Ton.Voon at egg.com Fri Sep 12 12:55:15 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Fri Sep 12 12:55:15 2003 Subject: [Nagiosplug-devel] perf data gudelines Message-ID: > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Friday, September 12, 2003 12:33 PM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: RE: [Nagiosplug-devel] perf data gudelines > > > On Fri, 2003-09-12 at 07:08, Voon, Ton wrote: > > > > > I think this is a range issue, rather than a perfdata > > > issue. Maybe we need a > > > > clarification on ranges in the dev guidelines. > > > > > > So the general case for [warn] and [crit] becomes > [num]:[num] - makes > > > parsing a little harder, but I guess it's logical. > > > > This was the reason for using ";" as the delimiters - > because ":" was > > reserved for ranges. > > Good design choice. I kust missed that implication when it > was proposed. > > > > > I think we should take the general case for ranges from > check_procs: > > > > 1) alert if metric outside start:end where start < end, > > > start (and ":") not > > > > required if 0 > > > > 2) if end not specified, assume infinity > > > > 3) if start > end, then alert if inside this range > > > > > > > > (A few thoughts: I don't like the specification for (3) - > > > I'd much prefer > > > > some identifier like "*start:end" to mean "inclusive > > > alert"; also how do you > > > > specify negative infinity?) > > > > > > When I came up with the rules above, without realizing > it, I assumed > > > that all number were non-negative. > > > > > > Do you have a proposed fix for this that we should try and > > > get in before > > > we relase the 1.4.x alpha with its perf data fields? > > > > I think this is starting to be like those obscure regex > rules which no one > > uses, but makes sense to define for completeness. > > > > I propose changing rule 3 and adding rule 2.5 so that: > > 3) If range starts with an "@", then alert if inside this range > > Inclusive of the range endpoints? I say yes. Exclusive takes values inclusive too. I think it will be too difficult to try and have an inclusive and exclusive option. > > Since we are trying to be consistent with option parsing for the > plugins, I assume we'd push this idea back into the plugins > as well. So > 3:5 would mean exactly he same as 5:3 ? Or would we retain the old > syntax (for parsing --crit options) too ? I don't know about 5:3. I'm picturing a generic function for parsing ranges and checking thresholds and I reckon 5:3 would be an error. > > > 2.5) to specify negative infinity, use ^ > > Why ^ ? Too many regexs, but that makes me thing of 'the beginning' > whereas 'negatinve infinity' is not a definite number thus cannot be a > place. Would ~ be OK as instead - I don't know that any > symbol would be > intuitive, but ~ does not feel counterintuitive or as > overloaded to me. > But if you might well have a logic for choosing ^ that I'm missing. I only thought of ^ as "start", but I guess regex considers this as 0, rather than negative infinity. ~ is fine with me. > > > Of course, the next step is for a single plugin to have > different metric > > checks (eg, check_http --time-warn= --time-crit= > --size-warn= --size-crit=). > > Sigh. > > That is the step we are at - there is a min-size parameter, it was not > implemented to look like a general warning threshols, but it > clearly is > a threshold, and I plan to generallize it. > > > > > With the ranges specified, I think a clever > > > Nagiosplugins->RRD tool could > > > > draw the appropriate alert areas in yellow and red with the > > > line of data in > > > > black. > > > > > > The definition of 'clever tool' keeps expanding here. Oh > > > well, it won't > > > be written in any case until there are rules on the inputs. > > > > > > > I think if we have good standards, it should be relatively > easy to write the > > tool. I'm just avoiding doing it myself ;o) > > Take away the wink - that's why I'm trying to work this out - someone > will need to write the tool. I don't know if it will be me, > but it could > be. Don't mean to overload you with work. I currently have an rrdgraphing tool in perl that we use internally based on the old style perf data format. I plan on updating it when we move to r1.4, but I don't know if it is good enough for publishing. Do you plan to make this range stuff consistent in r1.4 or leave till r1.5? I vote to leave till r1.5. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From karl at debisschop.net Sun Sep 14 06:39:06 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Sun Sep 14 06:39:06 2003 Subject: [Nagiosplug-devel] -C arg to check_http loses data In-Reply-To: References: Message-ID: <1063546646.13553.2.camel@miles.debisschop.net> On Fri, 2003-09-12 at 14:11, Matt Pounsett wrote: > My apologies if this is a known problem.. I was unable to find any previous > reports of this error in the nagiosplug-devel or nagiosplug-help list > archives. This was already noted and fixed in CVS (stable and head). Here is the changelog: $ cvs log check_http.c revision 1.24.2.6 date: 2003/08/22 04:42:55; author: kdebisschop; state: Exp; * bugfix: snprintf of timestamp truncated '\0' -- Karl From noreply at sourceforge.net Mon Sep 15 00:19:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 00:19:22 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-806358 ] check veritas netbackup (up to 3.4) tapedrives Message-ID: New Plugins item #806358, was opened at 2003-09-15 09:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=806358&group_id=29880 Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolai Langfeldt (janl) Assigned to: Nobody/Anonymous (nobody) Summary: check veritas netbackup (up to 3.4) tapedrives Initial Comment: Veritas Netbackup is a crossplatform backup package. This plugin checks the tape-drive status in versions up to netbackup 3.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=806358&group_id=29880 From noreply at sourceforge.net Mon Sep 15 00:22:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 00:22:24 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-806360 ] Check veritas netbackup (4.5, and up) tapedrives Message-ID: New Plugins item #806360, was opened at 2003-09-15 09:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=806360&group_id=29880 Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolai Langfeldt (janl) Assigned to: Nobody/Anonymous (nobody) Summary: Check veritas netbackup (4.5, and up) tapedrives Initial Comment: This plugin is for netbackup 4.5 (and probably higher versions). In 4.5 tape-drives can be taken down on a host to host basis and another command is needed to access this information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=806360&group_id=29880 From noreply at sourceforge.net Mon Sep 15 03:52:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 03:52:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-806445 ] check_nwstat.c segfault fix and enhancement Message-ID: Patches item #806445, was opened at 2003-09-15 10: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=806445&group_id=29880 Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Howat (xargle) Assigned to: Nobody/Anonymous (nobody) Summary: check_nwstat.c segfault fix and enhancement Initial Comment: Fixes segfault in check_nwstat and adds PCBUFF percentage of original cache buffers monitoring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 From noreply at sourceforge.net Mon Sep 15 07:19:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 07:19:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-778644 ] check_http cookies and keep-alive support Message-ID: Patches item #778644, was opened at 2003-07-27 23:58 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=778644&group_id=29880 Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitri Smirnov (trbmaker) >Assigned to: Ton Voon (tonvoon) Summary: check_http cookies and keep-alive support Initial Comment: Finally found a problem with my initial patch. Some IIS servers are not respond if Keep-Alive header supplied in request. I've made new patch for check_http 1.3.1 with 'Keep- Alive' disabled by default (option '-k' to enable). Patch attached below. -----Original Message----- From: Voon, Ton [mailto:Ton.Voon at egg.com] Sent: Tuesday, July 15, 2003 9:04 AM To: Dmitri Smirnov; nagiosplug- devel at lists.sourceforge.net Subject: RE: [Nagiosplug-devel] check_http cookie and app-proxy support Dmitri, Thanks very much for your patch. I'm sorry it has taken so long to look at it. I've given it a try and it seems to work okay with sites that do set cookies. However, it seems to fail when a site does not check for cookies - it just hangs when querying the site. I think there's a bug in your patch somewhere? If you do update your patch, please post on sourceforge so we can keep track of it: http://sourceforge.net/tracker/? group_id=29880&atid=397599 Thanks, Ton > -----Original Message----- > From: Dmitri Smirnov [mailto:Dmitri.Smirnov at fusepoint.com] > Sent: Monday, July 07, 2003 6:04 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] check_http cookie and app-proxy support > > > Hi guys, > > I've found a number of sites on our infrastructure that require > check_http plugin to have cookie support for sessions management and > 'Connection: Keep-Alive' in HTTP header to work correctly. > Below is a little patch for check_http (latest from CVS) I've made. > Will apriciate, guys, if you will review and incorporate such > functionality in standard check_http (wrapped by cmd arguments > probably). > > Dmitri > ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 15:18 Message: Logged In: YES user_id=664364 Dmitri, Thanks for this patch, but I'm having trouble adding it into check_http.c. Can you provide a unified diff against CVS HEAD? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=778644&group_id=29880 From noreply at sourceforge.net Mon Sep 15 07:28:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 07:28:03 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-781227 ] Can now specify a port for check_disk_smb to use. Message-ID: Patches item #781227, was opened at 2003-08-01 02:20 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=781227&group_id=29880 Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jason Burnett (trig_monkeypr0n) >Assigned to: Ton Voon (tonvoon) Summary: Can now specify a port for check_disk_smb to use. Initial Comment: We needed the ability to specify which port to connect (139 or 445) depending on the host. This patch allows you to specify or leave it blank and use the default of your smbclient. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 15:27 Message: Logged In: YES user_id=664364 Jason, Thanks for the patch. Added into check_disk_smb.pl v1.10. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=781227&group_id=29880 From noreply at sourceforge.net Mon Sep 15 07:59:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 07:59:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-799098 ] mod for check_nt to fail if wrong client version Message-ID: Patches item #799098, was opened at 2003-09-02 13:10 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=799098&group_id=29880 Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Steve Hanselman (stevehan) >Assigned to: Ton Voon (tonvoon) Summary: mod for check_nt to fail if wrong client version Initial Comment: This patch amends check_nt to (optionally) support the -l parameter for the client version check, if the client is not running the version given as the parameter then it will enter a warning state. Makes for easier rollout of upgraded clients. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 15:58 Message: Logged In: YES user_id=664364 Steve, Thanks for the patch. Applied to CVS HEAD, check_nt v1.19. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=799098&group_id=29880 From noreply at sourceforge.net Mon Sep 15 08:30:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 08:30:03 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-768445 ] Add Exim support to check_mailq.pl Message-ID: Patches item #768445, was opened at 2003-07-09 14:16 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=768445&group_id=29880 Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Eric Bollengier (ricozz) >Assigned to: Ton Voon (tonvoon) Summary: Add Exim support to check_mailq.pl Initial Comment: Add Exim support to check_mailq.pl ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 16:29 Message: Logged In: YES user_id=664364 Eric, Thanks for the patch. Applied to CVS HEAD for check_mailq.pl, v1.4. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=768445&group_id=29880 From noreply at sourceforge.net Mon Sep 15 08:49:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 08:49:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-740404 ] 1.3.0 performance addon for disk/http/load/ping/procs/swap/u Message-ID: Patches item #740404, was opened at 2003-05-20 13:14 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=740404&group_id=29880 Category: Perf data Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) >Assigned to: Ton Voon (tonvoon) Summary: 1.3.0 performance addon for disk/http/load/ping/procs/swap/u Initial Comment: These contain the new performance patches for 1.3.0. This way the plugins will return the extra performance data that is neccesary to make nice graphs with rrd for example. (contact me for the addons for this) developers: please implement this, as i'm seeing people using the most wicked ways to get performance data now. (e.g. parsing the default plugin output!) ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 16:48 Message: Logged In: YES user_id=664364 Edwin, Thank you for this patch. However, we have changed the format of performance data (see http://nagiosplug.sourceforge.net/developer-guidelines.html) and CVS HEAD has perf data for most of the plugins you have patched here. I will close this call as the patches you have provided cannot be used. If you have new patches in the new format for plugins that have not been done in CVS HEAD, those would be most welcome. Thanks again, Ton ---------------------------------------------------------------------- Comment By: Edwin Eefting (drpsycho) Date: 2003-05-20 19:04 Message: Logged In: YES user_id=400439 please use the latest patch, the first one was wrong. (can't delete it :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=740404&group_id=29880 From noreply at sourceforge.net Mon Sep 15 08:53:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 08:53:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-806445 ] check_nwstat.c segfault fix and enhancement Message-ID: Patches item #806445, was opened at 2003-09-15 11:51 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Howat (xargle) >Assigned to: Jeremy T. Bouse (undrgrid) Summary: check_nwstat.c segfault fix and enhancement Initial Comment: Fixes segfault in check_nwstat and adds PCBUFF percentage of original cache buffers monitoring. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-15 16:52 Message: Logged In: YES user_id=664364 Tony, This patch sounds interesting, but there is no attachment. Can you provide a unified or context diff against CVS HEAD for speedy inclusion. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 From noreply at sourceforge.net Mon Sep 15 08:59:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 08:59:11 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-806445 ] check_nwstat.c segfault fix and enhancement Message-ID: Patches item #806445, was opened at 2003-09-15 11:51 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Howat (xargle) >Assigned to: Ton Voon (tonvoon) Summary: check_nwstat.c segfault fix and enhancement Initial Comment: Fixes segfault in check_nwstat and adds PCBUFF percentage of original cache buffers monitoring. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-09-15 16:52 Message: Logged In: YES user_id=664364 Tony, This patch sounds interesting, but there is no attachment. Can you provide a unified or context diff against CVS HEAD for speedy inclusion. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 From sghosh at sghosh.org Mon Sep 15 21:39:02 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Sep 15 21:39:02 2003 Subject: [Nagiosplug-devel] Changes to the check_apc_ups.pl script in contrib In-Reply-To: <3F604F0D.18257.3AD6BED@localhost> Message-ID: Please add it to SourceForge as well. Thanks -sg On Thu, 11 Sep 2003, Aaron Moore wrote: > I've attached a diff file of changes I've made to the > check_apc_ups.pl plugin. > > Improvements include using Net::SNMP instead of using the external > snmpget program. And correcting the output of the plugin so that > nagios will display all of the information that it returns. > > -- > Aaron Moore > Systems Support Specialist > Information Systems > DeKalb Memorial Hospital > (260) 920-2808 > > -- From noreply at sourceforge.net Tue Sep 16 02:41:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 02:41:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-806445 ] check_nwstat.c segfault fix and enhancement Message-ID: Patches item #806445, was opened at 2003-09-15 10:51 Message generated for change (Comment added) made by xargle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Howat (xargle) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat.c segfault fix and enhancement Initial Comment: Fixes segfault in check_nwstat and adds PCBUFF percentage of original cache buffers monitoring. ---------------------------------------------------------------------- >Comment By: Tony Howat (xargle) Date: 2003-09-16 09:40 Message: Logged In: YES user_id=866773 Oops. Just checked out the cvs version, and it has the same functionality as my mods. I was working from the last release version. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-09-15 15:52 Message: Logged In: YES user_id=664364 Tony, This patch sounds interesting, but there is no attachment. Can you provide a unified or context diff against CVS HEAD for speedy inclusion. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 From noreply at sourceforge.net Tue Sep 16 03:55:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 03:55:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-807052 ] check_informix Message-ID: New Plugins item #807052, was opened at 2003-09-16 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=807052&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tielman de Villiers (tvilliers) Assigned to: Nobody/Anonymous (nobody) Summary: check_informix Initial Comment: A perl plugin for Informix, using the DBI, and reporting the number of tables, number of rows, and size (rows * rowsize) from systables ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=807052&group_id=29880 From noreply at sourceforge.net Tue Sep 16 03:56:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 03:56:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-806445 ] check_nwstat.c segfault fix and enhancement Message-ID: Patches item #806445, was opened at 2003-09-15 11:51 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 Category: Bugfix Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Tony Howat (xargle) Assigned to: Ton Voon (tonvoon) Summary: check_nwstat.c segfault fix and enhancement Initial Comment: Fixes segfault in check_nwstat and adds PCBUFF percentage of original cache buffers monitoring. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-09-16 11:55 Message: Logged In: YES user_id=664364 Tony, Thanks for checking that out. I'll close this call. Ton ---------------------------------------------------------------------- Comment By: Tony Howat (xargle) Date: 2003-09-16 10:40 Message: Logged In: YES user_id=866773 Oops. Just checked out the cvs version, and it has the same functionality as my mods. I was working from the last release version. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-09-15 16:52 Message: Logged In: YES user_id=664364 Tony, This patch sounds interesting, but there is no attachment. Can you provide a unified or context diff against CVS HEAD for speedy inclusion. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=806445&group_id=29880 From tvilliers at lastminute.com Tue Sep 16 05:57:02 2003 From: tvilliers at lastminute.com (Tielman de Villiers) Date: Tue Sep 16 05:57:02 2003 Subject: [Nagiosplug-devel] check_informix.pl Message-ID: <1063716820.15773.2.camel@lmn10631.lastminute.com> Hi, I have uploaded a Perl plugin to check Informix -- requires the Perl DBI, and outputs the number of tables, no of rows and db size (rownum * rowsize) from systables. Warning and critical monitors the db size. -- Tielman de Villiers Perl Developer: Post Sales lastminute.com Address: 4 Buckingham Gate, London SW1E 6JP Tel: +44(0)20.7802.4393 Fax: +44(0)20.7802.9302 email: tvilliers at lastminute.com From noreply at sourceforge.net Tue Sep 16 06:40:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 06:40:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-807122 ] check_apc_ups.pl patch Message-ID: Patches item #807122, was opened at 2003-09-16 08:39 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=807122&group_id=29880 Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aaron Kent Moore (mooreak) Assigned to: Nobody/Anonymous (nobody) Summary: check_apc_ups.pl patch Initial Comment: Improvements include using Net::SNMP instead of using the external snmpget program. And correcting the output of the plugin so that nagios will display all of the information that it returns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=807122&group_id=29880 From roy at karlsbakk.net Wed Sep 17 04:02:13 2003 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Wed Sep 17 04:02:13 2003 Subject: [Nagiosplug-devel] Re: [Nagios-users] NSClient In-Reply-To: <20030905145739.GK28216@marvin> References: <20030905145739.GK28216@marvin> Message-ID: <1063796403.10794.33.camel@roy-sin> > I have NSClient running on larger machines, but if it has much > RAM, then begins to use it up ... hundreds of Megs of RAM. > > Did a bugreport, though the developers are quite busy in the last > time: > > http://support.tsmgsoftware.com/viewtopic.php?t=23 We have the same problem on our servers. There must be a memory leak somewhere in nsclient. I'm monitoring memory usage in windows, and every now and then, I need to logon to these and restart the nsclient service to regain lost memory. Any chance of getting this fixed? roy From Ton.Voon at egg.com Wed Sep 17 05:01:15 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Wed Sep 17 05:01:15 2003 Subject: [Nagiosplug-devel] AIX support Message-ID: I've been working on the plugins so that check_procs and check_swap work in AIX (tested on AIX 5.1). However, I'm hitting an autoconf problem which is really annoying me now. I get an ERROR: Undefined symbol: .xmalloc when I try and compile check_disk. It seems that in the original coreutils, it uses some autoconf routines to replace xmalloc, which I can get working, but these replacement routines are asking for rpl_malloc which is provided by malloc.c, but I can't get it to conditionally compile. Does anyone have an idea on how to add this in? Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From noreply at sourceforge.net Wed Sep 17 18:13:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 18:13:03 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-808276 ] check_oracle --login fails Message-ID: Bugs item #808276, was opened at 2003-09-17 17:12 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=808276&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Martin (jhmartin) Assigned to: Nobody/Anonymous (nobody) Summary: check_oracle --login fails Initial Comment: When the check_oracle plugin attempts the --login process (a dummy login), it redirects Bugs item #808276, was opened at 2003-09-17 17:12 Message generated for change (Comment added) made by jhmartin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Martin (jhmartin) Assigned to: Nobody/Anonymous (nobody) Summary: check_oracle --login fails Initial Comment: When the check_oracle plugin attempts the --login process (a dummy login), it redirects Comment By: Jason Martin (jhmartin) Date: 2003-09-17 17:14 Message: Logged In: YES user_id=589094 Actually, instead of parsing the output of sqlplus it should check the returncode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 From noreply at sourceforge.net Thu Sep 18 01:28:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 01:28:19 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-808369 ] Removed the slashes from check_nt disk name fixes email Message-ID: Patches item #808369, was opened at 2003-09-18 07:44 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=808369&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Hanselman (stevehan) Assigned to: Nobody/Anonymous (nobody) Summary: Removed the slashes from check_nt disk name fixes email Initial Comment: Hi, (This is a fudge, not a fix as the real issue is in loading the symbol that is expanded for the email...) In check_nt.c if you remove the quoted slash after the disk name then you receive the full text of the disk status in the email/pager responses. The correct fix is to quote the slash in the symbol, but I haven't bothered to look for where that is done! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=808369&group_id=29880 From Ton.Voon at egg.com Thu Sep 18 01:28:30 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Thu Sep 18 01:28:30 2003 Subject: [Nagiosplug-devel] AIX support Message-ID: Sorry to post a reply to my own email, but I've finally got it working. Turns out we weren't using lib/Makefile.am quite how I was expecting it to be used. All standard plugins now compile on AIX (5.1) in CVS. Ton > -----Original Message----- > From: Voon, Ton [mailto:Ton.Voon at egg.com] > Sent: Wednesday, September 17, 2003 1:00 PM > To: NagiosPlug Devel > Subject: [Nagiosplug-devel] AIX support > > > I've been working on the plugins so that check_procs and > check_swap work in > AIX (tested on AIX 5.1). However, I'm hitting an autoconf > problem which is > really annoying me now. > > I get an ERROR: Undefined symbol: .xmalloc > > when I try and compile check_disk. It seems that in the > original coreutils, > it uses some autoconf routines to replace xmalloc, which I > can get working, > but these replacement routines are asking for rpl_malloc > which is provided > by malloc.c, but I can't get it to conditionally compile. > > Does anyone have an idea on how to add this in? > > Ton > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 > Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > 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 noreply at sourceforge.net Thu Sep 18 01:35:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 01:35:00 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-808276 ] check_oracle --login fails Message-ID: Bugs item #808276, was opened at 2003-09-18 02:12 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Martin (jhmartin) >Assigned to: Ton Voon (tonvoon) Summary: check_oracle --login fails Initial Comment: When the check_oracle plugin attempts the --login process (a dummy login), it redirects Comment By: Ton Voon (tonvoon) Date: 2003-09-18 09:19 Message: Logged In: YES user_id=664364 Jason, I'm not sure what you are trying to do. The idea with the -- login is to do a dummy login to sqlplus. The plugin is expecting sqlplus to return "ORA-01017: invalid username/password". This means that the plugin has managed to communicate with the database and the database (rightly) rejects the login. If the database was not running, then a different error would appear and then the plugin would return with a critical error. The < /dev/null is required otherwise if you run check_oracle on the command line sqlplus will wait for a response. Does this answer your query? Ton ---------------------------------------------------------------------- Comment By: Jason Martin (jhmartin) Date: 2003-09-18 02:14 Message: Logged In: YES user_id=589094 Actually, instead of parsing the output of sqlplus it should check the returncode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 From noreply at sourceforge.net Thu Sep 18 05:23:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 05:23:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-808369 ] Removing the slashes from check_nt disk name fixes email Message-ID: Patches item #808369, was opened at 2003-09-18 07:44 Message generated for change (Settings changed) made by stevehan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=808369&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Hanselman (stevehan) Assigned to: Nobody/Anonymous (nobody) >Summary: Removing the slashes from check_nt disk name fixes email Initial Comment: Hi, (This is a fudge, not a fix as the real issue is in loading the symbol that is expanded for the email...) In check_nt.c if you remove the quoted slash after the disk name then you receive the full text of the disk status in the email/pager responses. The correct fix is to quote the slash in the symbol, but I haven't bothered to look for where that is done! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=808369&group_id=29880 From noreply at sourceforge.net Thu Sep 18 10:38:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 10:38:03 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-808276 ] check_oracle --login fails Message-ID: Bugs item #808276, was opened at 2003-09-17 17:12 Message generated for change (Comment added) made by jhmartin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Martin (jhmartin) Assigned to: Ton Voon (tonvoon) Summary: check_oracle --login fails Initial Comment: When the check_oracle plugin attempts the --login process (a dummy login), it redirects Comment By: Jason Martin (jhmartin) Date: 2003-09-18 09:37 Message: Logged In: YES user_id=589094 Well, the problem is that I just finished installing 9.2.0, and I ran the --login check, and it said it was ok. Since I hadn't created a dummy login yet, I tried the same login via sqlplus and failed to log in. Then I tried it with Bugs item #808276, was opened at 2003-09-17 17:12 Message generated for change (Comment added) made by jhmartin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808276&group_id=29880 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jason Martin (jhmartin) Assigned to: Ton Voon (tonvoon) Summary: check_oracle --login fails Initial Comment: When the check_oracle plugin attempts the --login process (a dummy login), it redirects Comment By: Jason Martin (jhmartin) Date: 2003-09-18 09:39 Message: Logged In: YES user_id=589094 Oh wait, I just reread your commend and understood what you are saying. I was thinking check_oracle expected to login successfully, and return an error code if it couldn't; sorry. ---------------------------------------------------------------------- Comment By: Jason Martin (jhmartin) Date: 2003-09-18 09:37 Message: Logged In: YES user_id=589094 Well, the problem is that I just finished installing 9.2.0, and I ran the --login check, and it said it was ok. Since I hadn't created a dummy login yet, I tried the same login via sqlplus and failed to log in. Then I tried it with New Plugins item #809246, was opened at 2003-09-19 13:23 Message generated for change (Settings changed) made by synked You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=809246&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Awais Ahmad (synked) Assigned to: Nobody/Anonymous (nobody) >Summary: New plugin: HTTP Performance plugin Initial Comment: check_httpperf.pl Checks HTTP and HTTPS throughput, connect time and round trip time and has thresholds for each one. Returns throughput even if it times out if any data was recieved. I wrote it since there was nothing for this purpose in the current plugin distro, hence it should be quite useful to others. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=809246&group_id=29880 From noreply at sourceforge.net Fri Sep 19 16:36:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 19 16:36:56 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-809246 ] HTTP Performance plugin Message-ID: New Plugins item #809246, was opened at 2003-09-19 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=809246&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Awais Ahmad (synked) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP Performance plugin Initial Comment: check_httpperf.pl Checks HTTP and HTTPS throughput, connect time and round trip time and has thresholds for each one. Returns throughput even if it times out if any data was recieved. I wrote it since there was nothing for this purpose in the current plugin distro, hence it should be quite useful to others. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=809246&group_id=29880 From roy at karlsbakk.net Sat Sep 20 08:37:08 2003 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Sat Sep 20 08:37:08 2003 Subject: [Nagiosplug-devel] [BUG] NSClient memory leak... In-Reply-To: <1063796403.10794.33.camel@roy-sin> References: <20030905145739.GK28216@marvin> <1063796403.10794.33.camel@roy-sin> Message-ID: <200309201734.38385.roy@karlsbakk.net> Below is a bug report sent for quite some time ago... Any idea of getting nsclient fixed in the near future? roy On Wednesday 17 September 2003 13:00, Roy Sigurd Karlsbakk wrote: > > I have NSClient running on larger machines, but if it has much > > RAM, then begins to use it up ... hundreds of Megs of RAM. > > > > Did a bugreport, though the developers are quite busy in the last > > time: > > > > http://support.tsmgsoftware.com/viewtopic.php?t=23 > > We have the same problem on our servers. There must be a memory leak > somewhere in nsclient. I'm monitoring memory usage in windows, and every > now and then, I need to logon to these and restart the nsclient service > to regain lost memory. > > Any chance of getting this fixed? > > roy From karl at debisschop.net Sat Sep 20 15:37:05 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Sat Sep 20 15:37:05 2003 Subject: [Nagiosplug-devel] [BUG] NSClient memory leak... In-Reply-To: <200309201734.38385.roy@karlsbakk.net> References: <20030905145739.GK28216@marvin> <1063796403.10794.33.camel@roy-sin> <200309201734.38385.roy@karlsbakk.net> Message-ID: <1064097329.16913.3.camel@miles.debisschop.net> On Sat, 2003-09-20 at 11:34, Roy Sigurd Karlsbakk wrote: > Below is a bug report sent for quite some time ago... > > Any idea of getting nsclient fixed in the near future? > > roy > > On Wednesday 17 September 2003 13:00, Roy Sigurd Karlsbakk wrote: > > > I have NSClient running on larger machines, but if it has much > > > RAM, then begins to use it up ... hundreds of Megs of RAM. > > > > > > Did a bugreport, though the developers are quite busy in the last > > > time: > > > > > > http://support.tsmgsoftware.com/viewtopic.php?t=23 > > > > We have the same problem on our servers. There must be a memory leak > > somewhere in nsclient. I'm monitoring memory usage in windows, and every > > now and then, I need to logon to these and restart the nsclient service > > to regain lost memory. > > > > Any chance of getting this fixed? We don't develop nsclient - we do work on check_nt, but not nsclient. I believe the contact is listed in the code, but it's not nagiosplug-devel. Maybe the bug notice did not get to the right people? -- Karl From noreply at sourceforge.net Mon Sep 22 08:26:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 08:26:19 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-800634 ] rrdtool support in mrtg Message-ID: Feature Requests item #800634, was opened at 2003-09-04 18:34 Message generated for change (Comment added) made by stevehan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=800634&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Steve Hanselman (stevehan) Assigned to: Nobody/Anonymous (nobody) Summary: rrdtool support in mrtg Initial Comment: Has anybody looked at creating a check_mrtg that uses the rrdtool database? ---------------------------------------------------------------------- >Comment By: Steve Hanselman (stevehan) Date: 2003-09-22 15:25 Message: Logged In: YES user_id=521347 Ok, I've written a replacement for the code supplied in the contrib directory, it's attached, but wait, you'll need to patch nagios as you need to switch off semicolon comments in lines as the checking doesn't care whether they are in quotes or not :( Here are a couple of config entris to get you started: define service { use servicetemplate1 host_name linux3 service_description 5 volt rail check_command check_rrd_range!/var/www/html/cacti/rra/linux3_value_45.rrd! 4.7!5.2!4.4!5.5 } define service { use servicetemplate1 host_name linux3 service_description Processor Temperature check_command check_rrd_max!/var/www/html/cacti/rra/linux3_value_48.rrd! 30!35 } # # check_rrd_min, generates errors if the value falls below a level, e.g. free disk space # check_rrd_max, generates errors if the value goes above a level, e.g. swap usage # check_rrd_range, generates errors if the value goes outside a range, e.g. voltage # # check_rrd_min!myfreespace.rrd!100!50 # check_rrd_max!mycpuload.rrd!5!10 # check_rrd_range!myvoltage.rrd!4.8!5.2!4.5!5.5 define command{ command_name check_rrd_max command_line $USER1$/check_rrd.pl - file=$ARG1$ -warning='return(sprintf("Warning Value=% f\n",$$value)) if ($$value>$ARG2$);' -critical='return(sprintf ("Critical Value=%f\n",$$value)) if ($$value > $ARG3$);' - default='printf "OK Value=%f\n", $$value; return 0;' - dataset=0 -cf=MAX } define command{ command_name check_rrd_min command_line $USER1$/check_rrd.pl - file=$ARG1$ -warning='return(sprintf("Warning Value=% f\n",$$value)) if ($$value<$ARG2$);' -critical='return(sprintf ("Critical Value=%f\n",$$value)) if ($$value < $ARG3$);' - default='printf "OK Value=%f\n", $$value; return 0;' - dataset=0 -cf=MIN } define command{ command_name check_rrd_range command_line $USER1$/check_rrd.pl - file=$ARG1$ -warning='return(sprintf("Warning Value % f\n",$$value)) if ($$value<$ARG2$||$$value>$ARG3$ );' - critical='return(sprintf("Critical Value=%f\n",$$value)) if ($$value< $ARG4$ || $$value> $ARG5$ );' -default='printf "OK Value=%f\n", $$value; return 0;' -dataset=0 -cf=MAX } You'll also need to patch the source in two places and remove the checks for ; comments: xdata/xedtemplate.c: /* grab data before comment delimiter - faster than a strtok() and strncpy()... */ xdata/xodtemplate.c: /* grab data before comment delimiter - faster than a strtok() and strncpy()... */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=800634&group_id=29880 From noreply at sourceforge.net Tue Sep 23 01:57:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 23 01:57:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-811049 ] check_snmp_disk_monitor.pl use Net::SNMP Message-ID: New Plugins item #811049, was opened at 2003-09-23 10:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=811049&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pascal TROUVIN (ptrouvin) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp_disk_monitor.pl use Net::SNMP Initial Comment: I updated the contrib/check_snmp_disk_monitor.pl to use the standard Net::SNMP library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=811049&group_id=29880 From noreply at sourceforge.net Tue Sep 23 13:03:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 23 13:03:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-811360 ] New Plugin: check_webapp Message-ID: New Plugins item #811360, was opened at 2003-09-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=541465&aid=811360&group_id=29880 Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Roberts (manithree) Assigned to: Nobody/Anonymous (nobody) Summary: New Plugin: check_webapp Initial Comment: This plugin does several things that I couldn't figure out how to do with check_http. It is intended for checking web applications and allow logging in, etc. It uses a text file with URL's, and text to match or not match as described in the beginning of the source. It can hit multiple URL's and save/send cookies. It currently spawns grep and curl. I would like to change it to use re and pyCurl. It's only a pass/fail thing now. No warning, and timeouts are not user-specifiable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=811360&group_id=29880 From nlopez at espri.arizona.edu Fri Sep 26 12:37:05 2003 From: nlopez at espri.arizona.edu (Nicolas Lopez) Date: Fri Sep 26 12:37:05 2003 Subject: [Nagiosplug-devel] Small check_ldap fix Message-ID: <20030926185901.GC25475@nick.int.espri.arizona.edu> Check_ldap currently assumes that it is supposed to bind to the tree with a username and password, even if you don't specify one. This fails in the case of an anonymous(unbound) connection. The ldap_bind_s part needs to be wrapped in an if (ld_binddn), then everything is happy. I'm attaching a patch that does just that. I'm not subscribed to the list so please reply directly to me. Thanks. - Nick Lopez nlopez at espri.arizona.edu From Ton.Voon at egg.com Mon Sep 29 03:46:13 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Mon Sep 29 03:46:13 2003 Subject: [Nagiosplug-devel] Small check_ldap fix Message-ID: Nicolas, This sounds interesting. There doesn't appear to be a patch attached - can you please resend? Ton > -----Original Message----- > From: Nicolas Lopez [mailto:nlopez at espri.arizona.edu] > Sent: Friday, September 26, 2003 7:59 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Small check_ldap fix > > > Check_ldap currently assumes that it is supposed to bind to the tree > with a username and password, even if you don't specify one. > This fails > in the case of an anonymous(unbound) connection. The ldap_bind_s part > needs to be wrapped in an if (ld_binddn), then everything is > happy. I'm > attaching a patch that does just that. > > I'm not subscribed to the list so please reply directly to me. > > Thanks. > > - Nick Lopez > nlopez at espri.arizona.edu > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting > any issue. > ::: Messages without supporting info will risk being sent to /dev/null > This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From roy at karlsbakk.net Mon Sep 29 04:10:03 2003 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Mon Sep 29 04:10:03 2003 Subject: [Nagiosplug-devel] replacing nsclient? Message-ID: <1064833021.6301.25.camel@roy-sin> hi I beleive it's about time to replace nsclient. it's buggy, leaks memory, written in fscking Pascal and the author doesn't answer bug reports. I want to know if there are anyone else out there with similar feelings about the topic. If so - perhaps a new nsclient should be written in perl or some other portable language to allow us to share the code between platforms? roy From Ton.Voon at egg.com Mon Sep 29 08:02:13 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Mon Sep 29 08:02:13 2003 Subject: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin code Message-ID: Hi! Wanted to get some opinions on the latest development of the plugins. I'm starting to use OS specific ifdefs to get system data and I was wondering if this is the right way to go. The latest version of check_swap.c has ifdefs for Solaris and AIX as they have different ways for checking swap. It could have been done via ./configure, but there are too many different possibilities (for instance, need to run different switches for individual partition checks versus a summary of swap). If it was done via ./configure, you'd also need to set flags to say whether to ignore first lines (some have header info, others don't), work out different format responses (some return megabytes, some return free, some return percentage). I think all this is easier done within the code itself. Is this bad? Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From martin at mcflysr.kurgan.ru Mon Sep 29 08:16:46 2003 From: martin at mcflysr.kurgan.ru (martin mcflysr) Date: Mon Sep 29 08:16:46 2003 Subject: [Nagiosplug-devel] Nagios check_icmp plugin Message-ID: <138289299109.20030929182016@mcflysr.kurgan.ru> Hello nagiosplug-devel, On April 2003 i'm ask about new feature for check_ping, like -S src_addr Use the following IP address as the source address in outgoing packets. On hosts with more than one IP address, this option can be used to force the source address to be something other than the IP address of the interface the probe packet is sent on. If the IP address is not one of this machine's interface addresses, an error is returned and nothing is sent. option for original PING utility. May be, i can achieve target by different path? It is necessary for me to send ICMP packages from the server with Nagios from different interfaces. I have looked in nagios-plugins-1.3.1.tar.gz and could not find check_icmp plugin. Development of this plugin is frozen and not conducted? Thank you. -- martin, From karl at debisschop.net Mon Sep 29 22:00:03 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Sep 29 22:00:03 2003 Subject: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin code In-Reply-To: References: Message-ID: <1064897895.2744.56.camel@miles.debisschop.net> On Mon, 2003-09-29 at 10:46, Voon, Ton wrote: > Hi! Wanted to get some opinions on the latest development of the plugins. > > I'm starting to use OS specific ifdefs to get system data and I was > wondering if this is the right way to go. The latest version of check_swap.c > has ifdefs for Solaris and AIX as they have different ways for checking > swap. It could have been done via ./configure, but there are too many > different possibilities (for instance, need to run different switches for > individual partition checks versus a summary of swap). > > If it was done via ./configure, you'd also need to set flags to say whether > to ignore first lines (some have header info, others don't), work out > different format responses (some return megabytes, some return free, some > return percentage). > > I think all this is easier done within the code itself. Is this bad? What I don't like is use of targets like #ifdef _AIX or #ifdef sun -- for instance, SGI IRIX also has a swap command with very similar syntax. Except it is in /sbin instead of /usr/sbin. It's not at all obvious to me why we needs sun-specific code, but not IRIX-specific code (or more to the point, why can't we write generic code that tests whether the swap command accepts the '-s' switch, and forgo the #ifdef sun. To use things like #ifdef sun, unless absolutely needed, would seem to require perfect knowlege of all Uinx-like OS's in use, and perfect knowlege of those extensions that do not yet exist. Often, this is a symptom that there is a basic problem. In fact, we really see this issue in 3 plugins: check_ping, check_procs, and check_swap. >From my point of view, we should be using a C API in POSIX for these functions, rather than trying to parse comannd-line utilities. Certainly we can write a check_icmp, and probably should. If we can identify an apporpriate API for swap and procs, we should do the same for them. If not, I am much more ready to accept OS-specific ifdefs for procs than I am for swap. There are only a handful of swap variants. AFAICT, if there ar n varieties of Unix, there must be n+1 varieties of the ps command. -- Karl -- Karl From Ton.Voon at egg.com Tue Sep 30 00:56:03 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Sep 30 00:56:03 2003 Subject: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin cod e Message-ID: > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Tuesday, September 30, 2003 5:58 AM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: Re: [Nagiosplug-devel] RFC: OS specific ifdefs in > main plugin code > > > On Mon, 2003-09-29 at 10:46, Voon, Ton wrote: > > Hi! Wanted to get some opinions on the latest development > of the plugins. > > > > I'm starting to use OS specific ifdefs to get system data and I was > > wondering if this is the right way to go. The latest > version of check_swap.c > > has ifdefs for Solaris and AIX as they have different ways > for checking > > swap. It could have been done via ./configure, but there > are too many > > different possibilities (for instance, need to run > different switches for > > individual partition checks versus a summary of swap). > > > > If it was done via ./configure, you'd also need to set > flags to say whether > > to ignore first lines (some have header info, others > don't), work out > > different format responses (some return megabytes, some > return free, some > > return percentage). > > > > I think all this is easier done within the code itself. Is this bad? > > What I don't like is use of targets like #ifdef _AIX or #ifdef sun -- > for instance, SGI IRIX also has a swap command with very > similar syntax. > Except it is in /sbin instead of /usr/sbin. It's not at all obvious to > me why we needs sun-specific code, but not IRIX-specific code (or more > to the point, why can't we write generic code that tests whether the > swap command accepts the '-s' switch, and forgo the #ifdef sun. The reason for the sun specific code is that swap -l does not report "allocated but not used" swap, thus giving "wrong" results on free (available) swap. This is only available with swap -s. There was a thread on this about 9 months back. The trouble with IRIX which "also has a swap command with very similar syntax" is that the syntax is similar but not the same. So we would have to have ./configure work in parsing the output differently. But sometimes it is more than just the sscanf order: there is also if there is a header line, if the syntax returns MBs or bytes or percentage, if the results are for free, used or total. I guess these could be abstracted out to a generic function, but then the parameters to this function will probably need to be written very "code-like", so why not use code? > > To use things like #ifdef sun, unless absolutely needed, would seem to > require perfect knowlege of all Uinx-like OS's in use, and perfect > knowlege of those extensions that do not yet exist. > > Often, this is a symptom that there is a basic problem. In fact, we > really see this issue in 3 plugins: check_ping, check_procs, and > check_swap. > > From my point of view, we should be using a C API in POSIX for these > functions, rather than trying to parse comannd-line utilities. I agree, but these are not always readily available hence the hackery. Eventually, I guess nagiosplug is basically a command-line way of getting a common result from all OSes. > > Certainly we can write a check_icmp, and probably should. If we can > identify an apporpriate API for swap and procs, we should do the same > for them. If not, I am much more ready to accept OS-specific > ifdefs for > procs than I am for swap. There are only a handful of swap variants. I only have Solaris, AIX and Darwin knowledge and they all handle swap differently (Darwin doesn't even preallocated swap space - it just dynamically grows). check_procs doesn't have any ifdefs, maybe because the abstration is better/easier. Even so, I've had to add in extra variables to ./configure like number of columns to get round some inconsistencies (AIX's ps does not have an RSS field). > AFAICT, if there ar n varieties of Unix, there must be n+1 > varieties of > the ps command. > If we continue with the ifdef method, in future we could abstract out as we understand the different cases better. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From karl at debisschop.net Tue Sep 30 05:02:04 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Sep 30 05:02:04 2003 Subject: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin cod e In-Reply-To: References: Message-ID: <1064923251.2744.80.camel@miles.debisschop.net> On Tue, 2003-09-30 at 03:54, Voon, Ton wrote: > > What I don't like is use of targets like #ifdef _AIX or #ifdef sun -- > > for instance, SGI IRIX also has a swap command ... > The reason for the sun specific code is that swap -l does not report > "allocated but not used" swap, thus giving "wrong" results on free > (available) swap. This is only available with swap -s. There was a thread on > this about 9 months back. I think this should be in the comments in the code - few if any people will remember why the sun implementation was called out a year from now. Will 'swap -s' work with IRIX? > The trouble with IRIX which "also has a swap command with very similar > syntax" is that the syntax is similar but not the same. So we would have to > have ./configure work in parsing the output differently. But sometimes it is > more than just the sscanf order: there is also if there is a header line, if > the syntax returns MBs or bytes or percentage, if the results are for free, > used or total. I understand this, and I accept that it is a reason for needing to make the sort of #ifdef that you have done. (Note that above, I said I don't like this style, I was careful not to say this style should not be used -- sometimes it must be. But there are drawbacks, and I think we should be careful using it) > I guess these could be abstracted out to a generic function, but then the > parameters to this function will probably need to be written very > "code-like", so why not use code? I agree - to move the #ifdef to some abstratcted function is window dressing if you still use the same OS-based distinction. FWIW, personally, I'm on the fence on this particilar implementation. I'd like to see fewer OS-specific ifdefs, but I trust that you've looked into it and it's not worth doing in this case. > I agree, but these are not always readily available hence the hackery. > Eventually, I guess nagiosplug is basically a command-line way of getting a > common result from all OSes. True. But experience has shown that grepping a command-line utility from the OS is about the worst way to go about doing that. > > > > Certainly we can write a check_icmp, and probably should. If we can > > identify an apporpriate API for swap and procs, we should do the same > > for them. If not, I am much more ready to accept OS-specific > > ifdefs for > > procs than I am for swap. There are only a handful of swap variants. > > I only have Solaris, AIX and Darwin knowledge and they all handle swap > differently (Darwin doesn't even preallocated swap space - it just > dynamically grows). I have access to Solaris, FreeBSD, SGI (and Linux) - maybe if we add that in, we can at least document what the variations are. > check_procs doesn't have any ifdefs, maybe because the abstration is > better/easier. Even so, I've had to add in extra variables to ./configure > like number of columns to get round some inconsistencies (AIX's ps does not > have an RSS field). If it is easier, it's not by much. The test block is cryptic, order dependent, and essentially impossible to systematically debug. > > AFAICT, if there ar n varieties of Unix, there must be n+1 > > varieties of the ps command. > > If we continue with the ifdef method, in future we could abstract out as we > understand the different cases better. Yes. Again, if you feel we should go this route at present, I respect that. My opinion on the policy we should take is that we should use OS-specific ifdefs as little as practically possible, implementation choices should be left to the implementor. I do think better in-line comments about what led you to this approach would be worthwhile (if you do that, I noticed not all of your indents are consistent with the surrounding #ifdef indentation). I also like the idea that we may be able to go back and remove some OS-specific #ifdefs in favor of generic code. But I don't want to slow down release-realted work with the effort to move to the generic form. -- Karl From Ton.Voon at egg.com Tue Sep 30 07:00:07 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Sep 30 07:00:07 2003 Subject: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin cod e Message-ID: > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Tuesday, September 30, 2003 1:01 PM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: RE: [Nagiosplug-devel] RFC: OS specific ifdefs in > main plugin cod e > > > On Tue, 2003-09-30 at 03:54, Voon, Ton wrote: > > > > What I don't like is use of targets like #ifdef _AIX or > #ifdef sun -- > > > for instance, SGI IRIX also has a swap command ... > > > The reason for the sun specific code is that swap -l does not report > > "allocated but not used" swap, thus giving "wrong" results on free > > (available) swap. This is only available with swap -s. > There was a thread on > > this about 9 months back. > > I think this should be in the comments in the code - few if any people > will remember why the sun implementation was called out a > year from now. Fair point - have added comments to code and also fixed a logic problem which would have caused a problem on IRIX. > > Will 'swap -s' work with IRIX? > > > The trouble with IRIX which "also has a swap command with > very similar > > syntax" is that the syntax is similar but not the same. So > we would have to > > have ./configure work in parsing the output differently. > But sometimes it is > > more than just the sscanf order: there is also if there is > a header line, if > > the syntax returns MBs or bytes or percentage, if the > results are for free, > > used or total. > > I understand this, and I accept that it is a reason for > needing to make > the sort of #ifdef that you have done. (Note that above, I > said I don't > like this style, I was careful not to say this style should > not be used > -- sometimes it must be. But there are drawbacks, and I think > we should > be careful using it) > > > I guess these could be abstracted out to a generic > function, but then the > > parameters to this function will probably need to be written very > > "code-like", so why not use code? > > I agree - to move the #ifdef to some abstratcted function is window > dressing if you still use the same OS-based distinction. > > FWIW, personally, I'm on the fence on this particilar implementation. > I'd like to see fewer OS-specific ifdefs, but I trust that > you've looked > into it and it's not worth doing in this case. > > > I agree, but these are not always readily available hence > the hackery. > > Eventually, I guess nagiosplug is basically a command-line > way of getting a > > common result from all OSes. > > True. But experience has shown that grepping a command-line > utility from > the OS is about the worst way to go about doing that. > > > > > > > Certainly we can write a check_icmp, and probably should. > If we can > > > identify an apporpriate API for swap and procs, we should > do the same > > > for them. If not, I am much more ready to accept OS-specific > > > ifdefs for > > > procs than I am for swap. There are only a handful of > swap variants. > > > > I only have Solaris, AIX and Darwin knowledge and they all > handle swap > > differently (Darwin doesn't even preallocated swap space - it just > > dynamically grows). > > I have access to Solaris, FreeBSD, SGI (and Linux) - maybe if we add > that in, we can at least document what the variations are. > > > check_procs doesn't have any ifdefs, maybe because the abstration is > > better/easier. Even so, I've had to add in extra variables > to ./configure > > like number of columns to get round some inconsistencies > (AIX's ps does not > > have an RSS field). > > If it is easier, it's not by much. The test block is cryptic, order > dependent, and essentially impossible to systematically debug. Agreed. I find it horrible. > > > > AFAICT, if there ar n varieties of Unix, there must be n+1 > > > varieties of the ps command. > > > > If we continue with the ifdef method, in future we could > abstract out as we > > understand the different cases better. > > Yes. > > Again, if you feel we should go this route at present, I respect that. > My opinion on the policy we should take is that we should use > OS-specific ifdefs as little as practically possible, implementation > choices should be left to the implementor. > > I do think better in-line comments about what led you to this approach > would be worthwhile (if you do that, I noticed not all of your indents > are consistent with the surrounding #ifdef indentation). Fair point - have indented the ifdefs better too. > > I also like the idea that we may be able to go back and remove some > OS-specific #ifdefs in favor of generic code. But I don't want to slow > down release-realted work with the effort to move to the > generic form. I think overall the plugins are getting much better. Thanks for your comments. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From awais at eurobell.net Tue Sep 30 08:22:03 2003 From: awais at eurobell.net (Awais Ahmad) Date: Tue Sep 30 08:22:03 2003 Subject: [Nagiosplug-devel] check_dns.c Message-ID: <0165EC14EDB3D511970D00805FEF801449FF27@maggie.noc.eurobell.net> Hi, Does anyone see any utility in rewriting check_dns.c to use gethostbyname(), instead of nslookup?. Also, is just just querying for an A record really enough functionality for a plugin which checks name servers? Cheers Awais -----Original Message----- From: Voon, Ton [mailto:Ton.Voon at egg.com] Sent: Tuesday, September 30, 2003 8:55 AM To: 'Karl DeBisschop' Cc: NagiosPlug Devel Subject: RE: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin cod e > -----Original Message----- > From: Karl DeBisschop [mailto:karl at debisschop.net] > Sent: Tuesday, September 30, 2003 5:58 AM > To: Ton Voon > Cc: NagiosPlug Devel > Subject: Re: [Nagiosplug-devel] RFC: OS specific ifdefs in > main plugin code > > > On Mon, 2003-09-29 at 10:46, Voon, Ton wrote: > > Hi! Wanted to get some opinions on the latest development > of the plugins. > > > > I'm starting to use OS specific ifdefs to get system data and I was > > wondering if this is the right way to go. The latest > version of check_swap.c > > has ifdefs for Solaris and AIX as they have different ways > for checking > > swap. It could have been done via ./configure, but there > are too many > > different possibilities (for instance, need to run > different switches for > > individual partition checks versus a summary of swap). > > > > If it was done via ./configure, you'd also need to set > flags to say whether > > to ignore first lines (some have header info, others > don't), work out > > different format responses (some return megabytes, some > return free, some > > return percentage). > > > > I think all this is easier done within the code itself. Is this bad? > > What I don't like is use of targets like #ifdef _AIX or #ifdef sun -- > for instance, SGI IRIX also has a swap command with very > similar syntax. > Except it is in /sbin instead of /usr/sbin. It's not at all obvious to > me why we needs sun-specific code, but not IRIX-specific code (or more > to the point, why can't we write generic code that tests whether the > swap command accepts the '-s' switch, and forgo the #ifdef sun. The reason for the sun specific code is that swap -l does not report "allocated but not used" swap, thus giving "wrong" results on free (available) swap. This is only available with swap -s. There was a thread on this about 9 months back. The trouble with IRIX which "also has a swap command with very similar syntax" is that the syntax is similar but not the same. So we would have to have ./configure work in parsing the output differently. But sometimes it is more than just the sscanf order: there is also if there is a header line, if the syntax returns MBs or bytes or percentage, if the results are for free, used or total. I guess these could be abstracted out to a generic function, but then the parameters to this function will probably need to be written very "code-like", so why not use code? > > To use things like #ifdef sun, unless absolutely needed, would seem to > require perfect knowlege of all Uinx-like OS's in use, and perfect > knowlege of those extensions that do not yet exist. > > Often, this is a symptom that there is a basic problem. In fact, we > really see this issue in 3 plugins: check_ping, check_procs, and > check_swap. > > From my point of view, we should be using a C API in POSIX for these > functions, rather than trying to parse comannd-line utilities. I agree, but these are not always readily available hence the hackery. Eventually, I guess nagiosplug is basically a command-line way of getting a common result from all OSes. > > Certainly we can write a check_icmp, and probably should. If we can > identify an apporpriate API for swap and procs, we should do the same > for them. If not, I am much more ready to accept OS-specific > ifdefs for > procs than I am for swap. There are only a handful of swap variants. I only have Solaris, AIX and Darwin knowledge and they all handle swap differently (Darwin doesn't even preallocated swap space - it just dynamically grows). check_procs doesn't have any ifdefs, maybe because the abstration is better/easier. Even so, I've had to add in extra variables to ./configure like number of columns to get round some inconsistencies (AIX's ps does not have an RSS field). > AFAICT, if there ar n varieties of Unix, there must be n+1 > varieties of > the ps command. > If we continue with the ifdef method, in future we could abstract out as we understand the different cases better. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net 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 matt.pounsett at cira.ca Tue Sep 30 08:27:08 2003 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Tue Sep 30 08:27:08 2003 Subject: [Nagiosplug-devel] check_dns.c In-Reply-To: <0165EC14EDB3D511970D00805FEF801449FF27@maggie.noc.eurobell.net> Message-ID: On Tue, 30 Sep 2003, Awais Ahmad wrote: > > Hi, > > Does anyone see any utility in rewriting check_dns.c to use gethostbyname(), > instead of nslookup?. > Also, is just just querying for an A record really enough functionality for > a plugin which checks name servers? I was thinking about this myself the other day... check_dns isn't really useful for me, since most of my nameservers are non-recursive, and only hand out NS records (the .ca roots). I have a custom plugin written in perl using Net::DNS which is really only useful to me.. it checks serial numbers to make sure regular updates are happening when expected .. but the Net::DNS module is easily powerful enough to write a replacement for check_dns. -- Matt Pounsett CIRA - Canadian Internet Registration Authority Technical Support Programmer 350 Sparks Street, Suite 1110 matt.pounsett at cira.ca Ottawa, Ontario, Canada 613.237.5335 ext. 231 http://www.cira.ca From Ton.Voon at egg.com Tue Sep 30 08:42:03 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Sep 30 08:42:03 2003 Subject: [Nagiosplug-devel] check_dns.c Message-ID: > -----Original Message----- > From: Awais Ahmad [mailto:awais at eurobell.net] > Sent: Tuesday, September 30, 2003 4:19 PM > To: NagiosPlug Devel > Subject: [Nagiosplug-devel] check_dns.c > > > > Hi, > > Does anyone see any utility in rewriting check_dns.c to use > gethostbyname(), > instead of nslookup?. Yes, we just haven't got round to it. If you want to give it a shot, you're more than welcome. Please use CVS HEAD as there are lots of changes from the last release. > Also, is just just querying for an A record really enough > functionality for > a plugin which checks name servers? The service from a nameserver is do resolve a name, so that's what the plugin does. What were you thinking of? Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From slurndal at verisign.com Tue Sep 30 08:44:05 2003 From: slurndal at verisign.com (s lurndal) Date: Tue Sep 30 08:44:05 2003 Subject: [Nagiosplug-devel] check_dns.c In-Reply-To: from "Awais Ahmad" at Sep 30, 2003 04:18:44 PM Message-ID: <200309301543.IAA13523@slurndal-lnx.verisign.com> > > > Hi, > > Does anyone see any utility in rewriting check_dns.c to use gethostbyname(), > instead of nslookup?. The problem with gethostbyname() is that it will not necessarily check DNS, but rather check the host resolver configured in the /etc/nsswitch.conf[1] file which could be NIS, NIS+, LDAP, DNS or /etc/hosts. scott [1] or the SVR4 network resolver configuration file. > Also, is just just querying for an A record really enough functionality for > a plugin which checks name servers? > > Cheers > > Awais > > -----Original Message----- > From: Voon, Ton [mailto:Ton.Voon at egg.com] > Sent: Tuesday, September 30, 2003 8:55 AM > To: 'Karl DeBisschop' > Cc: NagiosPlug Devel > Subject: RE: [Nagiosplug-devel] RFC: OS specific ifdefs in main plugin > cod e > > > > -----Original Message----- > > From: Karl DeBisschop [mailto:karl at debisschop.net] > > Sent: Tuesday, September 30, 2003 5:58 AM > > To: Ton Voon > > Cc: NagiosPlug Devel > > Subject: Re: [Nagiosplug-devel] RFC: OS specific ifdefs in > > main plugin code > > > > > > On Mon, 2003-09-29 at 10:46, Voon, Ton wrote: > > > Hi! Wanted to get some opinions on the latest development > > of the plugins. > > > > > > I'm starting to use OS specific ifdefs to get system data and I was > > > wondering if this is the right way to go. The latest > > version of check_swap.c > > > has ifdefs for Solaris and AIX as they have different ways > > for checking > > > swap. It could have been done via ./configure, but there > > are too many > > > different possibilities (for instance, need to run > > different switches for > > > individual partition checks versus a summary of swap). > > > > > > If it was done via ./configure, you'd also need to set > > flags to say whether > > > to ignore first lines (some have header info, others > > don't), work out > > > different format responses (some return megabytes, some > > return free, some > > > return percentage). > > > > > > I think all this is easier done within the code itself. Is this bad? > > > > What I don't like is use of targets like #ifdef _AIX or #ifdef sun -- > > for instance, SGI IRIX also has a swap command with very > > similar syntax. > > Except it is in /sbin instead of /usr/sbin. It's not at all obvious to > > me why we needs sun-specific code, but not IRIX-specific code (or more > > to the point, why can't we write generic code that tests whether the > > swap command accepts the '-s' switch, and forgo the #ifdef sun. > > The reason for the sun specific code is that swap -l does not report > "allocated but not used" swap, thus giving "wrong" results on free > (available) swap. This is only available with swap -s. There was a thread on > this about 9 months back. > > The trouble with IRIX which "also has a swap command with very similar > syntax" is that the syntax is similar but not the same. So we would have to > have ./configure work in parsing the output differently. But sometimes it is > more than just the sscanf order: there is also if there is a header line, if > the syntax returns MBs or bytes or percentage, if the results are for free, > used or total. > > I guess these could be abstracted out to a generic function, but then the > parameters to this function will probably need to be written very > "code-like", so why not use code? > > > > > To use things like #ifdef sun, unless absolutely needed, would seem to > > require perfect knowlege of all Uinx-like OS's in use, and perfect > > knowlege of those extensions that do not yet exist. > > > > Often, this is a symptom that there is a basic problem. In fact, we > > really see this issue in 3 plugins: check_ping, check_procs, and > > check_swap. > > > > From my point of view, we should be using a C API in POSIX for these > > functions, rather than trying to parse comannd-line utilities. > > I agree, but these are not always readily available hence the hackery. > Eventually, I guess nagiosplug is basically a command-line way of getting a > common result from all OSes. > > > > > Certainly we can write a check_icmp, and probably should. If we can > > identify an apporpriate API for swap and procs, we should do the same > > for them. If not, I am much more ready to accept OS-specific > > ifdefs for > > procs than I am for swap. There are only a handful of swap variants. > > I only have Solaris, AIX and Darwin knowledge and they all handle swap > differently (Darwin doesn't even preallocated swap space - it just > dynamically grows). > > check_procs doesn't have any ifdefs, maybe because the abstration is > better/easier. Even so, I've had to add in extra variables to ./configure > like number of columns to get round some inconsistencies (AIX's ps does not > have an RSS field). > > > AFAICT, if there ar n varieties of Unix, there must be n+1 > > varieties of > > the ps command. > > > > If we continue with the ifdef method, in future we could abstract out as we > understand the different cases better. > > Ton > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > 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 matt.pounsett at cira.ca Tue Sep 30 08:49:09 2003 From: matt.pounsett at cira.ca (Matt Pounsett) Date: Tue Sep 30 08:49:09 2003 Subject: [Nagiosplug-devel] check_dns.c In-Reply-To: Message-ID: On Tue, 30 Sep 2003, Voon, Ton wrote: > The service from a nameserver is do resolve a name, so that's what the > plugin does. What were you thinking of? But nameservers resolve names to a lot more than just IP addresses. Ideally, the plugin should be able to check any RR, not just A RRs. -- Matt Pounsett CIRA - Canadian Internet Registration Authority Technical Support Programmer 350 Sparks Street, Suite 1110 matt.pounsett at cira.ca Ottawa, Ontario, Canada 613.237.5335 ext. 231 http://www.cira.ca