From seanius at seanius.net Mon Jul 4 10:58:06 2005 From: seanius at seanius.net (sean finney) Date: Mon Jul 4 10:58:06 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? Message-ID: <20050704175618.GA25183@seanius.net> hi all, given that most of the commits in the past couple months have been bugfixes and not feature additions, how do folks feel about making a 1.4.1 release with said bugfixes? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Tue Jul 5 08:45:13 2005 From: tonvoon at mac.com (Ton Voon) Date: Tue Jul 5 08:45:13 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <20050704175618.GA25183@seanius.net> References: <20050704175618.GA25183@seanius.net> Message-ID: <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> On 4 Jul 2005, at 18:56, sean finney wrote: > hi all, > > given that most of the commits in the past couple months have been > bugfixes and not feature additions, how do folks feel about making > a 1.4.1 release with said bugfixes? > > > sean > Yes, this is a good idea. Thanks for all your work, Sean. Can I suggest a release in two weeks, say, Thurs 21st July, to allow any other fixes to be thrown in? I haven't been working on the plugins recently, but I've got a bit of time soon so I'll try some builds. I noticed someone had dropped in a new testing suite which I'd like to commit. Is the CHANGES file up to date? I use that to generate the "press release" that accompanies a new release. Also, I'm looking for some opinions on our versioning strategy. At the moment, there is the CVS HEAD branch and a r1_4 branch. I was thinking that HEAD was always the latest branch, and then we apply bug fixes to r1_4 and HEAD, but this is probably too much overhead. There was an email some time back which suggested that we get smarter with our version numbers. So I'm proposing that for the 1.4.1 release, we make a branch which is r1_4_1 which we only commit absolutely critical bugs into (and thus into HEAD as well) and then release 1.4.1.x based off this. Meanwhile, we continue committing to HEAD, with a release of 1.4.x. At some point in the future, we'll make the latest 1.4.x into 1.5. I think this is the way that GNU coreutils is done. My feeling on feature additions is that they should go into the HEAD branch (with clearly documented "breakage" in the CHANGES file). We just don't have enough resources to handle multiple streams of development. Comments? Ton From noreply at sourceforge.net Tue Jul 5 11:13:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 5 11:13:09 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 15:34 Message generated for change (Comment added) made by sebasguay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- >Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 14:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 22:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From ae at op5.se Tue Jul 5 14:36:37 2005 From: ae at op5.se (Andreas Ericsson) Date: Tue Jul 5 14:36:37 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> Message-ID: <42CAFCC7.60508@op5.se> Ton Voon wrote: > On 4 Jul 2005, at 18:56, sean finney wrote: > >> hi all, >> >> given that most of the commits in the past couple months have been >> bugfixes and not feature additions, how do folks feel about making >> a 1.4.1 release with said bugfixes? >> >> >> sean >> > > Yes, this is a good idea. Thanks for all your work, Sean. > > Can I suggest a release in two weeks, say, Thurs 21st July, to allow > any other fixes to be thrown in? If this is the case and the np_runcmd() framework is to go in, I'd strongly suggest downloading the latest fixes for those from http://oss.op5.se/nagios The package is called "op5plugins.tar.gz" (I'll upload a new one tomorrow or so, with lots of other fixes as well). Apart from np_runcmd() it contains more or less only code cleanups, contrib integration (with necessary improvements) and dropping of obsoleted code. > I haven't been working on the plugins > recently, but I've got a bit of time soon so I'll try some builds. I > noticed someone had dropped in a new testing suite which I'd like to > commit. > I tried to download and grok it, but the file seems to be corrupt. I'm working on a different harness which might be of interest. Given a new config parser module and the np_runcmd framework, paired with the evaluation code I wrote when I was discussing parallell execution with whoever it was made it extremely fast, flexible and easy to the point of being scary to write tests for. It's got a cool name too. I'll spam the plugin-devel list when it's ready. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From seanius at seanius.net Tue Jul 5 16:38:25 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 5 16:38:25 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <42CAFCC7.60508@op5.se> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> Message-ID: <20050705233627.GA10551@seanius.net> On Tue, Jul 05, 2005 at 04:43:37PM +0100, Ton Voon wrote: > Can I suggest a release in two weeks, say, Thurs 21st July, to allow > any other fixes to be thrown in? I haven't been working on the > plugins recently, but I've got a bit of time soon so I'll try some > builds. I noticed someone had dropped in a new testing suite which > I'd like to commit. sounds good to me. > Is the CHANGES file up to date? I use that to generate the "press > release" that accompanies a new release. i was under the impression that CHANGES was generated automatically. otherwise, i certainly haven't made any edits in it... > Also, I'm looking for some opinions on our versioning strategy. At > the moment, there is the CVS HEAD branch and a r1_4 branch. I was > thinking that HEAD was always the latest branch, and then we apply > bug fixes to r1_4 and HEAD, but this is probably too much overhead. > There was an email some time back which suggested that we get smarter > with our version numbers. So I'm proposing that for the 1.4.1 > release, we make a branch which is r1_4_1 which we only commit > absolutely critical bugs into (and thus into HEAD as well) and then > release 1.4.1.x based off this. Meanwhile, we continue committing to > HEAD, with a release of 1.4.x. At some point in the future, we'll > make the latest 1.4.x into 1.5. I think this is the way that GNU > coreutils is done. i'm not sure i understand how doing an r_1_4_1 / HEAD combination would be less overhead than an r_1_4 / HEAD combination. i'd say we should stay with the r_1_4 tree for bugfixes and security updates to the 1.4.x series of the plugins, and commit everything else to HEAD. then, at some point we could branch off an r_1_5 tree, and when that is stable, release that and close off r_1_4 for posterity. On Tue, Jul 05, 2005 at 11:33:59PM +0200, Andreas Ericsson wrote: > If this is the case and the np_runcmd() framework is to go in, I'd > strongly suggest downloading the latest fixes for those from > http://oss.op5.se/nagios i'd vote against including this in a 1.4 series, since we'll be doing some fairly active work with it in the near future. > The package is called "op5plugins.tar.gz" (I'll upload a new one > tomorrow or so, with lots of other fixes as well). i grabbed a tarball shortly before you left for vacation, but haven't had the time to generate a diff against HEAD. if you could do me the favor of doing so, it'd be very helpful. > evaluation code I wrote when I was discussing parallell execution with > whoever it was made it extremely fast, flexible and easy to the point of > being scary to write tests for. It's got a cool name too. I'll spam the > plugin-devel list when it's ready. looking forward to it... sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Tue Jul 5 22:55:27 2005 From: tonvoon at mac.com (Ton Voon) Date: Tue Jul 5 22:55:27 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <20050705233627.GA10551@seanius.net> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> Message-ID: On 6 Jul 2005, at 00:36, sean finney wrote: > On Tue, Jul 05, 2005 at 04:43:37PM +0100, Ton Voon wrote: > >> Is the CHANGES file up to date? I use that to generate the "press >> release" that accompanies a new release. >> > > i was under the impression that CHANGES was generated automatically. > otherwise, i certainly haven't made any edits in it... > The ChangeLog is generated from cvs2cl, but the CHANGES file is manually updated (if you can work out an automatic way, I'm up for it!). The idea is that major enhancements or breakages are put into CHANGES. This is the high level "what's in a new release". The ChangeLog is the detailed changes from comments in CVS. > >> Also, I'm looking for some opinions on our versioning strategy. At >> the moment, there is the CVS HEAD branch and a r1_4 branch. I was >> thinking that HEAD was always the latest branch, and then we apply >> bug fixes to r1_4 and HEAD, but this is probably too much overhead. >> There was an email some time back which suggested that we get smarter >> with our version numbers. So I'm proposing that for the 1.4.1 >> release, we make a branch which is r1_4_1 which we only commit >> absolutely critical bugs into (and thus into HEAD as well) and then >> release 1.4.1.x based off this. Meanwhile, we continue committing to >> HEAD, with a release of 1.4.x. At some point in the future, we'll >> make the latest 1.4.x into 1.5. I think this is the way that GNU >> coreutils is done. >> > > i'm not sure i understand how doing an r_1_4_1 / HEAD combination > would be less overhead than an r_1_4 / HEAD combination. i'd say > we should stay with the r_1_4 tree for bugfixes and security updates > to the 1.4.x series of the plugins, and commit everything else to > HEAD. > then, at some point we could branch off an r_1_5 tree, and when > that is > stable, release that and close off r_1_4 for posterity. > So I think you are saying: - stay with r1_4 and HEAD - bugfixes and security updates to r1_4, all other development to HEAD - create a r1_5 branch from HEAD at some point (so there is r1_4, r1_5 and HEAD) - release r1_5 - close r1_4 at some point I have two issues with this: - all the current bugfixes you have applied would need to be committed into r1_4 from HEAD (I think you've been working on HEAD exclusively). I was trying to save you this effort! - I'm not sure what the difference between the r1_5 branch and HEAD is I have a (maybe oversimplified) equation in my head where "more branches" = "more work", so I'm trying to keep the number of branches to two. Ton From seanius at seanius.net Tue Jul 5 23:28:36 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 5 23:28:36 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> Message-ID: <20050706062726.GA14480@seanius.net> On Wed, Jul 06, 2005 at 06:53:49AM +0100, Ton Voon wrote: > The idea is that major enhancements or breakages are put into > CHANGES. This is the high level "what's in a new release". The > ChangeLog is the detailed changes from comments in CVS. aha... > So I think you are saying: > > - stay with r1_4 and HEAD > - bugfixes and security updates to r1_4, all other development to HEAD > - create a r1_5 branch from HEAD at some point (so there is r1_4, > r1_5 and HEAD) > - release r1_5 > - close r1_4 at some point more like - stay with r1_4 and HEAD - bugfixes and security updates to r1_4, all other development to HEAD - close r1_4 at some point - create a r1_5 branch from HEAD at some point (so there is r1_5 and HEAD) - release r1_5 the idea being that we close up shop and store away 1.4.x for good at some point, that point being shortly before officially starting work on making a new 1.5.x series. > I have a (maybe oversimplified) equation in my head where "more > branches" = "more work", so I'm trying to keep the number of branches > to two. i'd say that's probably a good idea. no reason not to also tag versions to any of the 1.4.x and 1.5.x point releases as well, but i think two actively maintained branches (one stable, one development) is ideal. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Wed Jul 6 00:36:33 2005 From: tonvoon at mac.com (Ton Voon) Date: Wed Jul 6 00:36:33 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <20050706062726.GA14480@seanius.net> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> <20050706062726.GA14480@seanius.net> Message-ID: <10E8A7F7-5363-4DFA-BC88-0AE49CF721D2@mac.com> On 6 Jul 2005, at 07:27, sean finney wrote: > On Wed, Jul 06, 2005 at 06:53:49AM +0100, Ton Voon wrote: > >> So I think you are saying: >> >> - stay with r1_4 and HEAD >> - bugfixes and security updates to r1_4, all other development to >> HEAD >> - create a r1_5 branch from HEAD at some point (so there is r1_4, >> r1_5 and HEAD) >> - release r1_5 >> - close r1_4 at some point >> > > more like > > - stay with r1_4 and HEAD > - bugfixes and security updates to r1_4, all other development to > HEAD > - close r1_4 at some point > - create a r1_5 branch from HEAD at some point (so there is r1_5 > and HEAD) > - release r1_5 > > the idea being that we close up shop and store away 1.4.x for good at > some point, that point being shortly before officially starting > work on > making a new 1.5.x series. > I assume "close r1_4" is just a statement that only major bug/ security fixes will make it into r1_4 and not some CVS thing? At the stage of a r1_5 and HEAD branch, what is the difference? If I have an enhancement that I want in the 1.5 release, does this mean I have to apply to r1_5 and HEAD as well? I only normally use CVS for single branch development, so maybe I am missing something? >> I have a (maybe oversimplified) equation in my head where "more >> branches" = "more work", so I'm trying to keep the number of branches >> to two. >> > > i'd say that's probably a good idea. no reason not to also tag > versions > to any of the 1.4.x and 1.5.x point releases as well, but i think two > actively maintained branches (one stable, one development) is ideal. I agree with one stable and one development branch, which is why I am thinking stable = r1_4 (moving to r1_5 when released) and development = HEAD. Sean, you didn't answer the question re: recent changes to HEAD for the 1.4.1 release. Do we need to patch the r1_4 branch? Sorry if I'm being a bit thick here - I just want to get this straight! This is a good discussion. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Wed Jul 6 05:48:44 2005 From: seanius at seanius.net (sean finney) Date: Wed Jul 6 05:48:44 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <10E8A7F7-5363-4DFA-BC88-0AE49CF721D2@mac.com> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> <20050706062726.GA14480@seanius.net> <10E8A7F7-5363-4DFA-BC88-0AE49CF721D2@mac.com> Message-ID: <20050706124718.GA21063@seanius.net> On Wed, Jul 06, 2005 at 08:35:13AM +0100, Ton Voon wrote: > I assume "close r1_4" is just a statement that only major bug/ > security fixes will make it into r1_4 and not some CVS thing? i actually meant "all development will cease", and that users will be advised to upgrade. of course that doesn't stop of from committing future critical updates if we deem it necessary. my suggestion is that once a 1.5 series is out, it immediately goes into bugfix only mode, and takes the place of 1.4. > At the stage of a r1_5 and HEAD branch, what is the difference? If I > have an enhancement that I want in the 1.5 release, does this mean I > have to apply to r1_5 and HEAD as well? i'd say r1_5 should only be branched off when we're ready for a feature freeze. after that point, bugfixes and security updates only, and everything else goes into HEAD. > Sean, you didn't answer the question re: recent changes to HEAD for > the 1.4.1 release. Do we need to patch the r1_4 branch? yes, for at least all of the changes that i've committed. i'll go back through the cvs log and apply them to r1_4 in the next few days. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Wed Jul 6 14:00:08 2005 From: tonvoon at mac.com (Ton Voon) Date: Wed Jul 6 14:00:08 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <20050706124718.GA21063@seanius.net> References: <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> <20050706062726.GA14480@seanius.net> <10E8A7F7-5363-4DFA-BC88-0AE49CF721D2@mac.com> <20050706124718.GA21063@seanius.net> Message-ID: <8DDFA495-4267-4CA5-981B-CD8E0093D379@mac.com> Sean, On 6 Jul 2005, at 13:47, sean finney wrote: > On Wed, Jul 06, 2005 at 08:35:13AM +0100, Ton Voon wrote: > >> Sean, you didn't answer the question re: recent changes to HEAD for >> the 1.4.1 release. Do we need to patch the r1_4 branch? >> > > yes, for at least all of the changes that i've committed. i'll go > back through the cvs log and apply them to r1_4 in the next few days. You going back through all the fixes you've already done to HEAD is what I am trying to avoid. I think we generally agree. But to make it worse, I've just taken a look and the branch is actually called r1_4-patches. Sigh. My fault for the inconsistency. Can we get agreement on the names? I suggest rx_y_z as the static tag for a release, with bx_y (uncreated yet) as the branch name. So, in two weeks, a r1_4_1 will be created. I suggest ignoring r1_4-patches. HEAD is the only active branch at the moment, with all the 1.4.x stuff now. r1_4_1 will be created from HEAD. That's saved you some work. Let's go a few more months in this state. When we are ready for major changes, we'll create a b1_4 and HEAD becomes the 1.5 development train. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonvoon at mac.com Wed Jul 6 15:04:30 2005 From: tonvoon at mac.com (Ton Voon) Date: Wed Jul 6 15:04:30 2005 Subject: [Nagiosplug-devel] Obsoleted contrib and tarballs files In-Reply-To: <20050628151555.GA7661@seanius.net> References: <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> Message-ID: <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> Guys, Sorry, jumping into this thread a bit late. I think if a contrib plugin has functionality that is available in an official plugin, it can go. I'd like the developer to look into it though, rather than just take the word of someone else. Err on the side of caution and retain. check_timeout should not be in contrib. I'm happy for it to be an official plugin. I really think we should unshackle ourselves from every plugin in the world and setup a CPAN-like area (or promote the use of one). That way support is kept with the plugin originators and they can update them independently from this project. The Nagios Plugins will still be for "core" functionality and showcasing new methods and techniques of interfacing with Nagios. I have had resistance to this idea in the past and I want to reopen the debate because I think this is the only way to go in future. Ton On 28 Jun 2005, at 16:15, sean finney wrote: > hi, > > (quoting with permission a private mail from stanley hopcroft) > > On Tue, Jun 28, 2005 at 02:25:26PM +1000, Stanley Hopcroft wrote: > >> I have a different view of /contrib: that /contrib are candidates for >> inclusion in the supported plugins (those in with the /plugin >> prefix) when >> there is sufficient information to decide that they are popular >> enough or >> conformant enough for one of the plugin developers to say they >> should be. >> >> At present, this is loosely decided based on the number of >> recommendations >> about a contributed plugin (eg try plugins/check_ica or whatever >> it's called >> these days). >> >> The matter of the lower quality of the code is understood by >> inclusion in >> /contrib. The ISC BIND and DHCP projects both distribute /contrib >> code with >> disclaimers about fitness for purpose or support; I thought that >> this was the >> view this project took also. >> >> There is no doubt that there could be code that is less useful in / >> contrib but >> it seems to me that there is >> >> 1 no cost in retaining it >> >> 2 a benefit in demonstrating the projects gratitude for >> contributed code so >> that people will produce plugins for the project. >> > > both are good points. this has to be balanced with a certain > amount of > quality control, but i guess that should really be before the plugins > are accepted into contrib. > > >> Irrespective of whether there _is_ a superior published plugin >> API/Framework/Modus operandi, I don't think it hurts to provide >> examples in >> /contrib of simple, script kiddy code that still serves a useful >> purpose. >> >> Until the project clearly states that Nagios plugins require this >> this and >> this and should adhere to these coding standards, I don't think we >> should >> discard /contrib contributions. >> > > i'm coming around to the same opinion myself for the plugins that > aren't > superceded by 'official' plugins. > > >> To sum up, I don't think this is a debate about the quality of >> contributed >> code, but about the projects relationship with developers and >> about the metrics for >> inclusion in the supported plugins.. >> > > On Tue, Jun 28, 2005 at 09:50:29AM +0200, Andreas Ericsson wrote: > >> I'll set up a different testing release then. Distributing it with >> the >> sane plugins that aren't exclusively for testing doesn't make much >> sense >> if you ask me, as only core testers will be able to make any use >> of it >> at all. >> > > i think just another directory in CVS would be appropriate, > wouldn't it? > perhaps nagiosplug/debug-plugins? > > >> I don't know if you followed the thread from start, but all of the >> nuked >> plugins are obsoleted by official ones which have been extended since >> the contrib ones were contributed. All of them were also notoriously >> > > with the exception of the rbl/ftp plugins... > > >> ugly in code and many of them suffered from lots of hardcoded >> paths and >> variables. Bringing them up to official standards would have taken >> more >> time than anyone can politely be asked to spend, and given their very >> narrow usage I think it's safe to say that noone would ever have >> done it. >> > > i think that for future reference, we should have a higher level > of code quality required before plugins are brought into ./contrib > (which should then be documented), but i'm beginning to side with > ethan > and stanley that existing plugins should be grandfathered (does that > expression work in swedish too?) in until they can be replaced with > something better. > > >> That said, if someone wants to check downloads from an FTP-site, >> I'll be >> happy to write a (much faster, safer and cleaner) version in C. Given >> the simplicity of the FTP protocol it shouldn't take much longer than >> 20-30 minutes. >> > > i'd be happy to see this. if it's complicated by the upcoming changes > wrt the np_runcmd or other api stuff perhaps we can table it in a TODO > until then. > > > sean > From noreply at sourceforge.net Wed Jul 6 15:40:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 6 15:40:21 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1185704 ] New Testing Infrastructure Message-ID: Patches item #1185704, was opened at 2005-04-19 08:31 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Bray (illumino) >Assigned to: Ton Voon (tonvoon) Summary: New Testing Infrastructure Initial Comment: The attched gzip'd tar archive contains a complete replacement for the Nagios Plugins 1.4.0 testing infrastructure and all currently written test harnesses. I hope that it will meet with the approval of the Nagios Plugins Team and replace the existing infrastructure. I have provided documentation of the key functions of the infrastructure in the perl module NPTest.pm and the test harnesses themselves should provide plenty of working examples for further assisting a test harness developer. I hope this infrastructure will ease & encourage the development of test harnesses for all of the Nagios Plugins. Reasoning behind the redevelopment: * I have always had trouble with the existing infrastructure, it never seemed to create the "Cache.pm", and the testing would not function until I had manually created it. * The test harnesses themselves were out of date with respect to the Nagios Plugins 1.4.0 test results. * It was not possible to debug the existing test harness during execution, as the values returned by the execution of the plug-in were never shown to the user. Making updating of out-of-date regexps more time consuming. * Test harnesses themselves were not directly executable. Although I did manage to work around this. Attributes of the new infrastructure: * A single perl module provides the bulk of the logic. The Cache and Helper Modules are no longer required. Aside: I considered rolling all of test.pl into the module, so that could be with "perl -MNPTest -e RunAll ..." but that is not in the current implementation, but its trivial. * The workhorse function "checkCmd" supports * debugging * flexible exit status testing * graceful handling of exceptions * makes each test case more concise and easier to read * All test harnesses are directly executable. * All test harnesses are self contained. They no longer rely on the wrapper to provide test parameters. This could be seen as a negative, but not having to update the wrapper every time a new test parameter is added will simplify development. * The new test parameter cache is much more flexible, including support for default values, environment variable overrides and even scoped parameters should the need arise. I hope these attributes and the corrections to the existing test harnesses will make the contribution a worth while addition to the Nagios Plugins code base. Peter Bray Sydney, Australia LEGAL STUFF: The submission is made "AS IS" with without express or implied warranty. The contribution may be used, redistributed and/or modified under the same terms as the Nagios Plugins release. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-07-06 23:39 Message: Logged In: YES user_id=664364 Peter, Thank you for this. I will look into this over the next few days, in anticipation of including this in the 1.4.1 release in two weeks. Ton ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-06-12 15:35 Message: Logged In: YES user_id=426773 13th June : What (if anything) can I do to have this submission evaluated by the Nagios Plugins Team? ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-04-19 10:11 Message: Logged In: YES user_id=426773 Sorry, but I forgot the test.pl rewrite in the orginal archive submission Peter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 From Stanley.Hopcroft at IPAustralia.Gov.AU Wed Jul 6 15:47:21 2005 From: Stanley.Hopcroft at IPAustralia.Gov.AU (Stanley Hopcroft) Date: Wed Jul 6 15:47:21 2005 Subject: [Nagiosplug-devel] Obsoleted contrib and tarballs files In-Reply-To: <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> References: <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> Message-ID: <20050706224610.GA236@IPAustralia.Gov.AU> Dear Folks, On Wed, Jul 06, 2005 at 11:03:32PM +0100, Ton Voon wrote: > Guys, > I really think we should unshackle ourselves from every plugin in the > world and setup a CPAN-like area (or promote the use of one). That > way support is kept with the plugin originators and they can update > them independently from this project. The Nagios Plugins will still > be for "core" functionality and showcasing new methods and techniques > of interfacing with Nagios. > > I have had resistance to this idea in the past and I want to reopen > the debate because I think this is the only way to go in future. > It was probably from me but I can't think why at the moment. It is an advantageous proposal in that it 1 allows development to concentrate on the official plugins 2 allows the donation of contributed code, without any commitment whatsoever from the project Such a facility may already exist (called 'Nagiosexchange'). OTOH doing so requires in my view 1 deciding what to do with contrib code that is already on the SF contrib tracker 2 managing expectations: at least, updating the plugin developers guidelines. Your comments about CPAN are interesting and seemingly consistent with a view held by Perl developers that CPAN is 1 absolutely indispensable to the future of Perl because of the high quality of __some__ of the modules 2 a dumping ground for other modules of lower quality That said, no one is talking about 'reforming' CPAN. People are known by their good code on CPAN (eg WWW::Mechanize, LWP, PAR, Inline etc etc). The only thing I would like from CPAN is a 'nuke' button to obliterate from all consciousness bad code I put there; Its absence means that I __must__ maintain it. > Ton > > Yours sincerely. -- Stanley Hopcroft -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: disclaimer.txt URL: From seanius at seanius.net Wed Jul 6 20:37:41 2005 From: seanius at seanius.net (sean finney) Date: Wed Jul 6 20:37:41 2005 Subject: [Nagiosplug-devel] RFC: making a 1.4.1 release? In-Reply-To: <8DDFA495-4267-4CA5-981B-CD8E0093D379@mac.com> References: <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <42CAFCC7.60508@op5.se> <20050704175618.GA25183@seanius.net> <31FEC784-1F84-4FB1-8F80-42705A62DB43@mac.com> <20050705233627.GA10551@seanius.net> <20050706062726.GA14480@seanius.net> <10E8A7F7-5363-4DFA-BC88-0AE49CF721D2@mac.com> <20050706124718.GA21063@seanius.net> <8DDFA495-4267-4CA5-981B-CD8E0093D379@mac.com> Message-ID: <20050707033557.GB30487@seanius.net> hey, On Wed, Jul 06, 2005 at 09:58:23PM +0100, Ton Voon wrote: > I suggest ignoring r1_4-patches. HEAD is the only active branch at > the moment, with all the 1.4.x stuff now. r1_4_1 will be created from > HEAD. That's saved you some work. Let's go a few more months in this > state. When we are ready for major changes, we'll create a b1_4 and > HEAD becomes the 1.5 development train. sounds good. i think there's probably a commit or two that should be backed out before branching though, the np_runcmd stuff is what comes to mind first. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Thu Jul 7 15:09:32 2005 From: tonvoon at mac.com (Ton Voon) Date: Thu Jul 7 15:09:32 2005 Subject: [Nagiosplug-devel] Obsoleted contrib and tarballs files In-Reply-To: <20050706224610.GA236@IPAustralia.Gov.AU> References: <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> Message-ID: On 6 Jul 2005, at 23:46, Stanley Hopcroft wrote: > Dear Folks, > > On Wed, Jul 06, 2005 at 11:03:32PM +0100, Ton Voon wrote: > >> Guys, >> I really think we should unshackle ourselves from every plugin in the >> world and setup a CPAN-like area (or promote the use of one). That >> way support is kept with the plugin originators and they can update >> them independently from this project. The Nagios Plugins will still >> be for "core" functionality and showcasing new methods and techniques >> of interfacing with Nagios. >> >> I have had resistance to this idea in the past and I want to reopen >> the debate because I think this is the only way to go in future. >> >> > > It was probably from me but I can't think why at the moment. > > It is an advantageous proposal in that it > > 1 allows development to concentrate on the official plugins > > 2 allows the donation of contributed code, without any commitment > whatsoever > from the project > > Such a facility may already exist (called 'Nagiosexchange'). > > OTOH doing so requires in my view > > 1 deciding what to do with contrib code that is already on the SF > contrib > tracker > > 2 managing expectations: at least, updating the plugin developers > guidelines. If these are the only two issues, then I am up for it. Having had a quick look around http://www.nagiosexchange.org/, it seems to be well thought out. It is supported by a reseller of Nagios, but I don't have a problem with that. Has anyone got any opinion of this site? I guess I am trying to work out what are the requirements for a Plugin CPAN. I guess there are issues of control and trust, but I've overcome my NIH (Not Invented Here) syndrome - if Nagios Exchange is the place to promote, I'm happy to start having discussions with the site owners. Any other opinions? I think this is a big step and I'd like to make sure it is the right direction. Ton From tonvoon at mac.com Thu Jul 7 18:31:40 2005 From: tonvoon at mac.com (Ton Voon) Date: Thu Jul 7 18:31:40 2005 Subject: [Nagiosplug-devel] check_swap in SUN OS In-Reply-To: References: Message-ID: Siva, From memory, the swap -s is around release 1.3 of the plugins. You can find the release on SF somewhere. However, it would be more beneficial to us if you can explain why the current check_swap cannot do what you need, so we can enhance that. We have moved from running swap -s to making the system calls instead. Thank you for pointing out the error in the help file. I have updated it now. Ton On 28 Jun 2005, at 18:57, Nellurandi, Sivakumar wrote: > Thank you so much for the reply. > > Can you please get me the source code which is using swap -s command? > > Regards, > Siva > > -----Original Message----- > From: sean finney [mailto:seanius at seanius.net] > Sent: Saturday, June 25, 2005 4:53 PM > To: Nellurandi, Sivakumar > Cc: kdebisschop at users.sourceforge.net; > nagiosplug-devel at lists.sourceforge.net > Subject: Re: [Nagiosplug-devel] check_swap in SUN OS > > > hi siva, > > On Mon, Jun 20, 2005 at 10:13:57AM -0700, Nellurandi, Sivakumar wrote: > >> I am finding some difficulties for having the check_swap plugin >> worked >> > > >> in SUN Solaris operating system. Can you please provide me the >> working >> > > >> version source code of the check_swap plugin? >> > > sorry for the late reply, i've been afk for the last week or two, > and i > don't think anyone else here seems to have much to say about > check_swap > it seems. > > >> printf (_("\n\ >> On Solaris, if -a specified, uses swap -l, otherwise uses swap -s.\n\ >> Will be discrepencies because swap -s counts allocated swap and >> includes\n\ real memory\n")); >> printf (_("\n\ >> On AIX, if -a is specified, uses lsps -a, otherwise uses lsps >> > -s.\n")); > >> >> The above print statements clearly state that omitting the "-a" >> argument to the plugin uses "swap -s" command on Solaris and "lsps >> -s" >> > > >> command on AIX. >> > > >> But in the code we did not find a similar execution of "swap -s" >> command for Solaris. Could you point out where the execution of "swap >> -s" command takes place. >> > > my guess is that this usage information is outdated, and that swap - > s is > not executed at all, because iirc the solaris check_swap heavily (or > perhaps exclusively) favors usage of the swapctl library routines > instead of executing the cmdline program. > > > sean > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug- > devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/ > nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null > From formy-duval_alan at bah.com Fri Jul 8 13:34:06 2005 From: formy-duval_alan at bah.com (Formy-Duval Alan) Date: Fri Jul 8 13:34:06 2005 Subject: [Nagiosplug-devel] Downloading Nagios Plugin Snapshot Message-ID: <70F40B6058284248BEAB168BF640CC598FCD89@MCLNEXVS03.resource.ds.bah.com> Hello, I am trying to download and compile the latest snapshot in order to resolve a bug found with the libnsl library on Solaris. Which is the correct file to download from http://nagiosplug.sf.net/snapshot? Do I need the 'HEAD' file or the 'r1_4' file? Thanks Alan Formy-Duval, CISSP Booz | Allen | Hamilton (202)508-6827 From noreply at sourceforge.net Fri Jul 8 15:24:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 8 15:24:07 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1234998 ] ldap replication plugin for Sun One Directory Server 5.x Message-ID: New Plugins item #1234998, was opened at 2005-07-08 15: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=1234998&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Lile (lile) Assigned to: Nobody/Anonymous (nobody) Summary: ldap replication plugin for Sun One Directory Server 5.x Initial Comment: We've been using this plug-in and event handler where I work for 2 years, seems like we can't be the only ones who need them. The check script checks the status of replication for a single host replica so it must be configured for each ldap replica and the database that is being replicated. The event-handler script will check all replication agreements on the master server and restart any failed replication agreements. It's a little complicated, but if you are already running Sun One Directory Server 5.x it should be fairly clear. You need a user in the cn=config branch that can read the replication agreements and it must be able to write to the agreements for the event-handler. Here is an example, the user, host and passwords are parameters to the scripts. dn: uid=nagios,cn=config uid: nagios givenName: nagios objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: nagios cn: nagios userPassword: xxxxxxxx And the aci to allow the check and event-handler, remove write for checking only. dn: cn=config aci: (targetattr = "*") (target = "ldap:///cn=config") (targetfilter = objectclass=nsDS5ReplicationAgreement) (version 3.0;acl "Nagios Replication Checks"; allow (read,compare,search,write) (userdn = "ldap:///uid=nagios,cn=config");) Sample nagios configuration: master-ldap is the master ldap host that services the replication agreements, the ldap basedn is dc=domain,dc=somewhere,dc=com and the dns domain is domain.somewhere.com in the following example. checkcommands.cfg - define command{ command_name check_replica command_line $USER1$/check_ds5replica -w 10 -c 15 -H $ARG1$ -b "dc=$ARG2$,dc=somewhere,dc=com" -l uid=nagios,cn=config -a password -r $HOSTNAME$$ARG3$ } define command{ command_name replica_update command_line $USER1$/eventhandlers/replication_update -H master-ldap -l uid=nagios,cn=config -a password $SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$ } services.cfg - define service{ use ldap-replica-service service_description LDAP-Replica hostgroup_name ldap_replica_servers check_command check_replica!master-ldap!domain!.domain.somewhere.com } services-templates.cfg- define service{ name ldap-replica-service use generic-service service_description LDAP-Replica is_volatile 0 check_period 24x7 max_check_attempts 5 normal_check_interval 10 retry_check_interval 2 contact_groups ldap-admins notification_period 24x7 notification_options c,r check_command check_replica event_handler replica_update register 0 } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1234998&group_id=29880 From tonvoon at mac.com Fri Jul 8 20:22:32 2005 From: tonvoon at mac.com (Ton Voon) Date: Fri Jul 8 20:22:32 2005 Subject: [Nagiosplug-devel] Downloading Nagios Plugin Snapshot In-Reply-To: <70F40B6058284248BEAB168BF640CC598FCD89@MCLNEXVS03.resource.ds.bah.com> References: <70F40B6058284248BEAB168BF640CC598FCD89@MCLNEXVS03.resource.ds.bah.com> Message-ID: <27BE6F1E-8F25-4771-921B-BFB3E0712D27@mac.com> Alan, Good question: this tells me the branches are not clear, which is quite relevant to a recent thread. Use HEAD - this is the only active branch at the moment. r1_4-patches will be killed soon. Ton On 8 Jul 2005, at 20:40, Formy-Duval Alan wrote: > Hello, > > I am trying to download and compile the latest snapshot in order to > resolve a bug found with the libnsl library on Solaris. Which is the > correct file to download from http://nagiosplug.sf.net/snapshot? Do I > need the 'HEAD' file or the 'r1_4' file? > > Thanks > > Alan Formy-Duval, CISSP > Booz | Allen | Hamilton > (202)508-6827 > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug- > devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/ > nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null > From noreply at sourceforge.net Sat Jul 9 08:43:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 9 08:43:02 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235245 ] check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Message-ID: Bugs item #1235245, was opened at 2005-07-09 17:42 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=1235245&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Marc Gimpel (mgimpel) Assigned to: Nobody/Anonymous (nobody) Summary: check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Initial Comment: When trying to run check_pgsql on Red Hat Enterprise Linux 4 with the PostgreSQL 8 RPMs from the PostgreSQL website I get the following error: [root at c9 ~]# /usr/lib/nagios/plugins/check_pgsql /usr/lib/nagios/plugins/check_pgsql: error while loading shared libraries: libpq.so.3: cannot open shared object file: No such file or directory The reason is that the PostgreSQL RPMs for Red Hat Enterprise Linux 4 contain the following libraries: /usr/lib/libpq.so.4 /usr/lib/libpq.so.4.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 From noreply at sourceforge.net Mon Jul 11 01:14:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 11 01:14:12 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235879 ] a few bugs in check_nwstat Message-ID: Bugs item #1235879, was opened at 2005-07-11 10: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=1235879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Gerd Mueller (gmueller_2000) Assigned to: Nobody/Anonymous (nobody) Summary: a few bugs in check_nwstat Initial Comment: I wonder if anybody is using check_nwstat. Because this plugin includes so many errors I had to patch it before using it. Attached you will find my changes. /Gerd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235879&group_id=29880 From greenmanse at ldschurch.org Mon Jul 11 11:58:25 2005 From: greenmanse at ldschurch.org (Scott Greenman) Date: Mon Jul 11 11:58:25 2005 Subject: [Nagiosplug-devel] Fix for check_nagios plugin with Nagios 2.03b Message-ID: <20050711181245.D481A4F4002@desire.netways.de> Hi list I just started using nagios2.03b with the latest plugins, and found that the check_nagios plugin wasn't correctly computing the time since last update of the status log. I found several people who had reported this problem on the nagiosplug-help list, but no responses. I tweaked the plugin code and it seems to work correctly now. I don't know how to go about contributing this change to the community, so I'm just posting a diff here and if someone more in the know wants to pick it up, great.... The problem is a difference between the status log file formats between versions of Nagios. I have no idea in what version of Nagios this change occurred. Implimenting this change will fix the plugin for Nagios 2.0b3, but will break it for earlier versions. Ultimately it seems that two different plugins are needed, or one plugin that has a flag to indicate which Nagios verison or can check the Nagios version itself. Here's the diff: *** plugins/check_nagios.c Sat Dec 25 16:17:44 2004 --- ~plugins/check_nagios.c Mon Jul 11 10:20:22 2005 *************** *** 84,96 **** return STATE_CRITICAL; } /* get the date/time of the last item updated in the log */ while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, fp)) { ! temp_ptr = strtok (input_buffer, "]"); ! temp_entry_time = ! (temp_ptr == NULL) ? 0L : strtoul (temp_ptr + 1, NULL, 10); ! if (temp_entry_time > latest_entry_time) ! latest_entry_time = temp_entry_time; } fclose (fp); --- 84,98 ---- return STATE_CRITICAL; } + const char *tag = "created="; + /* get the date/time of the last item updated in the log */ while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, fp)) { ! temp_ptr = strstr (input_buffer, tag); ! if (temp_ptr != NULL) { ! latest_entry_time = strtoul (temp_ptr + strlen(tag), NULL, 10); ! break; ! } } fclose (fp); Cheers... - Scott Greenman (sgreenman) ----------------------- The mailing list archive is found here: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html From noreply at sourceforge.net Mon Jul 11 15:19:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 11 15:19:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235879 ] a few bugs in check_nwstat Message-ID: Bugs item #1235879, was opened at 2005-07-11 09:12 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235879&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerd Mueller (gmueller_2000) >Assigned to: Ton Voon (tonvoon) Summary: a few bugs in check_nwstat Initial Comment: I wonder if anybody is using check_nwstat. Because this plugin includes so many errors I had to patch it before using it. Attached you will find my changes. /Gerd ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-07-11 23:17 Message: Logged In: YES user_id=664364 Gerd, Thanks for the patch. I don't think any of the developers in the team have a Netware service to check against, so some development is "done in the dark". Your patch looks fine and is applied to CVS. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235879&group_id=29880 From seanius at seanius.net Mon Jul 11 16:28:41 2005 From: seanius at seanius.net (sean finney) Date: Mon Jul 11 16:28:41 2005 Subject: [Nagiosplug-devel] Fix for check_nagios plugin with Nagios 2.03b In-Reply-To: <20050711181245.D481A4F4002@desire.netways.de> References: <20050711181245.D481A4F4002@desire.netways.de> Message-ID: <20050711232633.GA27788@seanius.net> hi scott, On Mon, Jul 11, 2005 at 08:12:45PM +0200, Scott Greenman wrote: > I just started using nagios2.03b with the latest plugins, and found > that the check_nagios plugin wasn't correctly computing the time > since last update of the status log. I found several people who > had reported this problem on the nagiosplug-help list, but no responses. > I tweaked the plugin code and it seems to work correctly now. I > don't know how to go about contributing this change to the community, > so I'm just posting a diff here and if someone more in the know > wants to pick it up, great.... the "preferred" way would be if you could open up a ticket in the bug tracker on the sourceforge site. you could include in the report such a patch. > The problem is a difference between the status log file formats > between versions of Nagios. I have no idea in what version of Nagios > this change occurred. Implimenting this change will fix the plugin > for Nagios 2.0b3, but will break it for earlier versions. Ultimately > it seems that two different plugins are needed, or one plugin that > has a flag to indicate which Nagios verison or can check the Nagios > version itself. i think what would be best is a cmdline option to enable the nagios v2 specific format, or perhaps as you suggest an automatic detection. you could probably do the latter by examining the first/last line in the status log and comparing it against what you would expect to see in either version. in any case, unified (-u) diffs are preferred, and any help you could provide would be appreciated. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Mon Jul 11 19:36:20 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Jul 11 19:36:20 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) In-Reply-To: References: <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> Message-ID: <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> On 7 Jul 2005, at 23:08, Ton Voon wrote: > > On 6 Jul 2005, at 23:46, Stanley Hopcroft wrote: > > >> Dear Folks, >> >> On Wed, Jul 06, 2005 at 11:03:32PM +0100, Ton Voon wrote: >> >> >>> Guys, >>> I really think we should unshackle ourselves from every plugin in >>> the >>> world and setup a CPAN-like area (or promote the use of one). That >>> way support is kept with the plugin originators and they can update >>> them independently from this project. The Nagios Plugins will still >>> be for "core" functionality and showcasing new methods and >>> techniques >>> of interfacing with Nagios. >>> >>> I have had resistance to this idea in the past and I want to reopen >>> the debate because I think this is the only way to go in future. >>> >>> >>> >> >> It was probably from me but I can't think why at the moment. >> >> It is an advantageous proposal in that it >> >> 1 allows development to concentrate on the official plugins >> >> 2 allows the donation of contributed code, without any commitment >> whatsoever >> from the project >> >> Such a facility may already exist (called 'Nagiosexchange'). >> >> OTOH doing so requires in my view >> >> 1 deciding what to do with contrib code that is already on the SF >> contrib >> tracker >> >> 2 managing expectations: at least, updating the plugin developers >> guidelines. >> > > If these are the only two issues, then I am up for it. > > Having had a quick look around http://www.nagiosexchange.org/, it > seems to be well thought out. It is supported by a reseller of > Nagios, but I don't have a problem with that. Has anyone got any > opinion of this site? I guess I am trying to work out what are the > requirements for a Plugin CPAN. > > I guess there are issues of control and trust, but I've overcome my > NIH (Not Invented Here) syndrome - if Nagios Exchange is the place > to promote, I'm happy to start having discussions with the site > owners. > > Any other opinions? I think this is a big step and I'd like to make > sure it is the right direction. > No opinions about a Nagios plugins CPAN-like area? I'm interested to hear what people think. Please respond privately if you prefer. I've had a think about this and I think my main requirement is that this CPAN-like area must allow mirroring of their archive. This means that if the main site stops being available, the mirrors will still hold the data. Any other requirements necessary? Ton From seanius at seanius.net Mon Jul 11 20:02:15 2005 From: seanius at seanius.net (sean finney) Date: Mon Jul 11 20:02:15 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) In-Reply-To: <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> References: <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> Message-ID: <20050712025945.GA29754@seanius.net> hi, On Mon, Jul 11, 2005 at 11:10:35PM +0100, Ton Voon wrote: > No opinions about a Nagios plugins CPAN-like area? I'm interested to > hear what people think. Please respond privately if you prefer. i think providing an easier way for people to submit and review plugins is a good idea. i do have some concerns though: my main concern is with qa-related topics. sure, there's the NIH syndrome you mentioned earlier (which i think is relevant), but i'm more worried about the overall lack of control over quality, as well as pollution of our namespace/reputation. i think such concerns could be addressed if we had some way of providing some kind of nagiosplug "status" or "rating", where it was made clear whether or not it was reviewed by a member of the team, whether it was being considered for inclusion, et c. if such a system existed, i think it would make a better bridge for plugins to make their way into the project, and would overall be a good thing. this would also obsolete the need for a "contrib" section. otherwise, i'd be very hesitant for moving in this direction, and am not sure what it would gain us that couldn't be simply done by linking to the nagiosexchange site where a similar collection system for plugins already seems to exist. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tonvoon at mac.com Mon Jul 11 23:28:02 2005 From: tonvoon at mac.com (Ton Voon) Date: Mon Jul 11 23:28:02 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) In-Reply-To: <20050712025945.GA29754@seanius.net> References: <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> Message-ID: On 12 Jul 2005, at 03:59, sean finney wrote: > hi, > > On Mon, Jul 11, 2005 at 11:10:35PM +0100, Ton Voon wrote: > >> No opinions about a Nagios plugins CPAN-like area? I'm interested to >> hear what people think. Please respond privately if you prefer. >> > > i think providing an easier way for people to submit and review > plugins is a good idea. i do have some concerns though: > > my main concern is with qa-related topics. sure, there's the NIH > syndrome you mentioned earlier (which i think is relevant), but i'm > more worried about the overall lack of control over quality, as well > as pollution of our namespace/reputation. Hadn't thought of the namespace situation. CPAN does have control over what namespace perl modules can take, at least at a top level. Not sure how this would work for plugins, which is just a single file name... Any ideas on controlling this? Or is it even a problem? > > i think such concerns could be addressed if we had some way of > providing > some kind of nagiosplug "status" or "rating", where it was made clear > whether or not it was reviewed by a member of the team, whether it was > being considered for inclusion, et c. if such a system existed, i > think > it would make a better bridge for plugins to make their way into the > project, and would overall be a good thing. I like CPAN's rating system. It is not fully used, but it gives a good general feedback on the quality of a perl module from the users. I'll add to my wish list. As for quality, I was thinking that there are varying levels of "certification" for a plugin (this is based on an email thread a long time ago, which I can't recall which). I propose that the dev guide should show level 1 as "returns 0 OK, 1 warn, 2 crit, with one line output", --help/-h with output, --version/-v for version info. Level 2 is perf data. Level 3 is stuff like -v -v -v for extra debug options and internationalization. Level 4 is stuff to do with integration into core (using common libraries, etc). With some work on the new test harness, I think we could probably create a generic test harness which proves which certification level a plugin is at. > this would also obsolete > the need for a "contrib" section. > > otherwise, i'd be very hesitant for moving in this direction, and am > not sure what it would gain us that couldn't be simply done by linking > to the nagiosexchange site where a similar collection system for > plugins > already seems to exist. I'm trying to work out our requirements for the NP collection system. Then I plan on having a discussion with Nagiosexchange, where I'll find out if they can meet all the requirements we have, in return for us officially promoting the use of their site. Seems like a win-win: we'll get what we want, while they gain exposure. It could be that we decide to keep it in house and develop our own collection system, which is valid (for instance, control of namespace could be a major issue). But then I really need commitment that we can do this ourselves! Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.Eble at kaufland.de Tue Jul 12 01:54:36 2005 From: Matthias.Eble at kaufland.de (Matthias.Eble at kaufland.de) Date: Tue Jul 12 01:54:36 2005 Subject: Antwort: Re: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) [Virus checked] In-Reply-To: Message-ID: > On Mon, Jul 11, 2005 at 11:10:35PM +0100, Ton Voon wrote: > Hadn't thought of the namespace situation. CPAN does have control > over what namespace perl modules can take, at least at a top level. > Not sure how this would work for plugins, which is just a single > file name... Any ideas on controlling this? Or is it even a problem? I think it's sth that should be thought about. Recently there was a discussion about redundant plugins in the cvs. Could a NP-CPAN lead to redundant plugins like eg check_http check_http2 (,...)? I haven't reviewed many plugins, but in my opinion (i'm not the greatest coder) there are already some plugins at nagiosexchange, which are improvable. What do you think about it? Is there enough attention paid to the Guidelines? From R.Brodie at rl.ac.uk Tue Jul 12 04:24:14 2005 From: R.Brodie at rl.ac.uk (Brodie, R (Richard)) Date: Tue Jul 12 04:24:14 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) Message-ID: <57BFD82EEF0CDE41A72C4EDADF8A01B2FB41C0@exchange27.fed.cclrc.ac.uk> Sean Finney wrote: > my main concern is with qa-related topics. sure, there's the NIH > syndrome you mentioned earlier (which i think is relevant), but i'm > more worried about the overall lack of control over quality, as well > as pollution of our namespace/reputation. I think a long term goal might be to have an 'unstable?' group that was easy to install as a package. These would be to some degree blessed: maybe requiring a core plugin developer to sponsor. Anything else would be strictly unofficial. > i think such concerns could be addressed if we had some way of providing > some kind of nagiosplug "status" or "rating", where it was made clear > whether or not it was reviewed by a member of the team, whether it was > being considered for inclusion, etc. Another useful thing would be to track whether maintenance is ongoing, and who by. CPAN appears to be fairly strong on this. At the moment, contrib is a bit of a dumping ground; I think this idea has the potential to improve on that. Richard Brodie From ae at op5.se Tue Jul 12 07:52:31 2005 From: ae at op5.se (Andreas Ericsson) Date: Tue Jul 12 07:52:31 2005 Subject: [Nagiosplug-devel] Fix for check_nagios plugin with Nagios 2.03b In-Reply-To: <20050711232633.GA27788@seanius.net> References: <20050711181245.D481A4F4002@desire.netways.de> <20050711232633.GA27788@seanius.net> Message-ID: <42D3D8AE.1090508@op5.se> sean finney wrote: > hi scott, > > On Mon, Jul 11, 2005 at 08:12:45PM +0200, Scott Greenman wrote: > >>I just started using nagios2.03b with the latest plugins, and found >> that the check_nagios plugin wasn't correctly computing the time >> since last update of the status log. I found several people who >> had reported this problem on the nagiosplug-help list, but no responses. >> I tweaked the plugin code and it seems to work correctly now. I >> don't know how to go about contributing this change to the community, >> so I'm just posting a diff here and if someone more in the know >> wants to pick it up, great.... > > > the "preferred" way would be if you could open up a ticket in the bug > tracker on the sourceforge site. you could include in the report such > a patch. > > >>The problem is a difference between the status log file formats >> between versions of Nagios. I have no idea in what version of Nagios >> this change occurred. Implimenting this change will fix the plugin >> for Nagios 2.0b3, but will break it for earlier versions. Ultimately >> it seems that two different plugins are needed, or one plugin that >> has a flag to indicate which Nagios verison or can check the Nagios >> version itself. > > > i think what would be best is a cmdline option to enable the nagios v2 > specific format, or perhaps as you suggest an automatic detection. Why not simply use the stat.st_mtime? Actually parsing the data seems a waste of cycles if you ask me. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From seanius at seanius.net Tue Jul 12 07:52:39 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 12 07:52:39 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B2FB41C0@exchange27.fed.cclrc.ac.uk> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> Message-ID: <20050712144911.GA5020@seanius.net> hi, (resending this one, the last one got caught by the mlm) On Tue, Jul 12, 2005 at 07:26:17AM +0100, Ton Voon wrote: > Hadn't thought of the namespace situation. CPAN does have control > over what namespace perl modules can take, at least at a top level. > Not sure how this would work for plugins, which is just a single file > name... Any ideas on controlling this? Or is it even a problem? i think it directly depends on how this ties in with the project, and how it's made available. i don't think it's an insurmountable problem. > I like CPAN's rating system. It is not fully used, but it gives a > good general feedback on the quality of a perl module from the users. > I'll add to my wish list. > > As for quality, I was thinking that there are varying levels of > "certification" for a plugin (this is based on an email thread a long > time ago, which I can't recall which). I propose that the dev guide > should show level 1 as "returns 0 OK, 1 warn, 2 crit, with one line > output", --help/-h with output, --version/-v for version info. Level > 2 is perf data. Level 3 is stuff like -v -v -v for extra debug > options and internationalization. Level 4 is stuff to do with > integration into core (using common libraries, etc). for functionality-purposes, this would be good. however there's also an orthogonal track of qa ratings for whether or not the code has been audited by a nagiosplug team member, whether or not it's scheduled for inclusion, etc. > I'm trying to work out our requirements for the NP collection system. > Then I plan on having a discussion with Nagiosexchange, where I'll > find out if they can meet all the requirements we have, in return for > us officially promoting the use of their site. Seems like a win-win: > we'll get what we want, while they gain exposure. i've spoken privately in the past with some of the people from nagiosexchange and they seem fairly reasonable folks. i'd be interested to hear what they have to say about it. On Tue, Jul 12, 2005 at 12:22:36PM +0100, Brodie, R (Richard) wrote: > Another useful thing would be to track whether maintenance is ongoing, > and who by. CPAN appears to be fairly strong on this. At the moment, > contrib is a bit of a dumping ground; I think this idea has the > potential to improve on that. yeah. i think in an ideal world, we could move all of the contrib plugins to either the official plugins directory or into whatever kind of collection system evolved, and then get rid of it entirely. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ae at op5.se Tue Jul 12 08:20:04 2005 From: ae at op5.se (Andreas Ericsson) Date: Tue Jul 12 08:20:04 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: <20050712025945.GA29754@seanius.net> References: <42C10145.90408@op5.se> <20050626162720.GA14990@seanius.net> <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> Message-ID: <42D3DF15.6040004@op5.se> sean finney wrote: > hi, > > On Mon, Jul 11, 2005 at 11:10:35PM +0100, Ton Voon wrote: > >>No opinions about a Nagios plugins CPAN-like area? I'm interested to >>hear what people think. Please respond privately if you prefer. > > > i think providing an easier way for people to submit and review > plugins is a good idea. i do have some concerns though: > > my main concern is with qa-related topics. sure, there's the NIH > syndrome you mentioned earlier (which i think is relevant), but i'm > more worried about the overall lack of control over quality, This shouldn't be a problem, considering the fact that the code quality of todays official plugins isn't exactly stellar. > as well > as pollution of our namespace/reputation. > The official plugins doesn't HAVE a namespace, unless you count the "my_" prefix, which is sort of restricted for personal use by general agreement. I like the np_ you added in front of np_connect() though, so that could be the seed to one. If you're worried about polluting official namespaces then that's already down the drain (the 6/3 rule is broken by the strnl(), strscpy() and whatnot in utils.c, which conflicts nicely with ANSI, POSIX, SUS and BSD). Fortunately, those functions can be done away with fairly easily and any linker that requires a 6/3 uniqueness in symbol names won't compile anything anywhere anyway (now adays, that is). Whatever you do, stay away from the _t suffix (POSIX) and the __ prefix or you'll run into trouble sooner or later. The __ prefix, for those who don't know, is reserved for library use. Symbols containing it aren't supposed to be visible globally but not all linkers have heard of weak aliases, so you're bound to run into trouble sooner or later. > i think such concerns could be addressed if we had some way of providing > some kind of nagiosplug "status" or "rating", where it was made clear > whether or not it was reviewed by a member of the team, whether it was > being considered for inclusion, Bad idea, for (at least) two reasons; 1) Plugins in contrib aren't evaluated, checked or any such thing by official developers today, so it'd be quite a miracle if they (that is, you) started doing so just because you had to download them in a special package as opposed to getting them "for free" when checking out the CVS. 2) If some contributor loses commit access to plugins they've originally written you'll end up with several forks right away. > et c. if such a system existed, i think > it would make a better bridge for plugins to make their way into the > project, and would overall be a good thing. this would also obsolete > the need for a "contrib" section. > > otherwise, i'd be very hesitant for moving in this direction, and am > not sure what it would gain us that couldn't be simply done by linking > to the nagiosexchange site where a similar collection system for plugins > already seems to exist. > I vote link to nagiosexchange. It's a wiki, so plugin authors can put links to whatever they want fairly much wherever they want. Just make it clear that you frown upon people who add nagiosplug-help at lists.sourceforge.net to the help output of their plugins, or in any way claim to be affiliated with the official distro when they're not. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From gh at 3gupload.com Tue Jul 12 13:16:23 2005 From: gh at 3gupload.com (Garrett Honeycutt) Date: Tue Jul 12 13:16:23 2005 Subject: [Nagiosplug-devel] check_mem minor bugfix Message-ID: <1121199015.27103.124.camel@gspot.internal.3gupload.com> I did a small bugfix to check_mem 1.3, so that the perf data is in the correct format. check_mem 1.4 has been attached and the diff from 1.3 to 1.4 is below. --- check_mem1.3 2005-07-12 14:45:56.000000000 -0500 +++ check_mem1.4 2005-07-12 14:50:08.000000000 -0500 @@ -1,6 +1,6 @@ #! /usr/bin/perl -w # -# check_mem v1.3 plugin for nagios +# check_mem v1.4 plugin for nagios # # uses the output of `free` to find the percentage of memory used # @@ -8,6 +8,9 @@ # # History: # +# v1.4 Garrett Honeycutt - gh at 3gupload.com +# + Fixed PerfData output to adhere to standards and show crit/warn values +# # v1.3 Rouven Homann - rouven.homann at cimt-ag.de # + Memory installed, used and free displayed in verbose mode # + Bit Code Cleanup @@ -47,7 +50,7 @@ "c=s" => \$opt_c, "critical=s" => \$opt_c); if ($opt_V) { - print_revision($PROGNAME,'$Revision: 1.3 $'); + print_revision($PROGNAME,'$Revision: 1.4 $'); exit $ERRORS{'UNKNOWN'}; } @@ -66,16 +69,16 @@ my ($mem_percent, $mem_total, $mem_used) = &sys_stats(); my $free_mem = $mem_total - $mem_used; if ($mem_percent>$critical) { - if ($verbose) { print "CRITICAL: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;0;0;\n";} - else { print "CRITICAL: $mem_percent\% Used Memory | MemUsed= $mem_percent\%;0;0;\n";}; + if ($verbose) { print "CRITICAL: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;$warning;$critica l \n";} + else { print "CRITICAL: $mem_percent\% Used Memory | MemUsed= $mem_percent\%;$warning;$critical\n";}; exit $ERRORS{'CRITICAL'}; } elsif ($mem_percent>$warning) { - if ($verbose) { print "WARNING: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;0;0;\n";} - else { print "WARNING: $mem_percent\% Used Memory | MemUsed= $mem_percent\%;0;0;\n";}; + if ($verbose) { print "WARNING: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;$warning;$critical \n";} + else { print "WARNING: $mem_percent\% Used Memory | MemUsed= $mem_percent\%;$warning;$critical\n";}; exit $ERRORS{'WARNING'}; } else { - if ($verbose) { print "OK: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;0;0;\n"; } - else { print "OK: $mem_percent\% Used Memory | MemUsed=$mem_percent \%;0;0;\n";}; + if ($verbose) { print "OK: $mem_percent\% Used Memory - Total: $mem_total MB, used: $mem_used MB, free: $free_mem MB | MemUsed= $mem_percent\%;$warning;$critical \n"; } + else { print "OK: $mem_percent\% Used Memory | MemUsed=$mem_percent \%;$warning;$critical\n";}; exit $ERRORS{'OK'}; } @@ -96,7 +99,7 @@ } sub print_help () { - print_revision($PROGNAME,'$Revision: 1.3 $'); + print_revision($PROGNAME,'$Revision: 1.4 $'); print "Copyright (c) 2005 Garrett Honeycutt/Rouven Homann\n"; print "\n"; print_usage(); @@ -107,4 +110,4 @@ print "-h = This screen.\n\n"; support(); } - \ No newline at end of file + -- // Garrett Honeycutt // Sr. Systems Administrator // 3GUpload.com, Inc. // 317.472.4969 Office -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mem Type: application/x-perl Size: 3821 bytes Desc: not available URL: From seanius at seanius.net Tue Jul 12 17:25:14 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 12 17:25:14 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: <42D3DF15.6040004@op5.se> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> <42D3DF15.6040004@op5.se> Message-ID: <20050713002042.GA9993@seanius.net> On Tue, Jul 12, 2005 at 05:17:41PM +0200, Andreas Ericsson wrote: > This shouldn't be a problem, considering the fact that the code quality > of todays official plugins isn't exactly stellar. perhaps this may be true, but this is something i'm actively working on making less true. i also think your standards are a more critical than most peoples'. but more importantly, i look at the quality of what's in the official plugins, and look at what's in contrib, and i kind of plot an imaginary line in my mind and imagine that introducing such an archive would take things even further out. > The official plugins doesn't HAVE a namespace, unless you count the > "my_" prefix, which is sort of restricted for personal use by general > agreement. I like the np_ you added in front of np_connect() though, so > that could be the seed to one. i was referring not so much to the API (though yes, the future internal API should have a common naming scheme) as the names of the plugins themselves. > >i think such concerns could be addressed if we had some way of providing > >some kind of nagiosplug "status" or "rating", where it was made clear > >whether or not it was reviewed by a member of the team, whether it was > >being considered for inclusion, > > > Bad idea, for (at least) two reasons; > 1) Plugins in contrib aren't evaluated, checked or any such thing by > official developers today, so it'd be quite a miracle if they (that is, > you) started doing so just because you had to download them in a special > package as opposed to getting them "for free" when checking out the CVS. i think the idea is that independant developers could solicit sponsorship of plugins as part of introducing them into nagios-plugins-proper. this would also lead to the eventual demise of the contrib section. but perhaps you're right. > I vote link to nagiosexchange. It's a wiki, so plugin authors can put > links to whatever they want fairly much wherever they want. > > Just make it clear that you frown upon people who add > nagiosplug-help at lists.sourceforge.net to the help output of their > plugins, or in any way claim to be affiliated with the official distro > when they're not. this is always another option. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Tue Jul 12 17:29:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 12 17:29:40 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235245 ] check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Message-ID: Bugs item #1235245, was opened at 2005-07-09 11:42 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Marc Gimpel (mgimpel) >Assigned to: M. Sean Finney (seanius) Summary: check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Initial Comment: When trying to run check_pgsql on Red Hat Enterprise Linux 4 with the PostgreSQL 8 RPMs from the PostgreSQL website I get the following error: [root at c9 ~]# /usr/lib/nagios/plugins/check_pgsql /usr/lib/nagios/plugins/check_pgsql: error while loading shared libraries: libpq.so.3: cannot open shared object file: No such file or directory The reason is that the PostgreSQL RPMs for Red Hat Enterprise Linux 4 contain the following libraries: /usr/lib/libpq.so.4 /usr/lib/libpq.so.4.0 ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-07-12 20:26 Message: Logged In: YES user_id=226838 hi, are you using precompiled binaries from an rpm or something? the reason you're getting this problem is because the check_pgsql plugin was compiled against postgres 7 (soname = 3) but you're running postgres 8 (soname = 4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 From seanius at seanius.net Tue Jul 12 17:30:02 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 12 17:30:02 2005 Subject: [Nagiosplug-devel] Fix for check_nagios plugin with Nagios 2.03b In-Reply-To: <42D3D8AE.1090508@op5.se> References: <20050711181245.D481A4F4002@desire.netways.de> <20050711232633.GA27788@seanius.net> <42D3D8AE.1090508@op5.se> Message-ID: <20050713002249.GB9993@seanius.net> On Tue, Jul 12, 2005 at 04:50:22PM +0200, Andreas Ericsson wrote: > Why not simply use the stat.st_mtime? Actually parsing the data seems a > waste of cycles if you ask me. i don't see why the plugin couldn't do both. i guess i see some wierd corner case where nagios was modifying the mtime of the file but not actually writing updates to the file or something similar. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ae at op5.se Tue Jul 12 18:29:09 2005 From: ae at op5.se (Andreas Ericsson) Date: Tue Jul 12 18:29:09 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: <20050713002042.GA9993@seanius.net> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> <42D3DF15.6040004@op5.se> <20050713002042.GA9993@seanius.net> Message-ID: <42D46D28.8000409@op5.se> sean finney wrote: > On Tue, Jul 12, 2005 at 05:17:41PM +0200, Andreas Ericsson wrote: > >>This shouldn't be a problem, considering the fact that the code quality >>of todays official plugins isn't exactly stellar. > > > perhaps this may be true, but this is something i'm actively working on > making less true. i also think your standards are a more critical than > most peoples'. That's neither an unmixed blessing nor a very big problem. I also think it's quite true. It's also one of the main reasons I had to fork the plugins and keep a separate branch of them. The fixes amounted to too many too fast for me to be able to handle it without commit access to some sort of SCM. > but more importantly, i look at the quality of what's > in the official plugins, and look at what's in contrib, and i kind of > plot an imaginary line in my mind and imagine that introducing such > an archive would take things even further out. > > >>The official plugins doesn't HAVE a namespace, unless you count the >>"my_" prefix, which is sort of restricted for personal use by general >>agreement. I like the np_ you added in front of np_connect() though, so >>that could be the seed to one. > > > i was referring not so much to the API (though yes, the future internal > API should have a common naming scheme) as the names of the plugins > themselves. > You mean the check_ prefix? It's not a naming standard per se, as it's totally unrelated to the nagiosplug project (or nagios for that matter), except by coincidence. If the prefix was np_ or nplg_ (snmpget, snmpwalk, snmpgetbulk et al) you might have better luck, but as it stands I think your chances are pretty slim of making other people adhere to it. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From seanius at seanius.net Tue Jul 12 19:30:47 2005 From: seanius at seanius.net (sean finney) Date: Tue Jul 12 19:30:47 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files) In-Reply-To: <57BFD82EEF0CDE41A72C4EDADF8A01B2FB41C0@exchange27.fed.cclrc.ac.uk> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> Message-ID: <20050712144436.GA4871@seanius.net> hi, On Tue, Jul 12, 2005 at 07:26:17AM +0100, Ton Voon wrote: > Hadn't thought of the namespace situation. CPAN does have control > over what namespace perl modules can take, at least at a top level. > Not sure how this would work for plugins, which is just a single file > name... Any ideas on controlling this? Or is it even a problem? i think it directly depends on how this ties in with the project, and how it's made available. i don't think it's an insurmountable problem. > I like CPAN's rating system. It is not fully used, but it gives a > good general feedback on the quality of a perl module from the users. > I'll add to my wish list. > > As for quality, I was thinking that there are varying levels of > "certification" for a plugin (this is based on an email thread a long > time ago, which I can't recall which). I propose that the dev guide > should show level 1 as "returns 0 OK, 1 warn, 2 crit, with one line > output", --help/-h with output, --version/-v for version info. Level > 2 is perf data. Level 3 is stuff like -v -v -v for extra debug > options and internationalization. Level 4 is stuff to do with > integration into core (using common libraries, etc). for functionality-purposes, this would be good. however there's also an orthogonal track of qa ratings for whether or not the code has been audited by a nagiosplug team member, whether or not it's scheduled for inclusion, etc. > I'm trying to work out our requirements for the NP collection system. > Then I plan on having a discussion with Nagiosexchange, where I'll > find out if they can meet all the requirements we have, in return for > us officially promoting the use of their site. Seems like a win-win: > we'll get what we want, while they gain exposure. i've spoken privately in the past with some of the people from nagiosexchange and they seem fairly reasonable folks. i'd be interested to hear what they have to say about it. On Tue, Jul 12, 2005 at 12:22:36PM +0100, Brodie, R (Richard) wrote: > Another useful thing would be to track whether maintenance is ongoing, > and who by. CPAN appears to be fairly strong on this. At the moment, > contrib is a bit of a dumping ground; I think this idea has the > potential to improve on that. yeah. i think in an ideal world, we could move all of the contrib plugins to either the official plugins directory or into whatever kind of collection system evolved, and then get rid of it entirely. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Wed Jul 13 02:33:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 13 02:33:16 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235245 ] check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Message-ID: Bugs item #1235245, was opened at 2005-07-09 17:42 Message generated for change (Comment added) made by mgimpel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Marc Gimpel (mgimpel) Assigned to: M. Sean Finney (seanius) Summary: check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Initial Comment: When trying to run check_pgsql on Red Hat Enterprise Linux 4 with the PostgreSQL 8 RPMs from the PostgreSQL website I get the following error: [root at c9 ~]# /usr/lib/nagios/plugins/check_pgsql /usr/lib/nagios/plugins/check_pgsql: error while loading shared libraries: libpq.so.3: cannot open shared object file: No such file or directory The reason is that the PostgreSQL RPMs for Red Hat Enterprise Linux 4 contain the following libraries: /usr/lib/libpq.so.4 /usr/lib/libpq.so.4.0 ---------------------------------------------------------------------- >Comment By: Marc Gimpel (mgimpel) Date: 2005-07-13 11:27 Message: Logged In: YES user_id=764314 Hi, I'm using the precompiles binaries provided by PostgreSQL on their web site http://www.postgresql.org/ftp/binary/v8.0.3/linux/rpms/redhat/rhel-es-4/ ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-13 02:26 Message: Logged In: YES user_id=226838 hi, are you using precompiled binaries from an rpm or something? the reason you're getting this problem is because the check_pgsql plugin was compiled against postgres 7 (soname = 3) but you're running postgres 8 (soname = 4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 From noreply at sourceforge.net Wed Jul 13 02:34:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 13 02:34:40 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235245 ] check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Message-ID: Bugs item #1235245, was opened at 2005-07-09 17:42 Message generated for change (Comment added) made by mgimpel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Marc Gimpel (mgimpel) Assigned to: M. Sean Finney (seanius) Summary: check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Initial Comment: When trying to run check_pgsql on Red Hat Enterprise Linux 4 with the PostgreSQL 8 RPMs from the PostgreSQL website I get the following error: [root at c9 ~]# /usr/lib/nagios/plugins/check_pgsql /usr/lib/nagios/plugins/check_pgsql: error while loading shared libraries: libpq.so.3: cannot open shared object file: No such file or directory The reason is that the PostgreSQL RPMs for Red Hat Enterprise Linux 4 contain the following libraries: /usr/lib/libpq.so.4 /usr/lib/libpq.so.4.0 ---------------------------------------------------------------------- >Comment By: Marc Gimpel (mgimpel) Date: 2005-07-13 11:31 Message: Logged In: YES user_id=764314 Hi, For the nagios plugins, I'm using the binarie RPMs from http://dag.wieers.com/packages/nagios-plugins/nagios-plugins-1.4-2.2.el4.rf.i386.rpm which are also for RHEL 4 ---------------------------------------------------------------------- Comment By: Marc Gimpel (mgimpel) Date: 2005-07-13 11:27 Message: Logged In: YES user_id=764314 Hi, I'm using the precompiles binaries provided by PostgreSQL on their web site http://www.postgresql.org/ftp/binary/v8.0.3/linux/rpms/redhat/rhel-es-4/ ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-13 02:26 Message: Logged In: YES user_id=226838 hi, are you using precompiled binaries from an rpm or something? the reason you're getting this problem is because the check_pgsql plugin was compiled against postgres 7 (soname = 3) but you're running postgres 8 (soname = 4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 From noreply at sourceforge.net Wed Jul 13 06:29:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 13 06:29:42 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235245 ] check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Message-ID: Bugs item #1235245, was opened at 2005-07-09 11:42 Message generated for change (Settings changed) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Submitted By: Marc Gimpel (mgimpel) Assigned to: M. Sean Finney (seanius) Summary: check_pgsql doesn't work with PostgreSQL 8 on RHEL 4 Initial Comment: When trying to run check_pgsql on Red Hat Enterprise Linux 4 with the PostgreSQL 8 RPMs from the PostgreSQL website I get the following error: [root at c9 ~]# /usr/lib/nagios/plugins/check_pgsql /usr/lib/nagios/plugins/check_pgsql: error while loading shared libraries: libpq.so.3: cannot open shared object file: No such file or directory The reason is that the PostgreSQL RPMs for Red Hat Enterprise Linux 4 contain the following libraries: /usr/lib/libpq.so.4 /usr/lib/libpq.so.4.0 ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-07-13 09:27 Message: Logged In: YES user_id=226838 hi there, i'm going to close this bug because it has little to do with our software and more to do with how it is being compiled and distributed by third parties over whom we have no control. i will provide a couple suggestions though: - contact dag wieers and ask him to recompile the plugins against postgres 8 - recompile the plugins yourself, using either dag's source rpm or the source code provided by us. ---------------------------------------------------------------------- Comment By: Marc Gimpel (mgimpel) Date: 2005-07-13 05:31 Message: Logged In: YES user_id=764314 Hi, For the nagios plugins, I'm using the binarie RPMs from http://dag.wieers.com/packages/nagios-plugins/nagios-plugins-1.4-2.2.el4.rf.i386.rpm which are also for RHEL 4 ---------------------------------------------------------------------- Comment By: Marc Gimpel (mgimpel) Date: 2005-07-13 05:27 Message: Logged In: YES user_id=764314 Hi, I'm using the precompiles binaries provided by PostgreSQL on their web site http://www.postgresql.org/ftp/binary/v8.0.3/linux/rpms/redhat/rhel-es-4/ ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-07-12 20:26 Message: Logged In: YES user_id=226838 hi, are you using precompiled binaries from an rpm or something? the reason you're getting this problem is because the check_pgsql plugin was compiled against postgres 7 (soname = 3) but you're running postgres 8 (soname = 4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1235245&group_id=29880 From noreply at sourceforge.net Wed Jul 13 18:08:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 13 18:08:09 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-11 05:34 Message generated for change (Comment added) made by johnwarburton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-14 11:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-06 04:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-28 12:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From noreply at sourceforge.net Thu Jul 14 04:29:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 14 04:29:23 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1218438 ] check_radius.c: In function `main': Message-ID: Bugs item #1218438, was opened at 2005-06-10 15:34 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: S?bastien Guay (sebasguay) Assigned to: M. Sean Finney (seanius) Summary: check_radius.c: In function `main': Initial Comment: When trying to compile on slackware I got the following check_radius.c: In function `main': check_radius.c:126: error: too few arguments to function `rc_avpair_add' check_radius.c:127: error: too few arguments to function `rc_avpair_add' check_radius.c:128: error: too few arguments to function `rc_avpair_add' check_radius.c:129: error: too few arguments to function `rc_avpair_add' check_radius.c:139: error: too few arguments to function `rc_avpair_add' check_radius.c:145: error: too few arguments to function `rc_send_server' make[2]: *** [check_radius.o] Error 1 make[2]: Leaving directory `/usr/local/src/nagios-plugins-1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins-1.4' make: *** [all] Error 2 I uninstalled the package ppp-2.4.2-i486-2 and redo a make and all was fine. After I reinstalled ppp-2.4.2-i486-2. ppp-2.4.2-i486-2 has a file radiusclient.h. S?bas ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-07-14 07:25 Message: Logged In: YES user_id=226838 hi, thanks for the extra info. i'll try and look more into this in the next couple of weeks, and see if i can do some voodoo in autoconf to determine the correct prototypes and version of radiusclient. ---------------------------------------------------------------------- Comment By: John Warburton (johnwarburton) Date: 2005-07-13 21:05 Message: Logged In: YES user_id=1192023 Hi Guys The problem isn't specific to Slackware. It is anyone that runs with newer versions of the radiusclient library. The REQUIREMENTS file says they can be found at http://www.cityline.net/~lf/radius/ versions radiusclient-0.3.1-1 That website no longer exists, but I have tracked down the developer to http://developer.berlios.de/projects/radiusclient-ng/ I was getting the same compile time errors on Solaris 8 with radiusclient-0.4.9 as S?bastien. I downloaded an earlier client library - radiusclient-0.3.3, which compiled, but I have no idea on configuring, so doesn't seem to work. It seems to me the radius client library has moved on, but the Nagios plugin hasn't. Since my site has moved to openradius, I will just use a very simple shell script as a plugin to attempt login using the openradius "radclient" program. Regards John ---------------------------------------------------------------------- Comment By: S?bastien Guay (sebasguay) Date: 2005-07-05 14:11 Message: Logged In: YES user_id=265586 Hi Sean, > this looks like a problem with slackware or the slackware > package of ppp then. where is the radiusclient.h provided > by your libradius package (or whatever the slackware > equivalent is that provides radiusclient.h)? The file radiusclient.h is part of the package ppp (or I misunderstood your question?). > i'm not sure why installing ppp would plop an include file > used to build ppp in a compiler accessible directory in the > first place, Not sure either :) > but unless you can provide a convincing reason > why this is a problem with the nagios plugins, i'm going to > close out the bug in a week's time. My goal was not to convince anybody, it was just to let you know that any Slackware user may have a problem to compile nagios plugins if they have the ppp package installed. As I said, the problem was easily solved on my side by uninstalling ppp and re-installing it after. Here's the definition of rc_avpair_add() function in the radiusclient.h file in the ppp package VALUE_PAIR *rc_avpair_add __P((VALUE_PAIR **, int, void *, int, int)); and here's the call of rc_avpair_add in check_radius.c rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) I don't know anything about libradius. Do you know what is the *supposed* arguments number for rc_avpair_add()? If it's 4, I can send a bug report to Patrick. The radiusclient.h file is in attach. S?bas ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-27 22:06 Message: Logged In: YES user_id=226838 hi sebastien, this looks like a problem with slackware or the slackware package of ppp then. where is the radiusclient.h provided by your libradius package (or whatever the slackware equivalent is that provides radiusclient.h)? i'm not sure why installing ppp would plop an include file used to build ppp in a compiler accessible directory in the first place, but unless you can provide a convincing reason why this is a problem with the nagios plugins, i'm going to close out the bug in a week's time. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1218438&group_id=29880 From tonvoon at mac.com Thu Jul 14 12:26:57 2005 From: tonvoon at mac.com (Ton Voon) Date: Thu Jul 14 12:26:57 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: <42D46D28.8000409@op5.se> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> <42D3DF15.6040004@op5.se> <20050713002042.GA9993@seanius.net> <42D46D28.8000409@op5.se> Message-ID: <65D63169-0684-4A38-878A-67A22535BC9B@mac.com> Thank you for your thoughts on the future plugin archive. Matthias Eble coined this as NP-CPAN, which I will use for now. In summary: Need to move away from contrib area. For: Richard Brodie, Sean Finney, Andreas Ericsson. Against: none. Control of names of plugins. Andreas thinks this is not possible and I would agree with him. However, I would like names not to clash (thinking about simplified downloading). Matthias is worried about check_http and check_http2, etc. I'm not sure we can control this in any meaningful way, so a user will need to decide on which plugin they would use. I think if we could get a sense of how "maintained" a plugin is and other users feedback, this would help a user in making a decision on which to use. Quality issues. Sean is worried about quality of external plugins, but the point of this is to be able to unleash the community to develop and maintain their plugins themselves. Andreas is right: current contribs are not really QA'd and forks will happen. I think Stanley Hopcroft said it best: "CPAN is [...] absolutely indispensable [...] because of the high quality of __some__ of the modules [and is a] dumping ground for other modules of lower quality". I think plugins will sink or rise based on popularity and/ or quality, which will be unrelated to how Nagios Plugins performs. Easy install. Richard mentions an unstable package for download, which shows some degree of "blessed" plugins by the project. As the point is to unleash, I don't think this is a reasonable expectation because it is again putting work onto this project. However, NP-CPAN should have some easy way of installing plugins. Certification. Sean thinks is a good idea, but also wants metrics on whether audited, or scheduled for inclusion. Again, as my aim is to unleash, I think auditing is an impossible objective. I would hope that some plugins come with test cases too, but that is fully up to the developer. Nagiosexchange. Sean says in his previous experience they seem "reasonable" and given they have some infrastructure already there, I'm inclined to talk with them. So I think there is a consensus to do it. No one has really commented on requirements, so here's my interpretation of the responses plus a few of my own: MUST HAVE: mirroring of repository, last updated, non-clashing plugin names SHOULD HAVE: user feedbacks, certification results NICE TO HAVE: easy downloadability I think the must haves must be available for NP-CPAN to be endorsed, with should haves as soon as possible. So, unless there are any objections by next Tuesday, I'll begin discussions with Nagiosexchange if they can be our official repository. Ton From ae at op5.se Thu Jul 14 14:01:08 2005 From: ae at op5.se (Andreas Ericsson) Date: Thu Jul 14 14:01:08 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: <65D63169-0684-4A38-878A-67A22535BC9B@mac.com> References: <42C037E2.12509.152FDE9@localhost> <20050627235500.GA31390@seanius.net> <20050628042526.GA657@ws11114.aipo.gov.au> <20050628151555.GA7661@seanius.net> <4235FF77-2AEC-471A-BA84-FF0B305E3D34@mac.com> <20050706224610.GA236@IPAustralia.Gov.AU> <11D88196-2672-4DCD-9AB2-61AD1D7F7DCA@altinity.com> <20050712025945.GA29754@seanius.net> <42D3DF15.6040004@op5.se> <20050713002042.GA9993@seanius.net> <42D46D28.8000409@op5.se> <65D63169-0684-4A38-878A-67A22535BC9B@mac.com> Message-ID: <42D6D1BB.2030002@op5.se> Ton Voon wrote: > Thank you for your thoughts on the future plugin archive. Matthias Eble > coined this as NP-CPAN, which I will use for now. > > In summary: > > Need to move away from contrib area. For: Richard Brodie, Sean Finney, > Andreas Ericsson. Against: none. > > Control of names of plugins. Andreas thinks this is not possible and I > would agree with him. However, I would like names not to clash > (thinking about simplified downloading). Matthias is worried about > check_http and check_http2, etc. I'm not sure we can control this in > any meaningful way, so a user will need to decide on which plugin they > would use. I think if we could get a sense of how "maintained" a plugin > is and other users feedback, this would help a user in making a > decision on which to use. > > Quality issues. Sean is worried about quality of external plugins, but > the point of this is to be able to unleash the community to develop and > maintain their plugins themselves. Andreas is right: current contribs > are not really QA'd and forks will happen. I think Stanley Hopcroft > said it best: "CPAN is [...] absolutely indispensable [...] because of > the high quality of __some__ of the modules [and is a] dumping ground > for other modules of lower quality". I think plugins will sink or rise > based on popularity and/ or quality, which will be unrelated to how > Nagios Plugins performs. > > Easy install. Richard mentions an unstable package for download, which > shows some degree of "blessed" plugins by the project. As the point is > to unleash, I don't think this is a reasonable expectation because it > is again putting work onto this project. However, NP-CPAN should have > some easy way of installing plugins. > > Certification. Sean thinks is a good idea, but also wants metrics on > whether audited, or scheduled for inclusion. Again, as my aim is to > unleash, I think auditing is an impossible objective. I would hope that > some plugins come with test cases too, but that is fully up to the > developer. > > Nagiosexchange. Sean says in his previous experience they seem > "reasonable" and given they have some infrastructure already there, I'm > inclined to talk with them. > > So I think there is a consensus to do it. No one has really commented > on requirements, so here's my interpretation of the responses plus a > few of my own: > > MUST HAVE: mirroring of repository, last updated, non-clashing plugin > names Skip the non-clashing plugin names. It won't last. Also, the entire site must be mirror-able through plain FTP or some such. wget and other web-mirroring programs have a tendency to include weird things and skip some others. A pure and simple lftp-style mirroring is the best. > SHOULD HAVE: user feedbacks, certification results > NICE TO HAVE: easy downloadability > I think that "easy downloadability" actually comes first, since a repository is completely useless unless the data can be extracted from it in a simple manner. User feedbacks is more like nice to have (it's not very used on CPAN, and I don't really think people will sit around and vote for various plugins). > I think the must haves must be available for NP-CPAN to be endorsed, > with should haves as soon as possible. > > So, unless there are any objections by next Tuesday, I'll begin > discussions with Nagiosexchange if they can be our official repository. > Well, I had some objections, but for the sake of expediency you can simple disregard them. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From Ton.Voon at egg.com Fri Jul 15 03:38:00 2005 From: Ton.Voon at egg.com (Voon, Ton) Date: Fri Jul 15 03:38:00 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive Message-ID: Sorry for top-posting. Why would non-clashing names not last? For example, if there were multiple implementations of check_physical_disk, how do you propose they be differentiated? By author? I think a restriction of non-clashing names will force people to use more suitable names (check_rs6000_physical_disks). Easier to lift a restriction than to apply one later. I'd obviously expect easy downloading, I think my thoughts were around automated installs of plugins and maybe groups of plugins. Of course, it helps if the plugin names do not clash! But you are right, it should be higher in priority, so I'll move it to MUST HAVE. I think user feedback is good for a guage on the quality of the plugin. It effectively moves the auditing of a plugin from a small set of people (the dev team) to the wider community. I use the Amazon review system a lot to guage how good a product is - I don't see how that is different on a plugin basis. However, not essential on day 1, hence in the SHOULD HAVE. Apologies if I missed your other objections. Can you summarise? -----Original Message----- From: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of Andreas Ericsson Sent: 14 July 2005 21:58 To: NagiosPlug Devel Subject: Re: [Nagiosplug-devel] Nagios plugins CPAN-like archive Ton Voon wrote: > Thank you for your thoughts on the future plugin archive. Matthias > Eble coined this as NP-CPAN, which I will use for now. > > In summary: > > Need to move away from contrib area. For: Richard Brodie, Sean > Finney, Andreas Ericsson. Against: none. > > Control of names of plugins. Andreas thinks this is not possible and > I would agree with him. However, I would like names not to clash > (thinking about simplified downloading). Matthias is worried about > check_http and check_http2, etc. I'm not sure we can control this in > any meaningful way, so a user will need to decide on which plugin > they would use. I think if we could get a sense of how "maintained" a > plugin is and other users feedback, this would help a user in making > a decision on which to use. > > Quality issues. Sean is worried about quality of external plugins, > but the point of this is to be able to unleash the community to > develop and maintain their plugins themselves. Andreas is right: > current contribs are not really QA'd and forks will happen. I think > Stanley Hopcroft said it best: "CPAN is [...] absolutely > indispensable [...] because of the high quality of __some__ of the > modules [and is a] dumping ground for other modules of lower > quality". I think plugins will sink or rise based on popularity and/ > or quality, which will be unrelated to how Nagios Plugins performs. > > Easy install. Richard mentions an unstable package for download, > which shows some degree of "blessed" plugins by the project. As the > point is to unleash, I don't think this is a reasonable expectation > because it is again putting work onto this project. However, NP-CPAN > should have some easy way of installing plugins. > > Certification. Sean thinks is a good idea, but also wants metrics on > whether audited, or scheduled for inclusion. Again, as my aim is to > unleash, I think auditing is an impossible objective. I would hope > that some plugins come with test cases too, but that is fully up to > the developer. > > Nagiosexchange. Sean says in his previous experience they seem > "reasonable" and given they have some infrastructure already there, > I'm inclined to talk with them. > > So I think there is a consensus to do it. No one has really commented > on requirements, so here's my interpretation of the responses plus a > few of my own: > > MUST HAVE: mirroring of repository, last updated, non-clashing plugin > names Skip the non-clashing plugin names. It won't last. Also, the entire site must be mirror-able through plain FTP or some such. wget and other web-mirroring programs have a tendency to include weird things and skip some others. A pure and simple lftp-style mirroring is the best. > SHOULD HAVE: user feedbacks, certification results NICE TO HAVE: easy > downloadability > I think that "easy downloadability" actually comes first, since a repository is completely useless unless the data can be extracted from it in a simple manner. User feedbacks is more like nice to have (it's not very used on CPAN, and I don't really think people will sit around and vote for various plugins). > I think the must haves must be available for NP-CPAN to be endorsed, > with should haves as soon as possible. > > So, unless there are any objections by next Tuesday, I'll begin > discussions with Nagiosexchange if they can be our official repository. > Well, I had some objections, but for the sake of expediency you can simple disregard them. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null ----------------------------------------- Egg is a trading name of the Egg group of companies which includes: Egg plc (reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg no 2999842. Egg Investments Ltd, Egg Banking plc and Egg Financial Intermediation Ltd are authorised and regulated by the Financial Services Authority (FSA) and are entered in the FSA register under numbers 190518, 205621 and 309551 respectively. These members of the Egg group are registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. This e-mail is confidential and for use by the addressee only. If you are not the intended recipient of this e-mail and have received it in error, please return the message to the sender by replying to it and then delete it from your mailbox. Internet e-mails are not necessarily secure. The Egg group of companies do not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Egg group of companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This communication does not create or modify any contract. From ae at op5.se Fri Jul 15 04:51:05 2005 From: ae at op5.se (Andreas Ericsson) Date: Fri Jul 15 04:51:05 2005 Subject: [Nagiosplug-devel] Nagios plugins CPAN-like archive In-Reply-To: References: Message-ID: <42D7A26A.2000705@op5.se> Voon, Ton wrote: > Sorry for top-posting. > > Why would non-clashing names not last? For example, if there were > multiple implementations of check_physical_disk, how do you propose they > be differentiated? By author? I think a restriction of non-clashing > names will force people to use more suitable names > (check_rs6000_physical_disks). Easier to lift a restriction than to > apply one later. > I thought you meant the naming standard thing Sean brought up. Non-clashing names is fairly obvious after all (although check_log and check_log2 seems legal to me). > I think user feedback is good for a guage on the quality of the plugin. > It effectively moves the auditing of a plugin from a small set of people > (the dev team) to the wider community. I use the Amazon review system a > lot to guage how good a product is - I don't see how that is different > on a plugin basis. However, not essential on day 1, hence in the SHOULD > HAVE. > But you stated SHOULD HAVE must be implemented in the near future (a couple of weeks). It is in no respect vital to the functionality of the plugin or the NPAN's (Nagios Plugin Archive Network) functionality. Granted, it's nice if it's there, but compared to amazon (a couple of million hits per day) it won't be even half as valuable, and I don't think very many people will vote for it. Also, authors will ofcourse vote top grade for their own plugins, so initially every plugin would be top rated. > Apologies if I missed your other objections. Can you summarise? > You didn't miss any, so I'll skip the summary. > > -----Original Message----- > From: nagiosplug-devel-admin at lists.sourceforge.net > [mailto:nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of > Andreas Ericsson > Sent: 14 July 2005 21:58 > To: NagiosPlug Devel > Subject: Re: [Nagiosplug-devel] Nagios plugins CPAN-like archive > > Ton Voon wrote: > >>Thank you for your thoughts on the future plugin archive. Matthias >>Eble coined this as NP-CPAN, which I will use for now. >> >>In summary: >> >>Need to move away from contrib area. For: Richard Brodie, Sean >>Finney, Andreas Ericsson. Against: none. >> >>Control of names of plugins. Andreas thinks this is not possible and >>I would agree with him. However, I would like names not to clash >>(thinking about simplified downloading). Matthias is worried about >>check_http and check_http2, etc. I'm not sure we can control this in >>any meaningful way, so a user will need to decide on which plugin >>they would use. I think if we could get a sense of how "maintained" a > > >>plugin is and other users feedback, this would help a user in making >>a decision on which to use. >> >>Quality issues. Sean is worried about quality of external plugins, >>but the point of this is to be able to unleash the community to >>develop and maintain their plugins themselves. Andreas is right: >>current contribs are not really QA'd and forks will happen. I think >>Stanley Hopcroft said it best: "CPAN is [...] absolutely >>indispensable [...] because of the high quality of __some__ of the >>modules [and is a] dumping ground for other modules of lower >>quality". I think plugins will sink or rise based on popularity and/ >>or quality, which will be unrelated to how Nagios Plugins performs. >> >>Easy install. Richard mentions an unstable package for download, >>which shows some degree of "blessed" plugins by the project. As the >>point is to unleash, I don't think this is a reasonable expectation >>because it is again putting work onto this project. However, NP-CPAN >>should have some easy way of installing plugins. >> >>Certification. Sean thinks is a good idea, but also wants metrics on >>whether audited, or scheduled for inclusion. Again, as my aim is to >>unleash, I think auditing is an impossible objective. I would hope >>that some plugins come with test cases too, but that is fully up to >>the developer. >> >>Nagiosexchange. Sean says in his previous experience they seem >>"reasonable" and given they have some infrastructure already there, >>I'm inclined to talk with them. >> >>So I think there is a consensus to do it. No one has really commented >>on requirements, so here's my interpretation of the responses plus a >>few of my own: >> >>MUST HAVE: mirroring of repository, last updated, non-clashing plugin >>names > > > Skip the non-clashing plugin names. It won't last. Also, the entire site > must be mirror-able through plain FTP or some such. wget and other > web-mirroring programs have a tendency to include weird things and skip > some others. A pure and simple lftp-style mirroring is the best. > > >>SHOULD HAVE: user feedbacks, certification results NICE TO HAVE: easy >>downloadability >> > > > I think that "easy downloadability" actually comes first, since a > repository is completely useless unless the data can be extracted from > it in a simple manner. User feedbacks is more like nice to have (it's > not very used on CPAN, and I don't really think people will sit around > and vote for various plugins). > > >>I think the must haves must be available for NP-CPAN to be endorsed, >>with should haves as soon as possible. >> >>So, unless there are any objections by next Tuesday, I'll begin >>discussions with Nagiosexchange if they can be our official > > repository. > > > Well, I had some objections, but for the sake of expediency you can > simple disregard them. > -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From gavin at openfusion.com.au Mon Jul 18 18:57:44 2005 From: gavin at openfusion.com.au (Gavin Carr) Date: Mon Jul 18 18:57:44 2005 Subject: [Nagiosplug-devel] Weird 'No output' problem with new plugin Message-ID: <20050719015226.GA15440@openfusion.com.au> I've just written a perl plugin to do an arbitrary query against a database and do some tests based on the number of rows returned. It's working fine from the command line as the 'nagios' user on the same machine, but plugged into nagios all I'm getting is '(No output!)', even using degenerate tests like 'check_foo -h'. Also, lots of the work is done by a perl module that is working fine in 5 other plugins currently monitoring 30 or 40 services. Any tips on how to go about debugging this, or anything obvious I'm missing? What can be different between running as the nagios user from the command line and running within nagios? How can I trace what nagios is doing more closely? Any ideas appreciated. Cheers, Gavin From pla at softflare.com Mon Jul 18 19:12:42 2005 From: pla at softflare.com (Paul L. Allen) Date: Mon Jul 18 19:12:42 2005 Subject: [Nagiosplug-devel] Re: Weird 'No output' problem with new plugin In-Reply-To: <20050719015226.GA15440@openfusion.com.au> References: <20050719015226.GA15440@openfusion.com.au> Message-ID: <20050719020952.27522.qmail@mullet.softflare.net> Gavin Carr writes: > What can be different between running as the nagios user from the > command line and running within nagios? On some flavours of *nix there are important differences between loging in as nagios and loging in as root then su-ing to nagios. Those differences may be the cause of your problem or they may not. The only way to be sure is to login as nagios and see what the command line gives you. -- Paul Allen Softflare Support From gary at daimonic.org Tue Jul 19 01:44:49 2005 From: gary at daimonic.org (Gary Wall) Date: Tue Jul 19 01:44:49 2005 Subject: [Nagiosplug-devel] Weird 'No output' problem with new plugin In-Reply-To: <20050719015226.GA15440@openfusion.com.au> References: <20050719015226.GA15440@openfusion.com.au> Message-ID: <20050719084230.481BD4F4002@desire.netways.de> Hi Gavin If your plugin is not using strict.pm, and you're running nagios with an embedded perl interpreter, its likely that its not working because its failing to abide my strict. I had this issue in the past. If so, just 'use strict;' in your script and make it work from the command line, then try it with nagios again. //daimonic ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofa q_pi1[showUid]=8758 From gavin at openfusion.com.au Tue Jul 19 04:09:16 2005 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue Jul 19 04:09:16 2005 Subject: [Nagiosplug-devel] Weird 'No output' problem with new plugin In-Reply-To: <20050719084230.481BD4F4002@desire.netways.de> References: <20050719015226.GA15440@openfusion.com.au> <20050719084230.481BD4F4002@desire.netways.de> Message-ID: <20050719110437.GA17276@openfusion.com.au> Hi Gary, On Tue, Jul 19, 2005 at 10:42:30AM +0200, Gary Wall wrote: > If your plugin is not using strict.pm, and you're running nagios > with > > an embedded perl interpreter, its likely that its not working because > > its failing to abide my strict. I had this issue in the past. If > so, > > just 'use strict;' in your script and make it work from the command > > line, then try it with nagios again. Thanks for the suggestion. I am using both 'strict' and warnings, and it's working fine from the command line. How do I tell if nagios has got an embedded interpreter? (I'm using the DAG packages, so haven't built it myself). This is version 1.2, btw. Any other suggestions anyone? I'm really just baffled about how to troubleshoot further. Is there any way of turning up the verbosity of the logging nagios does or something? Cheers, Gavin From gary at daimonic.org Tue Jul 19 05:58:23 2005 From: gary at daimonic.org (Gary Wall) Date: Tue Jul 19 05:58:23 2005 Subject: [Nagiosplug-devel] Weird 'No output' problem with new plugin Message-ID: <17145.195.244.197.114.1121777479.squirrel@deepsky.daimonic.org> Forgot to CC the list :) -------- Original Message -------- Subject: Re: [Nagiosplug-devel] Weird 'No output' problem with new plugin From: "Gary Wall" Date: Tue, July 19, 2005 1:35 pm To: > Hi Gary, > > On Tue, Jul 19, 2005 at 10:42:30AM +0200, Gary Wall wrote: >> If your plugin is not using strict.pm, and you're running nagios >> with >> >> an embedded perl interpreter, its likely that its not working because >> >> its failing to abide my strict. I had this issue in the past. If >> so, >> >> just 'use strict;' in your script and make it work from the command >> >> line, then try it with nagios again. > > Thanks for the suggestion. I am using both 'strict' and warnings, and > it's working fine from the command line. How do I tell if nagios has > got an embedded interpreter? (I'm using the DAG packages, so haven't > built it myself). This is version 1.2, btw. > > Any other suggestions anyone? I'm really just baffled about how to > troubleshoot further. Is there any way of turning up the verbosity of > the logging nagios does or something? > I usually just start nagios with all services removed except the broken one, in foreground mode under strace, like so: strace -vfF -o strace.log nagios /etc/nagios/nagios.cfg It can be annoying but you'll find it sooner or later that way. //gary From cwarden at xerus.org Tue Jul 19 12:19:48 2005 From: cwarden at xerus.org (Christian G. Warden) Date: Tue Jul 19 12:19:48 2005 Subject: [Nagiosplug-devel] check_ping duplicates bug Message-ID: <20050719191435.GZ4744@xerus.org> There's a bug in check_ping in which it incorrectly reports the number of duplicate packets received as the packet loss. A patch is attached which correctly parses the last line of the ping output. It should work for netkit-ping and iputils-ping. [I sent this yesterday, but I wasn't subscribed. Sorry if you get a duplicate.] Christian -------------- next part -------------- diff -ruw nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c nagios-plugins-HEAD-200507151647/plugins/check_ping.c --- nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c 2005-05-25 07:25:55.000000000 -0700 +++ nagios-plugins-HEAD-200507151647/plugins/check_ping.c 2005-07-18 17:27:25.634662410 -0700 @@ -415,6 +415,8 @@ /* get the percent loss statistics */ if(sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d errors, %d%% packet loss",&pl)==1 || + sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d duplicates, %d%% packet loss", &pl) == 1 || + sscanf(buf,"%*d packets transmitted, %*d received, +%*d duplicates, %d%% packet loss", &pl) == 1 || sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% packet loss",&pl)==1 || sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% loss, time",&pl)==1 || sscanf(buf,"%*d packets transmitted, %*d received, %d%% loss, time", &pl)==1 || From pla at softflare.com Tue Jul 19 15:04:00 2005 From: pla at softflare.com (Paul L. Allen) Date: Tue Jul 19 15:04:00 2005 Subject: [Nagiosplug-devel] Auxiliary files required by plugins and other questions In-Reply-To: <20050310112854.GA448@IPAustralia.Gov.AU> References: <20050310112854.GA448@IPAustralia.Gov.AU> Message-ID: <20050719215856.30898.qmail@mullet.softflare.net> Hi Since I can't find a plugin that checks the clamav anti-virus scanner, I'm in the middle of writing one, and various questions have arisen. I can't find answers in the developer guidelines, nor do any of the plugins I'm familiar with set any precedents that I can copy. Since I don't want to set precedents that the plugin development team would disagree with, I figured I'd better ask for opinions first. The first question arises from the fact that I need an auxiliary file and I don't know of any officially-sanctioned place to put it. Specifically, I want the eicar test 'virus' so that I can run clamdscan on it and check that it is identified as a virus. So where to put it? If the plugin makes it into the standard distribution then configure can create a directory for it, such as /usr/local/nagios/share, or /opt/nagios/share, or whatever, in a way that accommodates custom and practise on various distros. But until that happens I'd like to know where to put the eicar file. My gut feeling is that somewhere in /usr/local/nagios (or whatever the equivalent is on some exotic flavours of *nix) would be best simply because the plugin can use a relative path which can be hardcoded rather than having to have configure substitute the appropriate absolute path which would be needed with /opt/nagios/share (or whatever it is on exotic platforms). The second question is that, assuming a path relative to /usr/local/nagios (or equivalent on some flavours of *nix) is the way to go, should it go in an existing sub-directory or a new one? The utils* stuff lives in libexec, but those files are common to many plugins. I'm not sure I like the idea of polluting libexec with files that are specific to one plugin. The share directory seems like a better choice, but the share directory is used essentially for nagios static html. If we go down that route I'd suggest share/plugins would be better than polluting the share directory directly, but that requires changes to configure (if my plugin makes it into the standard distribution) or manual directory creation (if my plugin ends up in contrib or on nagiosexchange). So far this is the only plugin or plugin-to-be that I know of that requires something like this, but I'd rather the developers make a de jure decision rather than me set a de facto precedent. "Shove it in libexec" or "we'll have configure create a share/plugins sub-dir if needed" or "shove it here" or "$%#! off" are the alternative answers. Decide amongst yourselves and let me know. The third question is not relevant to my check_clamav plugin-to-be but I can see that the question might arise in the future and it is related to my previous questions. What if a plugin needs some sort of configuration file? What I'm thinking of is a plugin that requires multiple options for each host it checks, so many options that it's impractical to specify them individually in service definitions, so that the plugin refers to the config file and uses host X service Y to pick up the required info. We pretty much have this situation with one of the contributed MS SQL checks which uses freetds - you specify a server in the check and freetds looks up the details of the server. If this were converted to some sort of native check then for people checking many servers it would be sensible to have a configuration file similar to the freetds one. The obvious place to put such a config file would be /usr/local/nagios/etc (can I stop mentioning 'or equivalent on exotic flavours of *nix' yet?) but I really dislike the idea of polluting that directory with stuff specific to individual plugins. There's no rush in answering this one because (as far as I know) the need has yet to arise. But maybe it would be a good idea to come up with an answer in advance while dealing with related issues (like where do I put my eicar file). The fourth question is what do I do with a readme that is essential to the plugin? The easiest, and most sensible, and most accurate, way of determining if the clamav virus database is up to date is to run freshclam and examine the exit code. For all SANE installations of clamav this will not be a problem, even though the clamav FAQ implies that you must not run freshclam more than four times an hour. Having looked at how freshclam works, and having confirmed my conclusions with the clamav development team, there is absolutely no problem running freshclam as often as you want PROVIDED that you are running a reasonably recent version of clamav and PROVIDED that freshclam uses the default DNSDatabaseInfo mechanism and PROVIDED the DNS on your nagios machine is not well and truly borked so that ignores TTLs. The DNSDatabaseInfo mechanism checks TXT records with 900s (15 minute) TTLs so you'll never query clamav's DNS servers more than 4 times an hour no matter how frequently you run freshclam PROVIDED you do it right. If your setup is borked in some way and you end up doing a DNS query against the clamav DNS servers more often than that then you risk being blocked. And if you try to download the virus signatures repeatedly there is no question about it, you'll be blocked. According to the clamav docs there are systems out there that are this borked, so I want to make it VERY clear that you really should make sure that your freshclam configuration won't hammer the clamav nameservers (or, worse, their webservers for the virus databases) if you run check_clamav. Yeah, I can (and will) make some reference to this in the -h output (but not everybody reads that, as we all know). And I also want to make it clear that you shouldn't rely on check_clamav to update your virus definitions but that you should have a cron job on the server running clam to do it - if check_clamav happens to update the definitions ahead of the cron job that is a bonus. So the question is do we have any place for readmes? Do we have any conventions for plugins saying "you really have to check this before you run me and after you've checked it you can create a file with this name *here* and I'll do the checks instead of returning critical all the time." Again we're back to where to put auxiliary files, in this case one called "I_understand_that_running_check_clamav_may_get_my_server_ blocked_from_updates_if_my_freshclam_setup_is_borked" (or whatever). Oh, I ought to mention, for the benefit anyone who thinks that I ought to test a known virus-free file with clamdscan and check that the file is indeed free of viruses according to clamd, that I don't need a special location for the known-good file. I can run clamdscan on the plugin itself. If clamd ever thinks that plugin is infected you have major problems. :) I know where the "good" file lives, I want to know where the "bad" file ought to live. -- Paul Allen Softflare Support From ae at op5.se Tue Jul 19 15:43:35 2005 From: ae at op5.se (Andreas Ericsson) Date: Tue Jul 19 15:43:35 2005 Subject: [Nagiosplug-devel] check_ping duplicates bug In-Reply-To: <20050719191435.GZ4744@xerus.org> References: <20050719191435.GZ4744@xerus.org> Message-ID: <42DD809B.2080109@op5.se> Christian G. Warden wrote: > There's a bug in check_ping in which it incorrectly reports the number > of duplicate packets received as the packet loss. A patch is attached > which correctly parses the last line of the ping output. It should work > for netkit-ping and iputils-ping. > This patch will almost certainly cause an identical bug on some other distribution or platform or whatnot. Try check_icmp instead. Since it does its own low-level work it doesn't have this kind of bug (which is the most common type for the check_ping plugin). > [I sent this yesterday, but I wasn't subscribed. Sorry if you get a > duplicate.] > > Christian > > > ------------------------------------------------------------------------ > > diff -ruw nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c nagios-plugins-HEAD-200507151647/plugins/check_ping.c > --- nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c 2005-05-25 07:25:55.000000000 -0700 > +++ nagios-plugins-HEAD-200507151647/plugins/check_ping.c 2005-07-18 17:27:25.634662410 -0700 > @@ -415,6 +415,8 @@ > > /* get the percent loss statistics */ > if(sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d errors, %d%% packet loss",&pl)==1 || > + sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d duplicates, %d%% packet loss", &pl) == 1 || > + sscanf(buf,"%*d packets transmitted, %*d received, +%*d duplicates, %d%% packet loss", &pl) == 1 || > sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% packet loss",&pl)==1 || > sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% loss, time",&pl)==1 || > sscanf(buf,"%*d packets transmitted, %*d received, %d%% loss, time", &pl)==1 || -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Lead Developer From cwarden at xerus.org Tue Jul 19 22:30:02 2005 From: cwarden at xerus.org (Christian G. Warden) Date: Tue Jul 19 22:30:02 2005 Subject: [Nagiosplug-devel] check_ping duplicates bug In-Reply-To: <42DD809B.2080109@op5.se> References: <20050719191435.GZ4744@xerus.org> <42DD809B.2080109@op5.se> Message-ID: <20050720043123.GX19268@xerus.org> On Wed, Jul 20, 2005 at 12:37:15AM +0200, Andreas Ericsson wrote: > Christian G. Warden wrote: > >There's a bug in check_ping in which it incorrectly reports the number > >of duplicate packets received as the packet loss. A patch is attached > >which correctly parses the last line of the ping output. It should work > >for netkit-ping and iputils-ping. > > > > This patch will almost certainly cause an identical bug on some other > distribution or platform or whatnot. Try check_icmp instead. Since it > does its own low-level work it doesn't have this kind of bug (which is > the most common type for the check_ping plugin). Thanks, Andreas. I wasn't aware of check_icmp. Christian From jmwalker at itgroundwork.com Wed Jul 20 11:00:11 2005 From: jmwalker at itgroundwork.com (John Mark Walker) Date: Wed Jul 20 11:00:11 2005 Subject: [Nagiosplug-devel] Introduction, Linux World and OSCon Message-ID: <42DE90FD.8000103@itgroundwork.com> Hello, (Sorry for cross-posting, but I'm not sure who's on the nagios-devel and nagiosplug-devel lists) My name is John Mark Walker, and I am the new developer relations person at GroundWork. I wanted to take the time to introduce myself, because I'm sure I'll be working with many of you from time to time. For the last three years, I worked at No Starch Press, a computer book publisher in San Francisco, working with various developer communities to find new book authors. By the way, you may be interested to know that No Starch is working on a Nagios book these days, and I'm sure you'll hear more about that as it gets closer to release. Before No Starch I worked at VA Research/Linux/Software first as a web developer and later as a community outreach member and finally as the SourceForge.net Foundry Manager. I got to work with a lot of great open source developers. Now that I'm at GroundWork, my first order of business has been to reserve space for a Nagios birds-of-a-feather at Linux World. I was wondering if any of you will be attending and whether you would be interested in helping out with the BoF. There's also a possibility of hosting a BoF at O'Reilly OSCon in Portland the week before. Is anyone attending that conference as well? Thanks, -- John Mark Walker Direct: 510 899 7783 Marketing Programs Manager Mobile: 408 621 7061 GroundWork Open Source Solutions E-mail: jmwalker at itgroundwork.com 2200 Powell Street, Suite 350 http://www.itgroundwork.com/ Emeryville, CA 94608 From tonvoon at mac.com Wed Jul 20 15:43:29 2005 From: tonvoon at mac.com (Ton Voon) Date: Wed Jul 20 15:43:29 2005 Subject: [Nagiosplug-devel] check_ping duplicates bug In-Reply-To: <20050719191435.GZ4744@xerus.org> References: <20050719191435.GZ4744@xerus.org> Message-ID: <8327CC0A-7546-433B-9588-D5C648DDEAD6@mac.com> Christian, Thanks for the patch. I have applied this to check_ping v1.45, so the snapshot should include this soon. Ton On 19 Jul 2005, at 20:14, Christian G. Warden wrote: > There's a bug in check_ping in which it incorrectly reports the number > of duplicate packets received as the packet loss. A patch is attached > which correctly parses the last line of the ping output. It should > work > for netkit-ping and iputils-ping. > > [I sent this yesterday, but I wasn't subscribed. Sorry if you get a > duplicate.] > > Christian > > > From cwarden at zerolag.com Wed Jul 20 21:08:12 2005 From: cwarden at zerolag.com (Christian G. Warden) Date: Wed Jul 20 21:08:12 2005 Subject: [Nagiosplug-devel] check_ping duplicates bug Message-ID: <20050719004741.GU4744@xerus.org> There's a bug in check_ping in which it incorrectly reports the number of duplicate packets received as the packet loss. A patch is attached which correctly parses the last line of the ping output. It should work for netkit-ping and iputils-ping. [Oops, I forgot the patch the first time] Christian -------------- next part -------------- diff -ruw nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c nagios-plugins-HEAD-200507151647/plugins/check_ping.c --- nagios-plugins-HEAD-200507151647.orig/plugins/check_ping.c 2005-05-25 07:25:55.000000000 -0700 +++ nagios-plugins-HEAD-200507151647/plugins/check_ping.c 2005-07-18 17:27:25.634662410 -0700 @@ -415,6 +415,8 @@ /* get the percent loss statistics */ if(sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d errors, %d%% packet loss",&pl)==1 || + sscanf(buf,"%*d packets transmitted, %*d packets received, +%*d duplicates, %d%% packet loss", &pl) == 1 || + sscanf(buf,"%*d packets transmitted, %*d received, +%*d duplicates, %d%% packet loss", &pl) == 1 || sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% packet loss",&pl)==1 || sscanf(buf,"%*d packets transmitted, %*d packets received, %d%% loss, time",&pl)==1 || sscanf(buf,"%*d packets transmitted, %*d received, %d%% loss, time", &pl)==1 || From jzhao at reedtech.com Wed Jul 20 21:08:14 2005 From: jzhao at reedtech.com (Jie Zhao) Date: Wed Jul 20 21:08:14 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1235879 ] a few bugs in check_nwstat In-Reply-To: References: Message-ID: <20050720184610.E5F504F4002@desire.netways.de> Hi SourceForge.net ...[write your message here]... Where can I download your patch? Thanks - Jie Zhao (jzhao7) ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofa q_pi1[showUid]=8483 From tonvoon at mac.com Thu Jul 21 14:28:12 2005 From: tonvoon at mac.com (Ton Voon) Date: Thu Jul 21 14:28:12 2005 Subject: [Nagiosplug-devel] Welcome to Peter Bray & delay to 1.4.1 release Message-ID: Say hello to Peter Bray. He joins the plugin team, specifically to work on the testing infrastructure which has been neglected for too long. Since this is an important addition to the core code, we'll be delaying the release of 1.4.1 by a week to allow Peter to add his changes in. I think Sean wanted to remove some other code (the np_runcmd stuff?), so this delay ties in nicely here too. Ton From noreply at sourceforge.net Fri Jul 22 02:21:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 22 02:21:08 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1219557 ] Service fails to start with error Message-ID: Bugs item #1219557, was opened at 2005-06-13 08:57 Message generated for change (Comment added) made by dragon_sdc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1219557&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Boris (dragon_sdc) Assigned to: Nobody/Anonymous (nobody) Summary: Service fails to start with error Initial Comment: Hello, I am having a problem staring NSClient on one of our Win 2003 servers. I am successfully running it on several others. When I try and start it I get "Error 1067 The process terminated unexpectedely". The event log shows the following (I have cut out all the binary data, as the last event log entry had way too much, although I can add it if necessary): --- Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 13/06/2005 Time: 09:36:58 User: N/A Computer: xxx Description: Faulting application pNSClient.exe, version 2.0.1.0, faulting module unknown, version 0.0.0.0, fault address 0x0084241d. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. --- Event Type: Information Event Source: NSClient Event Category: None Event ID: 1 Date: 13/06/2005 Time: 09:36:58 User: N/A Computer: xxx Description: NSClient is now responding to queries. --- Event Type: Error Event Source: NSClient Event Category: None Event ID: 2 Date: 13/06/2005 Time: 09:36:58 User: N/A Computer: xxx Description: NSClient CollectData: Call to retrieve counter value for failed, returning status code 4294967295. --- Event Type: Information Event Source: DrWatson Event Category: None Event ID: 4097 Date: 13/06/2005 Time: 09:36:59 User: N/A Computer: xxx Description: The application, C:\Program Files\NSClient\pNSClient.exe, generated an application error The error occurred on 06/13/2005 @ 09:36:59.174 The exception generated was c0000005 at address 0084241D () For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. ---------------------------------------------------------------------- >Comment By: Boris (dragon_sdc) Date: 2005-07-22 09:20 Message: Logged In: YES user_id=475552 Slocs, Thanks a lot. This solved my problem. :-) Sean, The reason I posted here is because the NSClient home page links to a mailing list on this project, so naturally I assumed the bugs page was related as well - sorry. Could you possibly forward this to the appropriate person (as I have no idea where to send this to) ---------------------------------------------------------------------- Comment By: j_slocs (slocs) Date: 2005-06-28 18:14 Message: Logged In: YES user_id=1304274 Found this solution at: http://www.pantz.org/blog/. NSClient will now run as a service on our Windows Server 2003 (SP1) box. W2k3 Data Execution Protection (DEP) Date/Time: 6-10-2005 9:45 PM EST I got nailed with windows 2003 server sp1's new Data Execution Protection (DEP) (stack protection) today. I was trying to install the nagios NS Client program on a server with DEP turned on. When you tried to start the nagios agent service you would get "System Error 1067 has occurred". Which means the process was aborted and windows says "The process terminated unexpectedly". To make an exception for certain programs to run without DEP you need to do the following in W2k3 SP1: Right click "My Computer" then "Properties". Click the "Advanced" tab then click the "Settings" button under the "Performance" section. Click on the "Data Execution Prevention" tab and then click the radio button "Turn on DEP for all programs and services except those I select". Then click the "Add" button and add your exe you don't want stack protection for. That problem was fun to hunt down. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-28 02:11 Message: Logged In: YES user_id=226838 hi, this doesn't look like a problem with the nagios plugins, but instead looks like a problem with the program nsclient (which is not part of the nagios-plugins project). looking through our source and documentation, i found the following link, which might be helpful: http://nsclient.ready2run.nl/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1219557&group_id=29880 From seanius at seanius.net Fri Jul 22 08:41:40 2005 From: seanius at seanius.net (sean finney) Date: Fri Jul 22 08:41:40 2005 Subject: [Nagiosplug-devel] Auxiliary files required by plugins and other questions In-Reply-To: <20050719215856.30898.qmail@mullet.softflare.net> References: <20050310112854.GA448@IPAustralia.Gov.AU> <20050719215856.30898.qmail@mullet.softflare.net> Message-ID: <20050722154033.GA6051@seanius.net> hi paul, On Tue, Jul 19, 2005 at 10:58:56PM +0100, Paul L. Allen wrote: > The first question arises from the fact that I need an auxiliary file > and I don't know of any officially-sanctioned place to put it. > Specifically, I want the eicar test 'virus' so that I can run clamdscan > on it and check that it is identified as a virus. So where to put it? > If the plugin makes it into the standard distribution then configure can > create a directory for it, such as /usr/local/nagios/share, or > /opt/nagios/share, or whatever, in a way that accommodates custom and > practise on various distros. But until that happens I'd like to know > where to put the eicar file. i'd say ditch a default place and provide a cmdline flag to specify the file. > So far this is the only plugin or plugin-to-be that I know of that > requires something like this, but I'd rather the developers make a de > jure decision rather than me set a de facto precedent. "Shove it in > libexec" or "we'll have configure create a share/plugins sub-dir if > needed" or "shove it here" or "$%#! off" are the alternative answers. > Decide amongst yourselves and let me know. yeah, there are a couple ones close to this, like check_rrd, which i believe has the rrd location specified via cmdline. i think others have been written that are more stateful and not accepted because of it. > The third question is not relevant to my check_clamav plugin-to-be but > I can see that the question might arise in the future and it is related > to my previous questions. What if a plugin needs some sort of > configuration file? What I'm thinking of is a plugin that requires > multiple options for each host it checks, so many options that it's > impractical to specify them individually in service definitions, so that > the plugin refers to the config file and uses host X service Y to pick up > the required info. We pretty much have this situation with one of the > contributed MS SQL checks which uses freetds - you specify a server in > the check and freetds looks up the details of the server. If this were > converted to some sort of native check then for people checking many > servers it would be sensible to have a configuration file similar to the > freetds one. if either freetds or ms sql has a standard configuration file format (for example, like mysql has my.cnf format files) i think providing a cmdline option to use it is fairly acceptable for situations where you don't want to specify all the info via the cmdline. > The obvious place to put such a config file would be > /usr/local/nagios/etc (can I stop mentioning 'or equivalent on exotic > flavours of *nix' yet?) but I really dislike the idea of polluting that > directory with stuff specific to individual plugins. There's no rush in > answering this one because (as far as I know) the need has yet to arise. > But maybe it would be a good idea to come up with an answer in advance > while dealing with related issues (like where do I put my eicar file). i really think the best approach is to not have a hardcoded location (most distributions providing nagios plugins use different locations anyway) and instead provide a way via the cmdline to specify said files. > The fourth question is what do I do with a readme that is essential to > the plugin? The easiest, and most sensible, and most accurate, way of i guess put it in the documentation somewhere :) sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From pla at softflare.com Fri Jul 22 09:14:23 2005 From: pla at softflare.com (Paul L. Allen) Date: Fri Jul 22 09:14:23 2005 Subject: [Nagiosplug-devel] Re: Auxiliary files required by plugins and other questions In-Reply-To: <20050722154033.GA6051@seanius.net> References: <20050310112854.GA448@IPAustralia.Gov.AU> <20050719215856.30898.qmail@mullet.softflare.net> <20050722154033.GA6051@seanius.net> Message-ID: <20050722161343.21208.qmail@mullet.softflare.net> Hi Sean > On Tue, Jul 19, 2005 at 10:58:56PM +0100, Paul L. Allen wrote: >> But until that happens I'd like to know where to put the eicar file. > > i'd say ditch a default place and provide a cmdline flag to specify the > file. I'd considered that. There are several disadvantages that I can see: 1) It bulks up the command-line. Not a big problem if you're just checking the localhost or using check_by_ssh to check remote hosts and make intelligent use of checkcommands.cfg. A slightly bigger problem with NRPE, particularly if you're using NRPE to monitor hosts behind a firewall, which means defining check_clamav_host1, etc. 2) The end user has to locate a suitable tame virus file. With a default location the tame virus could be part of the plugin tarball. 3) It's easy for somebody to omit doing, either through laziness or because they don't read the plugin help (we both know the latter happens a lot). I think checking a tame virus is a pretty essential sanity check of functionality/virus signature generation. Put it this way, if ever clamav's virus signatures got messed up in such a way that it was no longer recognizing viruses, we'd get a lot of irate phone calls. And maybe a claim for damages if a virus got through and infected somebody. But if there's no enthusiasm for a default location for files like that then I'll have to come up with some other method. >> Decide amongst yourselves and let me know. > > yeah, there are a couple ones close to this, like check_rrd, which > i believe has the rrd location specified via cmdline. i think others > have been written that are more stateful and not accepted because of it. Hmmm, does that mean that some stateful plugins that might be of use to others have been turned down simply because nobody has defined default locations for state info? >> If this were converted to some sort of native check then for people >> checking many servers it would be sensible to have a configuration file >> similar to the freetds one. > > if either freetds or ms sql has a standard configuration file format > (for example, like mysql has my.cnf format files) i think providing a > cmdline option to use it is fairly acceptable for situations where you > don't want to specify all the info via the cmdline. I didn't make myself clear enough, sorry. Currently there is a contributed script for checking MS SQL which runs freetds. Freetds has a configuration file which defines the servers it can access giving username, password, protocol version. If somebody were to come up with a self-contained MS SQL check in C to eliminate the need to install freetds then it would probably require a similar configuration file if you had lots of servers to check - it's nicer to call check_mssql -x wibble than it is to call it with -u foo -p bar --version 7.0 for dozens of hosts. Of course you could use the same location, filename and format as freetds, which makes switching a lot easier. But the location of the freetds conf file is specified when you install freetds so a plugin can only make a guess as to where the conf file is whereas freetds itself has that location compiled in. > i really think the best approach is to not have a hardcoded location > (most distributions providing nagios plugins use different locations > anyway) That's why I did suggest locations relative to the existing nagios root. That way it doesn't matter if the root is /usr/local/nagios or /opt/nagios or /home/fred/nagios or whatever. > and instead provide a way via the cmdline to specify said files. Or come up with some other devious mechanism. Which I just have. :) I'm just trying to decide if it's an elegant hack or something too evil to see the light of day. Since utils.pm ought to be present and free of viruses on any plugin installation that makes use of perl plugins (which check_clamav will be) I can use that as a known clean file. Which means I can embed eicar or similar in check_clamav itself. It does make it rather hard to mail patches around, though... >> The fourth question is what do I do with a readme that is essential to >> the plugin? The easiest, and most sensible, and most accurate, way of > > i guess put it in the documentation somewhere :) And the default directory for that is where? :) -- Paul Allen Softflare Support From pla at softflare.com Fri Jul 22 09:29:19 2005 From: pla at softflare.com (Paul L. Allen) Date: Fri Jul 22 09:29:19 2005 Subject: [Nagiosplug-devel] Re: Auxiliary files required by plugins and other questions In-Reply-To: <20050722161343.21208.qmail@mullet.softflare.net> References: <20050310112854.GA448@IPAustralia.Gov.AU> <20050719215856.30898.qmail@mullet.softflare.net> <20050722154033.GA6051@seanius.net> <20050722161343.21208.qmail@mullet.softflare.net> Message-ID: <20050722162813.27812.qmail@mullet.softflare.net> Paul L. Allen writes: > Or come up with some other devious mechanism. Which I just have. :) *Sigh* Scratch that idea. Either clamav doesn't cope with polymorphisms that include offsetting the start of the virus and putting a jump at the start of the file or it's clever enough that it knows what a valid jump would look like. I supposed that it was too much to hope that it would detect a virus embedded in an arbitrary file where it wasn't actually harmful. It looks like it will have to be the command-line switch. -- Paul Allen Softflare Support From Matthias.Eble at kaufland.de Fri Jul 22 10:04:25 2005 From: Matthias.Eble at kaufland.de (Matthias.Eble at kaufland.de) Date: Fri Jul 22 10:04:25 2005 Subject: [Nagiosplug-devel] check_radius warning bahavior [Virus checked] Message-ID: hi list, our activcard radius server doesn't allow unchanged passwords for more than 14 days. So changing the password for the monitoring user every 14 days isn't really the way we can go. Unfortunately check_radius exits with a warning state if the authentication fails. After watching the code of radiusclient, it seems to me, that rc_send_server exits with BADRESP_RC if: User/Password is incorrect, server response has invalid length there's not enough buffer space to verify the response receiving non matching seq. numbers receiving invalid reply digest So my first intention, to create a simple switch to change the return code to OK if "Auth failed" occurs, won't work since other important errors could be misinterpreted. In short, we would need an opportunity to let check_radius generate an OK state if an invalid user/password combination is given. Has anyone an idea how to solve this problem or could check if my assumption is right? Thank you very much Matthias From noreply at sourceforge.net Sun Jul 24 16:32:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 24 16:32:26 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1185704 ] New Testing Infrastructure Message-ID: Patches item #1185704, was opened at 2005-04-19 17:31 Message generated for change (Settings changed) made by illumino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Bray (illumino) >Assigned to: Peter Bray (illumino) Summary: New Testing Infrastructure Initial Comment: The attched gzip'd tar archive contains a complete replacement for the Nagios Plugins 1.4.0 testing infrastructure and all currently written test harnesses. I hope that it will meet with the approval of the Nagios Plugins Team and replace the existing infrastructure. I have provided documentation of the key functions of the infrastructure in the perl module NPTest.pm and the test harnesses themselves should provide plenty of working examples for further assisting a test harness developer. I hope this infrastructure will ease & encourage the development of test harnesses for all of the Nagios Plugins. Reasoning behind the redevelopment: * I have always had trouble with the existing infrastructure, it never seemed to create the "Cache.pm", and the testing would not function until I had manually created it. * The test harnesses themselves were out of date with respect to the Nagios Plugins 1.4.0 test results. * It was not possible to debug the existing test harness during execution, as the values returned by the execution of the plug-in were never shown to the user. Making updating of out-of-date regexps more time consuming. * Test harnesses themselves were not directly executable. Although I did manage to work around this. Attributes of the new infrastructure: * A single perl module provides the bulk of the logic. The Cache and Helper Modules are no longer required. Aside: I considered rolling all of test.pl into the module, so that could be with "perl -MNPTest -e RunAll ..." but that is not in the current implementation, but its trivial. * The workhorse function "checkCmd" supports * debugging * flexible exit status testing * graceful handling of exceptions * makes each test case more concise and easier to read * All test harnesses are directly executable. * All test harnesses are self contained. They no longer rely on the wrapper to provide test parameters. This could be seen as a negative, but not having to update the wrapper every time a new test parameter is added will simplify development. * The new test parameter cache is much more flexible, including support for default values, environment variable overrides and even scoped parameters should the need arise. I hope these attributes and the corrections to the existing test harnesses will make the contribution a worth while addition to the Nagios Plugins code base. Peter Bray Sydney, Australia LEGAL STUFF: The submission is made "AS IS" with without express or implied warranty. The contribution may be used, redistributed and/or modified under the same terms as the Nagios Plugins release. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-07-07 08:39 Message: Logged In: YES user_id=664364 Peter, Thank you for this. I will look into this over the next few days, in anticipation of including this in the 1.4.1 release in two weeks. Ton ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-06-13 00:35 Message: Logged In: YES user_id=426773 13th June : What (if anything) can I do to have this submission evaluated by the Nagios Plugins Team? ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-04-19 19:11 Message: Logged In: YES user_id=426773 Sorry, but I forgot the test.pl rewrite in the orginal archive submission Peter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 From noreply at sourceforge.net Sun Jul 24 19:11:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 24 19:11:18 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1185704 ] New Testing Infrastructure Message-ID: Patches item #1185704, was opened at 2005-04-19 17:31 Message generated for change (Comment added) made by illumino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Bray (illumino) Assigned to: Peter Bray (illumino) Summary: New Testing Infrastructure Initial Comment: The attched gzip'd tar archive contains a complete replacement for the Nagios Plugins 1.4.0 testing infrastructure and all currently written test harnesses. I hope that it will meet with the approval of the Nagios Plugins Team and replace the existing infrastructure. I have provided documentation of the key functions of the infrastructure in the perl module NPTest.pm and the test harnesses themselves should provide plenty of working examples for further assisting a test harness developer. I hope this infrastructure will ease & encourage the development of test harnesses for all of the Nagios Plugins. Reasoning behind the redevelopment: * I have always had trouble with the existing infrastructure, it never seemed to create the "Cache.pm", and the testing would not function until I had manually created it. * The test harnesses themselves were out of date with respect to the Nagios Plugins 1.4.0 test results. * It was not possible to debug the existing test harness during execution, as the values returned by the execution of the plug-in were never shown to the user. Making updating of out-of-date regexps more time consuming. * Test harnesses themselves were not directly executable. Although I did manage to work around this. Attributes of the new infrastructure: * A single perl module provides the bulk of the logic. The Cache and Helper Modules are no longer required. Aside: I considered rolling all of test.pl into the module, so that could be with "perl -MNPTest -e RunAll ..." but that is not in the current implementation, but its trivial. * The workhorse function "checkCmd" supports * debugging * flexible exit status testing * graceful handling of exceptions * makes each test case more concise and easier to read * All test harnesses are directly executable. * All test harnesses are self contained. They no longer rely on the wrapper to provide test parameters. This could be seen as a negative, but not having to update the wrapper every time a new test parameter is added will simplify development. * The new test parameter cache is much more flexible, including support for default values, environment variable overrides and even scoped parameters should the need arise. I hope these attributes and the corrections to the existing test harnesses will make the contribution a worth while addition to the Nagios Plugins code base. Peter Bray Sydney, Australia LEGAL STUFF: The submission is made "AS IS" with without express or implied warranty. The contribution may be used, redistributed and/or modified under the same terms as the Nagios Plugins release. ---------------------------------------------------------------------- >Comment By: Peter Bray (illumino) Date: 2005-07-25 12:10 Message: Logged In: YES user_id=426773 Well, as requested I have checked in the new infrastructure and tested it here (at home - as I work in a air-gap'd network at work). I don't have NetSNMP installed here, but the "gmake check" passes all other tests (after a small update to t/check_swap.t Could others please test this ASAP ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-07-25 12:10 Message: Logged In: YES user_id=426773 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-07-07 08:39 Message: Logged In: YES user_id=664364 Peter, Thank you for this. I will look into this over the next few days, in anticipation of including this in the 1.4.1 release in two weeks. Ton ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-06-13 00:35 Message: Logged In: YES user_id=426773 13th June : What (if anything) can I do to have this submission evaluated by the Nagios Plugins Team? ---------------------------------------------------------------------- Comment By: Peter Bray (illumino) Date: 2005-04-19 19:11 Message: Logged In: YES user_id=426773 Sorry, but I forgot the test.pl rewrite in the orginal archive submission Peter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1185704&group_id=29880 From tonvoon at mac.com Mon Jul 25 06:28:04 2005 From: tonvoon at mac.com (Ton Voon) Date: Mon Jul 25 06:28:04 2005 Subject: [Nagiosplug-devel] Welcome to Peter Bray & delay to 1.4.1 release In-Reply-To: References: Message-ID: <484F5821-44DC-4451-998E-1EB6961EF524@mac.com> This is a call for some testing! Peter has committed the new testing infrastructure to CVS HEAD and we'd like reports of whether the tests pass for you or not. On 21 Jul 2005, at 22:26, Ton Voon wrote: > Say hello to Peter Bray. He joins the plugin team, specifically to > work on the testing infrastructure which has been neglected for too > long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rouven.homann at cimt-ag.de Mon Jul 25 06:35:23 2005 From: rouven.homann at cimt-ag.de (Rouven Homann) Date: Mon Jul 25 06:35:23 2005 Subject: [Nagiosplug-devel] Plugin Release 1.4.1 frozen? Message-ID: Hi, am i to late to submit some new plugins for the next release? I just made 1-2 new and some small improvements to older ones. Best Regards, Rouven Homann cimt AG Burchardstr. 17 20095 Hamburg Tel.: +49.40.53302-0 Fax: -22 email: rouven.homann at cimt-ag.de http://www.cimt-ag.de ________________________________ Von: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net] Im Auftrag von Ton Voon Gesendet: Montag, 25. Juli 2005 15:27 An: Ton Voon Cc: NagiosPlug Devel Betreff: Re: [Nagiosplug-devel] Welcome to Peter Bray & delay to 1.4.1 release This is a call for some testing! Peter has committed the new testing infrastructure to CVS HEAD and we'd like reports of whether the tests pass for you or not. On 21 Jul 2005, at 22:26, Ton Voon wrote: Say hello to Peter Bray. He joins the plugin team, specifically to work on the testing infrastructure which has been neglected for too long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnizhnikov at aval.ua Mon Jul 25 07:34:36 2005 From: dnizhnikov at aval.ua (Nizhnikov Dmitry) Date: Mon Jul 25 07:34:36 2005 Subject: [Nagiosplug-devel] question about check_ping plugin Message-ID: <42E4F748.7070502@aval.ua> Good day. I'm try running check_ping plugin and obtain next mistake: libexec#./check_ping -H localhost -w 1000.0,80% -c 2000.0,100% /bin/ping -n -U -w 15 -c 5 localhost CRITICAL - Could not interpret output from ping command run as nagios user and root too. Why that may be. Thank you. From tonvoon at mac.com Mon Jul 25 11:46:04 2005 From: tonvoon at mac.com (Ton Voon) Date: Mon Jul 25 11:46:04 2005 Subject: [Nagiosplug-devel] question about check_ping plugin In-Reply-To: <42E4F748.7070502@aval.ua> References: <42E4F748.7070502@aval.ua> Message-ID: <5E9BBCB6-3239-4699-8232-0C92DEC293A0@mac.com> Dmitry, This should go to the nagiosplug-help mailing list. Also, you are missing version information and your OS. However, I know there has been a fix recently for check_ping for Red Hat 9, as well as some other internationalisation fixes. Please try the CVS snapshot at http://nagiosplug.sf.net/snapshot Ton On 25 Jul 2005, at 15:29, Nizhnikov Dmitry wrote: > Good day. I'm try running check_ping plugin and obtain next mistake: > > libexec#./check_ping -H localhost -w 1000.0,80% -c 2000.0,100% > /bin/ping -n -U -w 15 -c 5 localhost > CRITICAL - Could not interpret output from ping command > > run as nagios user and root too. > Why that may be. Thank you. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug- > devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/ > nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. ::: Messages without supporting info will risk being sent > to /dev/null > From tonvoon at mac.com Mon Jul 25 11:47:10 2005 From: tonvoon at mac.com (Ton Voon) Date: Mon Jul 25 11:47:10 2005 Subject: [Nagiosplug-devel] Plugin Release 1.4.1 frozen? In-Reply-To: References: Message-ID: <08813DF2-D75E-406E-BD1A-66E5E7A43AE5@mac.com> Rouven, The new plugins are probably outside of scope for 1.4.1. However, "small improvements" are welcome. Can you raise a tracker item at http://sf.net/projects/nagiosplug and send an email here too and we'll evaluate their inclusion. Ton On 25 Jul 2005, at 14:34, Rouven Homann wrote: > Hi, > am i to late to submit some new plugins for the next release? I > just made 1-2 new and some small improvements to older ones. > > Best Regards, > > Rouven Homann > > cimt AG > Burchardstr. 17 > 20095 Hamburg > Tel.: +49.40.53302-0 Fax: -22 > > email: rouven.homann at cimt-ag.de > http://www.cimt-ag.de > > > > Von: nagiosplug-devel-admin at lists.sourceforge.net > [mailto:nagiosplug-devel-admin at lists.sourceforge.net] Im Auftrag > von Ton Voon > Gesendet: Montag, 25. Juli 2005 15:27 > An: Ton Voon > Cc: NagiosPlug Devel > Betreff: Re: [Nagiosplug-devel] Welcome to Peter Bray & delay to > 1.4.1 release > > > This is a call for some testing! Peter has committed the new > testing infrastructure to CVS HEAD and we'd like reports of whether > the tests pass for you or not. > > > On 21 Jul 2005, at 22:26, Ton Voon wrote: > >> Say hello to Peter Bray. He joins the plugin team, specifically to >> work on the testing infrastructure which has been neglected for >> too long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Jul 25 23:02:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 25 23:02:05 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1244978 ] check_rpc with dynamic rpc list Message-ID: New Plugins item #1244978, was opened at 2005-07-26 08:01 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=1244978&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rouven (rhomann) Assigned to: Nobody/Anonymous (nobody) Summary: check_rpc with dynamic rpc list Initial Comment: I've modified the original plugin to get the rpc list dynamically by the /etc/rpc file and not hardcoded within the plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1244978&group_id=29880 From rouven.homann at cimt-ag.de Mon Jul 25 23:02:06 2005 From: rouven.homann at cimt-ag.de (Rouven Homann) Date: Mon Jul 25 23:02:06 2005 Subject: [Nagiosplug-devel] check_rpc (mod) Message-ID: I've modified the original plugin to get the rpc list dynamically by the /etc/rpc file and not hardcoded within the plugin. Best regards, Rouven Homann cimt AG Burchardstr. 17 20095 Hamburg Tel.: +49.40.53302-0 Fax: -22 email: rouven.homann at cimt-ag.de http://www.cimt-ag.de -------------- next part -------------- A non-text attachment was scrubbed... Name: check_rpc.gz Type: application/x-gzip Size: 2784 bytes Desc: check_rpc.gz URL: From rouven.homann at cimt-ag.de Mon Jul 25 23:10:05 2005 From: rouven.homann at cimt-ag.de (Rouven Homann) Date: Mon Jul 25 23:10:05 2005 Subject: [Nagiosplug-devel] Check_mem (linux) Message-ID: This is v1.4 made by Garrett Honeycutt and me, Rouven Homann. This perl linux plugin checks the percentage of memory usage with performance data. Best Regards, Rouven Homann cimt AG Burchardstr. 17 20095 Hamburg Tel.: +49.40.53302-0 Fax: -22 email: rouven.homann at cimt-ag.de http://www.cimt-ag.de -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mem.gz Type: application/x-gzip Size: 1374 bytes Desc: check_mem.gz URL: From noreply at sourceforge.net Mon Jul 25 23:11:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 25 23:11:06 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1244983 ] check_mem Message-ID: New Plugins item #1244983, was opened at 2005-07-26 08:10 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=1244983&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rouven (rhomann) Assigned to: Nobody/Anonymous (nobody) Summary: check_mem Initial Comment: This is v1.4 made by Garrett Honeycutt and me, Rouven Homann. This perl linux plugin checks the percentage of memory usage with performance data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1244983&group_id=29880 From eric at eb.homelinux.org Tue Jul 26 07:54:05 2005 From: eric at eb.homelinux.org (BOLLENGIER Eric) Date: Tue Jul 26 07:54:05 2005 Subject: [Nagiosplug-devel] Check_mem (linux) In-Reply-To: References: Message-ID: <200507261009.02711.eric@eb.homelinux.org> Hi, Sorry, but your sys_stats function is very ugly... you launch 7 sub process to get 2 values. (you can do the same with only one call to free -mt) > chomp($mem_total = `free -mt | grep Mem | awk '{print \$2}'`); > chomp($mem_used = `free -mt | grep cache | tail -1 | awk '{print \$3}'`); There more than way to do... Regards Le Tuesday 26 July 2005 08:09, Rouven Homann a ?crit?: > This is v1.4 made by Garrett Honeycutt and me, Rouven Homann. This perl > linux plugin checks the percentage of memory usage with performance > data. > > > Best Regards, > > Rouven Homann > > cimt AG > Burchardstr. 17 > 20095 Hamburg > Tel.: +49.40.53302-0 Fax: -22 > > email: rouven.homann at cimt-ag.de > http://www.cimt-ag.de From rouven.homann at cimt-ag.de Wed Jul 27 01:57:05 2005 From: rouven.homann at cimt-ag.de (Rouven Homann) Date: Wed Jul 27 01:57:05 2005 Subject: AW: [Nagiosplug-devel] Check_mem (linux) Message-ID: Ok, thanks for the hint. I fixed it to call only one sub process instead of 7. Version is now 1.5 and attached. Mit freundlichem Gru? Rouven Homann cimt AG Burchardstr. 17 20095 Hamburg Tel.: +49.40.53302-0 Fax: -22 email: rouven.homann at cimt-ag.de http://www.cimt-ag.de -----Urspr?ngliche Nachricht----- Von: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net] Im Auftrag von BOLLENGIER Eric Gesendet: Dienstag, 26. Juli 2005 10:09 An: Rouven Homann Cc: nagiosplug-devel at lists.sourceforge.net Betreff: Re: [Nagiosplug-devel] Check_mem (linux) Hi, Sorry, but your sys_stats function is very ugly... you launch 7 sub process to get 2 values. (you can do the same with only one call to free -mt) > chomp($mem_total = `free -mt | grep Mem | awk '{print \$2}'`); > chomp($mem_used = `free -mt | grep cache | tail -1 | awk '{print > \$3}'`); There more than way to do... Regards Le Tuesday 26 July 2005 08:09, Rouven Homann a ?crit?: > This is v1.4 made by Garrett Honeycutt and me, Rouven Homann. This > perl linux plugin checks the percentage of memory usage with > performance data. > > > Best Regards, > > Rouven Homann > > cimt AG > Burchardstr. 17 > 20095 Hamburg > Tel.: +49.40.53302-0 Fax: -22 > > email: rouven.homann at cimt-ag.de > http://www.cimt-ag.de ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mem.gz Type: application/x-gzip Size: 1417 bytes Desc: check_mem.gz URL: From noreply at sourceforge.net Wed Jul 27 02:01:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 27 02:01:08 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1244983 ] check_mem Message-ID: New Plugins item #1244983, was opened at 2005-07-26 08:10 Message generated for change (Comment added) made by rhomann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1244983&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rouven (rhomann) Assigned to: Nobody/Anonymous (nobody) Summary: check_mem Initial Comment: This is v1.4 made by Garrett Honeycutt and me, Rouven Homann. This perl linux plugin checks the percentage of memory usage with performance data. ---------------------------------------------------------------------- >Comment By: rouven (rhomann) Date: 2005-07-27 11:00 Message: Logged In: YES user_id=1304023 New version with small performance tweaks as described in mailing list. thanks to Eric Bollengier for the request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1244983&group_id=29880 From noreply at sourceforge.net Wed Jul 27 02:24:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 27 02:24:13 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-1245831 ] check_postfix Message-ID: New Plugins item #1245831, was opened at 2005-07-27 11: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=1245831&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Vigot (nicopc) Assigned to: Nobody/Anonymous (nobody) Summary: check_postfix Initial Comment: This plugin check the size of the mail queue and the age of the messages. Contrary to the others plugins of monitoring for Postfix, this one is written in C. It can parse 5 000 mails in one second. This plugin has two new options : -W (age limit warning) -C (age limit critical) When one or more mails are older than an age limit, an alarm is set off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=1245831&group_id=29880 From noreply at sourceforge.net Wed Jul 27 06:01:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 27 06:01:07 2005 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-778477 ] check_frontpage Message-ID: New Plugins item #778477, was opened at 2003-07-27 15:46 Message generated for change (Comment added) made by kyrian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=778477&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Kev Green (kyrian) Assigned to: Stanley Hopcroft (stanleyhopcroft) Summary: check_frontpage Initial Comment: In anger at that particular bane of unix sysadmins lives, or perhaps my own willingness to install it, the other day I wrote a nagios plugin to monitor whether frontpage appeared to be working on a given site. Do with it as you will, but I accept no responsibility for its failing to allow you to sleep soundly at night, save you from tearing your hair out, etc. Obviously FrontPage remains a trademark/copyright/whatever of Microsoft, and the fact that this plugin has ever proved necessary as a result of various misconfigurations and website migrations from server to server is not intended as any kind of indicator for or against the quality of Microsoft's software. ---------------------------------------------------------------------- >Comment By: Kev Green (kyrian) Date: 2005-07-27 14:00 Message: Logged In: YES user_id=99923 In order to make my life easier, I've migrated any future development on this thing to http://www.orenet.co.uk/opensource/. If there's anything added, it'll be published there first, and maybe here later, when I get around to it. I'll still be checking sourceforge redirected email, and so on, but a quick tar -czvf && scp is much easier than the sourceforge frontend ;-) Although I have added a GPL header, and attached the LICENSE file into a tarball inline with Nagios licensing to this and any future versions, this should not effect the use of it within Nagios in any way, and provides a degree of protection for me. The version in question with GPL stuff attached is added with this comment as a .tar.gz. K. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-27 04:09 Message: Logged In: YES user_id=395628 Thank you for the plugin and sorry that it has taken so long to acknowledge. Plugin should be in /contrib in the next 1-2 hours ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-06-22 18:48 Message: Logged In: YES user_id=99923 Just a bit more verbose. ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-06-22 18:48 Message: Logged In: YES user_id=99923 Just a bit more verbose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=778477&group_id=29880 From tonvoon at mac.com Thu Jul 28 14:56:36 2005 From: tonvoon at mac.com (Ton Voon) Date: Thu Jul 28 14:56:36 2005 Subject: [Nagiosplug-devel] Welcome to Peter Bray & delay to 1.4.1 release In-Reply-To: <484F5821-44DC-4451-998E-1EB6961EF524@mac.com> References: <484F5821-44DC-4451-998E-1EB6961EF524@mac.com> Message-ID: <9C1E3914-7395-44A3-8FFE-D696297A710A@mac.com> Unfortunately due to personal reasons, the 1.4.1 release will be delayed another week until next Thursday. On 25 Jul 2005, at 14:27, Ton Voon wrote: > > This is a call for some testing! Peter has committed the new > testing infrastructure to CVS HEAD and we'd like reports of whether > the tests pass for you or not. > > > On 21 Jul 2005, at 22:26, Ton Voon wrote: > >> Say hello to Peter Bray. He joins the plugin team, specifically to >> work on the testing infrastructure which has been neglected for >> too long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.Eble at kaufland.de Fri Jul 29 05:57:46 2005 From: Matthias.Eble at kaufland.de (Matthias.Eble at kaufland.de) Date: Fri Jul 29 05:57:46 2005 Subject: [Nagiosplug-devel] FW: check_radius warning bahavior [Virus checked] Message-ID: ----- Weitergeleitet von Matthias Eble/IS/STIFTUNG/LIDL-SCHWARZ am 29.07.2005 14:54 ----- Matthias Eble/IS/STIFTUNG/LIDL-SCHWARZ schrieb am 22.07.2005 19:02:47: > hi list, > > our activcard radius server doesn't allow unchanged passwords for > more than 14 days. So changing the password for the monitoring user > every 14 days > isn't really the way we can go. Unfortunately check_radius exits > with a warning state if the authentication fails. > > After watching the code of radiusclient, it seems to me, that > rc_send_server exits with BADRESP_RC if: > User/Password is incorrect, > server response has invalid length > there's not enough buffer space to verify the response > receiving non matching seq. numbers > receiving invalid reply digest > > So my first intention, to create a simple switch to change the > return code to OK if "Auth failed" occurs, won't work since > other important errors could be misinterpreted. In short, we would > need an opportunity to let check_radius generate an OK state > if an invalid user/password combination is given. > > Has anyone an idea how to solve this problem or could check if my > assumption is right? > > Thank you very much > Matthias Hi all, has anzbody any hints on this one? thanks a lot From vnovoselskiy at itgroundwork.com Fri Jul 29 13:35:03 2005 From: vnovoselskiy at itgroundwork.com (Vladimir Novoselskiy) Date: Fri Jul 29 13:35:03 2005 Subject: [Nagiosplug-devel] check_if.sh Added Linux Support Message-ID: <20050729202935.1E2244F4002@desire.netways.de> Hi list, I'm new here... I'm looking for check_if plugins and notice: it currently only supported on Solaris, so i added few lines and now it works on Linux.If any one intresed... i will be glad to post it here... Please let me know what is the right way to do so. Regards, - Vladimir Novoselskiy (Vladimir) ----------------------- The mailing list archive is found here: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html