From jpotter at codepuppy.com Thu Jul 5 15:25:38 2007 From: jpotter at codepuppy.com (Jeff Potter) Date: Thu, 5 Jul 2007 09:25:38 -0400 Subject: [Nagiosplug-devel] bug in nagios-plugins 1.4.9's check_linux_raid.pl Message-ID: <6495BD53-2CE0-40C4-B459-430E9B2658EA@codepuppy.com> Hi Guys, Thanks for a great tool -- nagios is amazing. In v1.4.9, file "check_linux_raid.pl" has a very simple bug that prevents it from running at all. Trying to run it as-is gives: Bareword "utils" not allowed while "strict subs" in use at /usr/lib/ nagios/plugins/contrib/check_linux_raid.pl line 26. Bareword "pm" not allowed while "strict subs" in use at /usr/lib/ nagios/plugins/contrib/check_linux_raid.pl line 26. BEGIN not safe after errors--compilation aborted at /usr/lib/nagios/ plugins/contrib/check_linux_raid.pl line 27. I think it just needs quote marks around the use statement -- here is a diff that fixed it: 26c26 < use lib 'utils.pm'; --- > use lib utils.pm; best, Jeff From Ingo.Pangritz at SecurIntegration.de Thu Jul 5 15:44:19 2007 From: Ingo.Pangritz at SecurIntegration.de (Ingo Pangritz) Date: Thu, 5 Jul 2007 15:44:19 +0200 Subject: [Nagiosplug-devel] Feature suggestion for check_proc Message-ID: <20070705134355.F2CE3112CC@mail.SecurIntegration.de> Dear nagios plugin development team, we want to use our nagios installation to monitor the available RAM for use within our VMWare Server installations. If the check_proc plugin would allow for a cumulative check on used memory for ALL processes of ONE user, it would offer the requested functionality. Example situation: User vmware has two processes: 1. VM1 with RSS of 1500000 2. VM2 with RSS of 1500000 In total user vmware uses RSS of 3000000. If the vmware server has 3,5GB RAM for its internal use, we would like to have a warning at let's say 2,5GB used for VMs and a critical at 3,2GB. The check command would be something like: check_procs -w 2500000 -c 3000000 --metric=RSS -u vmware -X Were X is the new option to use cumulative checks instead per process check. Is this a feature that could be implemented for this plugin? Or is there another plugin to do the same thing? Mit freundlichen Gr??en / Kind regards, Ingo Pangritz ______________________________ SecurIntegration GmbH Ingo Pangritz Security Consultant R?srather Str. 702 51107 K?ln Fon: +49 (221) 71 99 00-64 Fax: +49 (221) 71 99 00-23 http://www.SecurIntegration.de Amtsgericht K?ln HRB 35063 Gesch?ftsf?hrer: Guido Schneider SecurIntegration ist SAP Special Expertise Partner GRC From ton.voon at altinity.com Mon Jul 9 17:33:22 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 9 Jul 2007 16:33:22 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com> <2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> Message-ID: <5308DA16-7FE3-417A-BE69-A3862B011BDC@altinity.com> On 8 Jun 2007, at 08:20, Ton Voon wrote: > I'll spend some time next week working through some of the ancillary > tools and will let you know when those work. Just to let you know I've updated the test SVN repo with the latest CVS code. I've also updated the snapshot and the dev guidelines generation code to work against SVN instead of CVS (though I haven't committed yet - I've got local copies of them for now and I've got a note to do this when the SVN goes live). I've still got a task against Tinderbox to work against SVN. Is there anything else that is delaying the switchover (apart from me?) Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From Thomas at zango.com Mon Jul 9 18:08:36 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 9 Jul 2007 09:08:36 -0700 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <5308DA16-7FE3-417A-BE69-A3862B011BDC@altinity.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com><2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <5308DA16-7FE3-417A-BE69-A3862B011BDC@altinity.com> Message-ID: <804160344192334BB21922E8082EA6C0A7145B@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Ton Voon > Sent: July 9, 2007 11:33 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Switching to svn > > > On 8 Jun 2007, at 08:20, Ton Voon wrote: > > I'll spend some time next week working through some of the ancillary > > tools and will let you know when those work. > > Just to let you know I've updated the test SVN repo with the latest > CVS code. I've also updated the snapshot and the dev guidelines > generation code to work against SVN instead of CVS (though I haven't > committed yet - I've got local copies of them for now and I've got a > note to do this when the SVN goes live). > > I've still got a task against Tinderbox to work against SVN. Is there > anything else that is delaying the switchover (apart from me?) I have to change my tinderbox script to update from SVN but that's only a one word change :) I'm ready when you are. Once we're done with the switch I suggest that we put a huge ASCII warning message (Ie. using something like http://www.network-science.de/ascii/; I got nice results with "WARNING!!!" and font banner3) at the beginning and end of the configure script in the CVS tree. Users that already have their checkout will notice right away that something is wrong, and we could put the SVN url so they won't have to look it up from the web. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ton.voon at altinity.com Mon Jul 9 18:14:47 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 9 Jul 2007 17:14:47 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <804160344192334BB21922E8082EA6C0A7145B@seaex01.180solutions.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com><2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <5308DA16-7FE3-417A-BE69-A3862B011BDC@altinity.com> <804160344192334BB21922E8082EA6C0A7145B@seaex01.180solutions.com> Message-ID: <9389BF5E-E92A-4415-A31C-1633C6275507@altinity.com> Hi Thomas, On 9 Jul 2007, at 17:08, Thomas Guyot-Sionnest wrote: > nce we're done with the switch I suggest that we put a huge ASCII > warning > message (Ie. using something like http://www.network-science.de/ > ascii/; I > got nice results with "WARNING!!!" and font banner3) at the > beginning and > end of the configure script in the CVS tree. Users that already > have their > checkout will notice right away that something is wrong, and we > could put > the SVN url so they won't have to look it up from the web. Good idea. I've got it added in my notes for switchover time. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From dave.worthy at hp.com Mon Jul 9 21:54:10 2007 From: dave.worthy at hp.com (Dave Worthy) Date: Mon, 09 Jul 2007 15:54:10 -0400 Subject: [Nagiosplug-devel] check_ldaps plugin help needed Message-ID: <46929262.7070209@hp.com> I am running nagios 1.2 on a 2.4.21-27.ELsmp i686 host without trouble. We are needing to migrate off that host and to a host running 2.6.9-34.ELsmp x86_64 host. I'd like to upgrade, but time won't allow currently, so I'm doing a straight port of 1.2 onto the new host for the time being. My issue is that the plugin check_ldaps works on the old host, but not the new one. It gets even more strange. I can get the command line, any user, to run check_ldaps successfully, but the nagios binary continues to launch failed check_ldaps connections. I've updated /etc/openldap/ldap.conf to include TLS_CACERT line to indicate location of generic cert to use. I however don't have much knowledge about the ldap innards making this extra difficult to troubleshoot. What I do know is that any user on new host can run check_ldaps and it works, but it shows up as failed in the new nagios browser. The nagios binary has to be started as root Ideas? Dave I've also posted here, so hope I'm not double posting: http://www.meulie.net/portal_plugins/forum/forum_viewtopic.php?8777 From bharani at nextgen.co.in Tue Jul 10 18:08:06 2007 From: bharani at nextgen.co.in (P.Bharanitharan) Date: Tue, 10 Jul 2007 21:38:06 +0530 Subject: [Nagiosplug-devel] Problem Message-ID: <4693AEE6.4070000@nextgen.co.in> Dear Support, We have installed nagios and running. I have checked the plugin "check_mailq" . Its checking only localhost. There is no option to check the remote mail server's mailq. We want to check the remote mail server's mailq. Kindly give advice for this option. Regards, Bharani. From andurin at process-zero.de Tue Jul 10 19:28:57 2007 From: andurin at process-zero.de (=?ISO-8859-1?Q?Hendrik_B=E4cker?=) Date: Tue, 10 Jul 2007 19:28:57 +0200 Subject: [Nagiosplug-devel] Problem In-Reply-To: <4693AEE6.4070000@nextgen.co.in> References: <4693AEE6.4070000@nextgen.co.in> Message-ID: <4693C1D9.2060504@process-zero.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Baharani, this is quiet not a developing issue, I think next time the nagiosplug-users list is better for something like this. You can use NRPE (www.nagios.org) or check_by_ssh for this things. In both ways you start a "local" plugin to connect to a server (nrpe daemon or a usual ssh daemon) to ask them to execute a local plugin and return the states back to your nagios host. For further information try to google for NRPE or check_by_ssh and read the docs. Regards, Hendrik P.Bharanitharan schrieb: > Dear Support, > > We have installed nagios and running. I have checked the plugin > "check_mailq" . > > Its checking only localhost. There is no option to check the remote mail > server's mailq. > > We want to check the remote mail server's mailq. > > Kindly give advice for this option. > > Regards, > Bharani. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) iD8DBQFGk8HZlI0PwfxLQjkRAqxNAJ9MO0F5bBpXMc6GoBg7alne/6a72gCfTAKY E5JLbHKcdlonBVxOWJBIkns= =i9O0 -----END PGP SIGNATURE----- From Thomas at zango.com Tue Jul 10 19:31:26 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 10 Jul 2007 10:31:26 -0700 Subject: [Nagiosplug-devel] Problem In-Reply-To: <4693AEE6.4070000@nextgen.co.in> References: <4693AEE6.4070000@nextgen.co.in> Message-ID: <804160344192334BB21922E8082EA6C0A71772@seaex01.180solutions.com> You have to use something like NRPE to run plugins on remote hosts. Plugins are simply local programs run by Nagios (with specific return code and output format though). When you want a plugin to run remotely you have to run a local program (ex.: check_nrpe) that will forward the request to a remote server (ex.: using the NRPE daemon on a remote server) to get the check run. You can also do the reverse and have remote programs send Passive results to Nagios using NSCA. Read the Nagios documentation about Passive checks if you're interested in that. Thomas > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of P.Bharanitharan > Sent: July 10, 2007 12:08 > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Problem > > Dear Support, > > We have installed nagios and running. I have checked the plugin > "check_mailq" . > > Its checking only localhost. There is no option to check the remote mail > server's mailq. > > We want to check the remote mail server's mailq. > > Kindly give advice for this option. > > Regards, > Bharani. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug- > devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug- > devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Tue Jul 10 22:53:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 13:53:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636 Message-ID: Bugs item #1466426, was opened at 2006-04-07 18:18 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: John Rouillard (rouilj) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4.2 check_ldaps doesn't default to port 636 Initial Comment: check_ldaps in the 1.4.2 release doesn't automatically try to conect to port 636. It uses port 389 like check_ldap does. -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-10 22:53 Message: Logged In: YES user_id=1694341 Originator: NO John, I'm closing this item now. If you can find some time to test the latest version, please post a comment to the closed tracker item (I guess this should work). Best Regards Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-20 13:15 Message: Logged In: YES user_id=1694341 Originator: NO I commited Holger's proposals a couple of minutes ago. I hope, i didn't break backward compatibility, but I'm quite sure everything should work as expected. The --ssl and --starttls arguments are now valid for check_ldap, too. Not only to check_ldaps. John, it would be great if you could checkout and try the latest cvs version. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 19:02 Message: Logged In: YES user_id=759506 Originator: NO Personally, I'd find "--old-ldaps" a bit confusing, too. I'd suggest: 1) By default, keep the current behaviour for backwards compatibility. 2) Introduce two new flags: - "-T/--starttls", which forces, well, STARTTLS. - "-S/--ssl", which forces "SSL on connect" and sets the default port to 636 (even nicer would be to use getservbyname(3), but IIRC we do that nowhere, so that's a different story). If "--ssl" seems too ambiguous, it could be called "--ssl-on-connect" or so, but I'd prefer "--ssl" as "check_http", "check_tcp" and possibly other plugins use it. If either option is used, the plugin doesn't care about argv[0] nor about the specified port. If neither option is used, you get the current behaviour. 3) Document the default behaviour, and maybe also mark it as deprecated: "If this plugin is called via 'check_ldaps', 'STARTTLS' will be used, unless --port=636 is specified, in which case 'SSL on connect' will be used. This behaviour is deprecated, please use 'check_ldap' with the '--starttls' or '--ssl' flags instead." Just my 2?, Holger ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 18:30 Message: Logged In: YES user_id=1694341 Originator: NO For the records: wikipedia claims: >A common alternate method of securing LDAP communication is using an SSL tunnel. This is >denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP over SSL >is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never >standardized in any formal specification. This usage has been deprecated along with >LDAPv2, which was officially retired in 2003 so if i got it right, starttls starts a tls connection on port 389, ssl on connect uses ssl wrapped around normal ldap since tls was not included in ldap that time I'd say these steps need to be done? - introduce an argument --old-ldaps to force direct connection to 636 - keep default behaviour if -p 636 is given -> ldaps - set default port to 636 if --old-ldaps is defined - introduce default behaviour (startTLS) in --help what do you think? matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:48 Message: Logged In: YES user_id=1694341 Originator: NO Today i have read about a user expecting ldaps to connect to 636 in a forum. But using the direct connection seems to be deprecated according to http://www.openldap.org/lists/openldap-software/200409/msg00617.html So startTLS should be the right way to make it. I couldn't find out if ldap_start_tls_s() eventually makes a secure connect after the query on the default port. IMO it should do so. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2007-06-19 17:38 Message: Logged In: YES user_id=707416 Originator: YES I checked the code I used to compile the check_ldaps binary. It matches the startls stuff that hweiss detailed. I agree with psychotrahe that check_ldaps should use port 636 and not 389 with startTLS. At the very least it has to be documented. I can verify the startTLS error: /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10 Could not init startTLS at port 389! when running against a non-TLS enabled server. I am starting to think that my port 389 test that worked was using startTLS. So my assertion: > Sorry this is a valid bug. I saw one host work, but that > system (incorrectly) runs both ldap and ldaps so it > worked against the ldap port without ssl. should have read: ... worked against the ldap port *with* ssl, but I expected it to use ldaps protocol and not ldap with startTLS. -- rouilj ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Holger, you are right. I din't know about the startTLS functionality. IMO check_ldaps lets people expect a to be connecting to a secure port. startTLS seems to be intended to be used on a non secure port. It should imo therefore rather be an option to check_ldap instead of default behaviour for check_ldaps. I also couldn't find a hint that clarifies what check_ldaps was intended to do. However since we don't want to break backward compatibility, we should as you said add some lines to --help. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-06-19 16:29 Message: Logged In: YES user_id=759506 Originator: NO rouilj: | I saw one host work, but that system (incorrectly) runs both ldap | and ldaps so it worked against the ldap port without ssl. Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? >From a quick look at the code, if you call "check_ldaps" without specifying the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL error if that fails (see check_ldap.c:139-181 from the 1.4.9 release). psychotrahe: AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to trying STARTTLS, unless "--port=636" was specified, in which case it tries LDAPS (that is, "SSL on connect"). The change you suggested would make the plugin behave the other way round, so I guess this would then confuse the STARTTLS users instead of the LDAPS users :-) More importantly, it would break existing configurations which don't specify the --port explicitely. IMO, this is yet another example that such magic (guessing connection protocols from ports or the other way round) is almost always a bad idea. However, for backwards compatibility, we should probably keep the existing magic by default. But maybe we should add options to explicitely request "SSL on connect" or STARTTLS regardless of the port. And in any case, we should properly document the behaviour in the --help output. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=1694341 Originator: NO will fix this tonight.. there should be a warning if you connect to the ldaps port and don't get a ldaps session. So changing the port to 636 if argv[0] is "check_ldaps" will fix this, too. ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:56 Message: Logged In: YES user_id=707416 Sorry this is a valid bug. I saw one host work, but that system (incorrectly) runs both ldap and ldaps so it worked against the ldap port without ssl. So that may be another bug, it should fail if it doesn't get an encrypted session. -- rouilj ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2006-04-07 18:51 Message: Logged In: YES user_id=707416 Never mind. User error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880 From noreply at sourceforge.net Tue Jul 10 22:54:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jul 2007 13:54:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1386144 ] Bug in check_mrtg plug-in Message-ID: Bugs item #1386144, was opened at 2005-12-20 14:16 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: James Turnbull (kartar) Assigned to: Matthias Eble (psychotrahe) Summary: Bug in check_mrtg plug-in Initial Comment: I get a segmentation fault when I run the check_mrtg plugin on Red Hat Linux Enterprise 4. The plug-in version is 1.4.2. I poked into the code of the plug-in and noticed this line: int expire_minutes = 0; I changed it to: int expire_minutes = -1; I recompiled the code and the segementation fault was corrected. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 21:29 Message: Logged In: YES user_id=1694341 Originator: NO Thanks for your reply James, it has really long time gone. Is anyone of the devs running a rhel4 server with mrtg to check this? If there are any other bugs concerning rhel4, i'll probably set up a vmware image. If not, i'll close it in the next days. Again, thanks for your report. ---------------------------------------------------------------------- Comment By: James Turnbull (kartar) Date: 2007-06-11 15:46 Message: Logged In: YES user_id=1364759 Originator: YES Matthias Doesn't seem to but I only have RHEL 5 to test it on - may behave differently on RHEL 4. I know it's odd - I have no idea why the change impacted it either - but it worked after that change. I could find nothing else in the compile environment to explain it working. I am trying to rack my brains as to what triggered me to change expire_minutes but *shrugs* it was over a year ago. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-11 10:16 Message: Logged In: YES user_id=1694341 Originator: NO Announced pending state by sending emails to the participants. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-06-05 14:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, could you please tell us if this problem persists in the latest version (1.4.9 or cvs snapshot)? If so, we need the command line you used (i guess verbose output isn't possible with check_mrtg). I watched the source and can, up to now, hardly imagine how setting expire_minutes to -1 can prevent the plugin from segfaulting. We'll see.. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1386144&group_id=29880 From noreply at sourceforge.net Wed Jul 11 17:38:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 08:38:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1218235 ] unicast support for check_dhcp Message-ID: Patches item #1218235, was opened at 2005-06-10 15:49 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1218235&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Ericsson (ageric) >Assigned to: Holger Weiss (hweiss) Summary: unicast support for check_dhcp Initial Comment: Heiti Ernits, an employee at Boras Kommun has added unicast support to the check_dchp plugin. I reworked it a bit to be more general and removed the hardcoded stuff. I also added detection of ones own IP-address to use for the return route. It gives check_dhcp the ability to mimic a dhcp-relay server, which use unicast when talking to the server and therefore can be used to query dhcp-servers on separate and even remote subnets. There are routing rules ofcourse. Querying a dhcp-server with ip 192.168.0.4 on subnet A from 192.168.0.3 on subnet B won't work, as the dhcp-server then will redirect its responses to a host on the same subnet (which may or may not exist) rather than the correct server. Sane networks probably won't suffer from it, and it may be possible to work around it (although I can't imagine how). Apply with patch -p1 < nagiosplug-check_dhcp-unicast.diff ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-07-11 17:38 Message: Logged In: YES user_id=759506 Originator: NO Thank you very much. I hope I'll find the time to look into the patch and test it Really Soon Now[tm]. Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1218235&group_id=29880 From dave.worthy at hp.com Wed Jul 11 12:53:09 2007 From: dave.worthy at hp.com (Dave Worthy) Date: Wed, 11 Jul 2007 06:53:09 -0400 Subject: [Nagiosplug-devel] check_ldaps plugin help needed In-Reply-To: <46929262.7070209@hp.com> References: <46929262.7070209@hp.com> Message-ID: <4694B695.6090905@hp.com> Found the fix. For whatever reason, the check_ldaps would not bind using the IP address whilst with the hostname it worked beautifully( using $HOSTALIAS$ instead of $HOSTADDRESS$) <--this being the diff from nagios binary to command line...i was running cmd line with hostname Also note that using double quotes around the ldap query parms proved a problem when the DN had a space in the name; using single ticks around that fixed that issue as well: command_line $USER1$/check_ldaps -H $HOSTALIAS$ -b o=company.com -p #### -D 'cn=mytest,ou=IT Tester, o=company.com' -P $USER5$ -w 150 -c 300 -t 300 Dave Worthy wrote: > > I am running nagios 1.2 on a 2.4.21-27.ELsmp i686 host without trouble. > We are needing to migrate off that host and to a host running > 2.6.9-34.ELsmp x86_64 host. I'd like to upgrade, but time won't allow > currently, so I'm doing a straight port of 1.2 onto the new host for the > time being. > > My issue is that the plugin check_ldaps works on the old host, but not > the new one. It gets even more strange. I can get the command line, > any user, to run check_ldaps successfully, but the nagios binary > continues to launch failed check_ldaps connections. > > I've updated /etc/openldap/ldap.conf to include TLS_CACERT line to > indicate location of generic cert to use. I however don't have much > knowledge about the ldap innards making this extra difficult to > troubleshoot. > > What I do know is that any user on new host can run check_ldaps and it > works, but it shows up as failed in the new nagios browser. The nagios > binary has to be started as root > > Ideas? > > Dave > > I've also posted here, so hope I'm not double posting: > > http://www.meulie.net/portal_plugins/forum/forum_viewtopic.php?8777 > > > > > -- Dave Worthy Hewlett-Packard Company HPIT Linux (770)517-9986 Planned PTO: 7/17-22 From noreply at sourceforge.net Wed Jul 11 22:54:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 13:54:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-808369 ] Removing the slashes from check_nt disk name fixes email Message-ID: Bugs item #808369, was opened at 2003-09-18 09:44 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808369&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: CVS >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Steve Hanselman (stevehan) Assigned to: Benoit Mortier (opensides) Summary: Removing the slashes from check_nt disk name fixes email Initial Comment: Hi, (This is a fudge, not a fix as the real issue is in loading the symbol that is expanded for the email...) In check_nt.c if you remove the quoted slash after the disk name then you receive the full text of the disk status in the email/pager responses. The correct fix is to quote the slash in the symbol, but I haven't bothered to look for where that is done! ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-11 22:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Steve, I cannot reproduce this problem here. To me, there could be a problem with the notification command. I have used this define command{ command_name notify-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ } and it worked fine with mailx and check_nt. I'll close this item. Best regards Matthias ---------------------------------------------------------------------- Comment By: Steve Hanselman (stevehan) Date: 2005-01-04 10:26 Message: Logged In: YES user_id=521347 The text that comes back from check_nt relating to disk space reports it as (eg) c:\ and it needs to be c:\\ otherwise the email that is sent containing this is trashed. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 02:53 Message: Logged In: YES user_id=388184 hi, could you be more precise where the problem is ?? so i can fix it.. thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=808369&group_id=29880 From noreply at sourceforge.net Wed Jul 11 23:09:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jul 2007 14:09:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653253 ] check_nt: Wrong Unit in perfdata Message-ID: Bugs item #1653253, was opened at 2007-02-06 13:37 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: FliTTi (flitti) >Assigned to: Matthias Eble (psychotrahe) Summary: check_nt: Wrong Unit in perfdata Initial Comment: These Plugin puts everytime I call it, an % into the perfdata. The % is the Perfunit like this: Perfdata= 65.000000%;0.000000;0.000000;0 Is there an patch available or must I execute the check_nt plugin in an other way? ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-11 23:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi Flitti, is this still an issue? I have tested several calls and could not reproduce your problem. I cannot judge if you need to call the plugin otherwise Without knowing your command. However: ./check_nt -v CPULOAD -H 192.168.1.2 -l 10,90,95,10,90,95 -p 12489 CPU Load 0% (10 min average) 0% (10 min average) | '10 min avg Load'=0%;90;95;0;100 '10 min avg Load'=0%;90;95;0;100 -> looks fine ./check_nt -v MEMUSE -H 192.168.1.2 -l C -p 12489 Memory usage: total:1250,25 Mb - used: 331,50 Mb (27%) - free: 918,75 Mb (73%) | 'Memory usage'=331,50Mb;0,00;0,00;0.00;1250,25 -> looks fine ./check_nt -v USEDDISKSPACE -H 192.168.1.2 -l C -p 12489 C:\ - total: 156,25 Gb - used: 89,10 Gb (57%) - free 67,15 Gb (43%) | 'C:\ Used Space'=89,10Gb;0,00;0,00;0.00;156,25 -> looks fine the source doesn't look like if there is such a problem and the source has not changed significantly for long. I'm setting this issue to pending. It'll get deleted automatically if you won't post a comment in the next 14 days. Best regards Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 From rouilj at cs.umb.edu Thu Jul 12 04:26:59 2007 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 11 Jul 2007 22:26:59 -0400 Subject: [Nagiosplug-devel] check_ldaps plugin help needed In-Reply-To: Your message of "Wed, 11 Jul 2007 06:53:09 EDT." <4694B695.6090905@hp.com> Message-ID: <200707120226.l6C2QxUY016338@mx1.cs.umb.edu> In message <4694B695.6090905 at hp.com>, Dave Worthy writes: >Found the fix. For whatever reason, the check_ldaps would not bind using >the IP address whilst with the hostname it worked beautifully( using >$HOSTALIAS$ instead of $HOSTADDRESS$) <--this being the diff from nagios >binary to command line...i was running cmd line with hostname The certificate's CN needs to match the argument to -H (hostname). Unless your ldaps cert has the ip address as the CN, it's not going to work. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From Thomas at zango.com Thu Jul 12 19:08:49 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 12 Jul 2007 10:08:49 -0700 Subject: [Nagiosplug-devel] check_ldaps plugin help needed In-Reply-To: <200707120226.l6C2QxUY016338@mx1.cs.umb.edu> References: Your message of "Wed, 11 Jul 2007 06:53:09 EDT."<4694B695.6090905@hp.com> <200707120226.l6C2QxUY016338@mx1.cs.umb.edu> Message-ID: <804160344192334BB21922E8082EA6C0ACC4EA@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of John P. Rouillard > Sent: July 11, 2007 22:27 > To: Nagios Plugin Development Mailing List > Cc: dave.worthy at hp.com > Subject: Re: [Nagiosplug-devel] check_ldaps plugin help needed > > > In message <4694B695.6090905 at hp.com>, > Dave Worthy writes: > >Found the fix. For whatever reason, the check_ldaps would not bind using > >the IP address whilst with the hostname it worked beautifully( using > >$HOSTALIAS$ instead of $HOSTADDRESS$) <--this being the diff from nagios > >binary to command line...i was running cmd line with hostname > > The certificate's CN needs to match the argument to -H > (hostname). Unless your ldaps cert has the ip address as the CN, it's > not going to work. We should add an argument to allow specifying a hostname to use for certificate verification (or to skip cert verification, or even both). I always use IP addresses for monitoring so that DNS failures won't affect me. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Fri Jul 13 05:22:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jul 2007 20:22:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1753164 ] configure script fails to recognise radius libs Message-ID: Bugs item #1753164, was opened at 2007-07-13 13:22 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=1753164&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arya (alphamega) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails to recognise radius libs Initial Comment: There's a good chance this has already been fixed in CVS (and apologies if this is the case), but just in case it hasnt.... It looks like the configure script doesnt detect the radiusclient libs, even though they are present. OS: Solaris 10 Plugins Version: 1.4.9 Radiusclient Version: 0.3.2 [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # echo $PATH /usr/local/bin:/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/dt/bin:/usr/local/bin:/usr/local/sbin:/usr/sfw/bin:/usr/sfw/sbin:/usr/ccs/bin:/usr/local/ssl/bin:/opt/64/bin:/opt/64/sbin:/opt/SUNWspro/bin:/usr/ucb:/usr/local/BerkeleyDB.4.4/bin:/usr/local/apache2/bin:/usr/local/mysql/bin/:/usr/local/net-snmp/bin:/usr/local/net-snmp/sbin:/usr/local/openldap/bin:/usr/local/openldap/sbin:/usr/local/php5/bin:/usr/local/radiusclient/sbin:/usr/local/rrdtool/bin [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # crle Configuration file [version 4]: /var/ld/ld.config Default Library Path (ELF): /lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.4/lib:/usr/local/apache2/lib:/usr/local/mysql/lib/mysql:/usr/local/net-snmp/lib:/usr/local/openldap/lib:/usr/local/php5/lib:/usr/local/radiusclient/lib:/usr/local/rrdtool/lib:/usr/lib:/usr/sfw/lib Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.4/lib:/usr/local/apache2/lib:/usr/local/mysql/lib/mysql:/usr/local/net-snmp/lib:/usr/local/openldap/lib:/usr/local/php5/lib:/usr/local/radiusclient/lib:/usr/local/rrdtool/lib:/usr/lib:/usr/sfw/lib [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # cat configure-script.sh export CPPFLAGS="-I/usr/local/radiusclient/include -I/usr/local/openldap/include" export LDFLAGS="-L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib" export CC=gcc ./configure --prefix=/usr/local/nagios [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # ./configure-script.sh checking for libpq-fe.h... no checking for rc_read_config in -lradiusclient... no configure: WARNING: Skipping radius plugin configure: WARNING: install radius libs to compile this plugin (see REQUIREMENTS). checking for main in -lldap... yes checking for ldap_set_option... yes checking for ldap_init... yes checking for ldap_set_option... (cached) yes checking for ldap_get_option... yes checking for ldap_start_tls_s... yes config.status: creating po/Makefile --with-apt-get-command: --with-ping6-command: --with-ping-command: /usr/sbin/ping -n -s %s 56 %d --with-ipv6: yes --with-mysql: /usr/local/mysql/bin//mysql_config --with-openssl: yes --with-gnutls: no --with-perl: /usr/local/bin/perl --with-cgiurl: /nagios/cgi-bin --with-trusted-path: /bin:/sbin:/usr/bin:/usr/sbin [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # cd /usr/local [root at cbr-x2200-02 /usr/local] # ls -ld radiusclient* 2 lrwxrwxrwx 1 root root 19 Jul 12 16:07 radiusclient -> radiusclient-0.3.2/ 2 drwxr-xr-x 7 root root 512 Jul 12 15:54 radiusclient-0.3.2 [root at cbr-x2200-02 /usr/local] # du -a radiusclient/ 6 radiusclient/include/includes.h 24 radiusclient/include/radiusclient.h 4 radiusclient/include/messages.h 2 radiusclient/include/pathnames.h 38 radiusclient/include 154 radiusclient/lib/libradiusclient.so.0.0.1 2 radiusclient/lib/libradiusclient.so.0 2 radiusclient/lib/libradiusclient.so 2 radiusclient/lib/libradiusclient.la 224 radiusclient/lib/libradiusclient.a 386 radiusclient/lib 52 radiusclient/sbin/radlogin 24 radiusclient/sbin/radstatus 26 radiusclient/sbin/radacct 22 radiusclient/sbin/radexample 126 radiusclient/sbin 2 radiusclient/etc/radiusclient/servers 2 radiusclient/etc/radiusclient/issue 2 radiusclient/etc/radiusclient/port-id-map 6 radiusclient/etc/radiusclient/radiusclient.conf 14 radiusclient/etc/radiusclient/dictionary 26 radiusclient/etc/radiusclient/dictionary.ascend 4 radiusclient/etc/radiusclient/dictionary.compat 2 radiusclient/etc/radiusclient/dictionary.merit 60 radiusclient/etc/radiusclient 62 radiusclient/etc 18 radiusclient/doc/instop.html 20 radiusclient/doc 634 radiusclient Once I comment out some lines in configure (lines 20994 - 21003): #if test "$ac_cv_lib_radiusclient_rc_read_config" = "yes"; then EXTRAS="$EXTRAS check_radius" RADIUSLIBS="-lradiusclient" #else # { echo "$as_me:$LINENO: WARNING: Skipping radius plugin" >&5 #echo "$as_me: WARNING: Skipping radius plugin" >&2;} # { echo "$as_me:$LINENO: WARNING: install radius libs to compile this plugin (see REQUIREMENTS)." >&5 #echo "$as_me: WARNING: install radius libs to compile this plugin (see REQUIREMENTS)." >&2;} #fi I can re-run ./configure-script.sh. Obviously configure will still report this: checking for rc_read_config in -lradiusclient... no However, it pretends it's there, and when I run a 'make', viola, it works. To install radiusclient, I did a simple "./configure --prefix=/usr/local/radiusclient && make && make install" -- which works. [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9/plugins] # make check_radius if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT check_radius.o -MD -MP -MF ".deps/check_radius.Tpo" -c -o check_radius.o check_radius.c; \ then mv -f ".deps/check_radius.Tpo" ".deps/check_radius.Po"; else rm -f ".deps/check_radius.Tpo"; exit 1; fi In file included from check_radius.c:42: common.h:191: warning: static declaration of 'floorf' follows non-static declaration if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT netutils.o -MD -MP -MF ".deps/netutils.Tpo" -c -o netutils.o netutils.c; \ then mv -f ".deps/netutils.Tpo" ".deps/netutils.Po"; else rm -f ".deps/netutils.Tpo"; exit 1; fi In file included from netutils.c:36: common.h:191: warning: static declaration of 'floorf' follows non-static declaration if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT utils.o -MD -MP -MF ".deps/utils.Tpo" -c -o utils.o utils.c; \ then mv -f ".deps/utils.Tpo" ".deps/utils.Po"; else rm -f ".deps/utils.Tpo"; exit 1; fi In file included from utils.c:17: common.h:191: warning: static declaration of 'floorf' follows non-static declaration /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib -L. -L/usr/local/ssl/lib -o check_radius check_radius.o netutils.o utils.o ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lradiusclient -lnsl -lsocket mkdir .libs gcc -g -O2 -o check_radius check_radius.o netutils.o utils.o -L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -L/usr/local/src/nagios-plugins-1.4.9/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../gl/libgnu.a -lresolv /usr/local/radiusclient/lib/libradiusclient.so -lcrypt -lnsl -lsocket -R/usr/local/radiusclient/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9/plugins] # ldd ./check_radius libresolv.so.2 => /lib/libresolv.so.2 libradiusclient.so.0 => /usr/local/radiusclient/lib/libradiusclient.so.0 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 libgen.so.1 => /lib/libgen.so.1 libmp.so.2 => /lib/libmp.so.2 libmd5.so.1 => /lib/libmd5.so.1 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libm.so.2 => /lib/libm.so.2 I suspect what's happening here is that configure is a little too optimistic about how configured the radiusclient installation is :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753164&group_id=29880 From danm at prime.gushi.org Thu Jul 12 23:00:43 2007 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 12 Jul 2007 17:00:43 -0400 (EDT) Subject: [Nagiosplug-devel] check_mrtgtraf checking CURRENT traffic? Message-ID: <20070712165647.Y43890@prime.gushi.org> Hello All, I'm looking to throw a warning with the check_mrtgtraf when a customer's port CURRENTLY (i.e. within the last X number of samples) exceeds a certain value. Since this is the one value this plugin doesn't seem to be able to do (only AVERAGE (over the lifetime of the logfile) and MAX (high water mark) appear to be supported. Does anyone know how difficult this would be to implement? Alternatively, some way to adjust the value from which the average is calculated (i.e. the average of the last 5 samples) -- which is different from my original request (which is alert if ANY of the last 5 samples exceed a threshhold). Ideas, or pointers to an improved plugin are much appreciated. -Dan Mahoney -- "You're a thucking reyer!" -Richard Bozzello, who believed tongue piercing was painless. --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From noreply at sourceforge.net Fri Jul 13 16:17:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jul 2007 07:17:43 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1753506 ] check_ntp : typo Message-ID: Bugs item #1753506, was opened at 2007-07-13 16:17 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=1753506&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aurelien Bompard (abompard) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp : typo Initial Comment: There's a typo in the argument checks in check_ntp. In the current CVS : http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/plugins/check_ntp.c?view=markup line 723. There is a second check for ocrit < owarn, instead of checking for jcrit < jwarn. Here's the current code: if (ocrit < owarn){ usage4(_("Critical offset should be larger than warning offset")); } if (ocrit < owarn){ usage4(_("Critical jitter should be larger than warning jitter")); } The second check should be jcrit < jwarn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753506&group_id=29880 From noreply at sourceforge.net Fri Jul 13 16:18:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jul 2007 07:18:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1753506 ] check_ntp : typo Message-ID: Bugs item #1753506, was opened at 2007-07-13 16:17 Message generated for change (Settings changed) made by abompard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753506&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Aurelien Bompard (abompard) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp : typo Initial Comment: There's a typo in the argument checks in check_ntp. In the current CVS : http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/plugins/check_ntp.c?view=markup line 723. There is a second check for ocrit < owarn, instead of checking for jcrit < jwarn. Here's the current code: if (ocrit < owarn){ usage4(_("Critical offset should be larger than warning offset")); } if (ocrit < owarn){ usage4(_("Critical jitter should be larger than warning jitter")); } The second check should be jcrit < jwarn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753506&group_id=29880 From noreply at sourceforge.net Fri Jul 13 17:38:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jul 2007 08:38:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1753626 ] argument processing for check_snmp_disk_monitor.pl Message-ID: Patches item #1753626, was opened at 2007-07-13 11:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1753626&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: trockij-unisys (trockij-unisys) Assigned to: Nobody/Anonymous (nobody) Summary: argument processing for check_snmp_disk_monitor.pl Initial Comment: In contrib/check_snmp_disk_monitor.pl, -c and -w do not work. This patch fixes the problem. I first contacted the original author via the email in the source, but the email bounced, so this is why I am making this submission here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1753626&group_id=29880 From noreply at sourceforge.net Sat Jul 14 20:34:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jul 2007 11:34:18 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1753506 ] check_ntp : typo Message-ID: Bugs item #1753506, was opened at 2007-07-13 16:17 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753506&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS >Status: Closed >Resolution: Accepted Priority: 1 Private: No Submitted By: Aurelien Bompard (abompard) >Assigned to: Matthias Eble (psychotrahe) Summary: check_ntp : typo Initial Comment: There's a typo in the argument checks in check_ntp. In the current CVS : http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/plugins/check_ntp.c?view=markup line 723. There is a second check for ocrit < owarn, instead of checking for jcrit < jwarn. Here's the current code: if (ocrit < owarn){ usage4(_("Critical offset should be larger than warning offset")); } if (ocrit < owarn){ usage4(_("Critical jitter should be larger than warning jitter")); } The second check should be jcrit < jwarn ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 20:34 Message: Logged In: YES user_id=1694341 Originator: NO Hi Aurelien, I've fixed this in cvs. Thanks for your report. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753506&group_id=29880 From noreply at sourceforge.net Sat Jul 14 21:52:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jul 2007 12:52:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1742066 ] nagios-plugins-1.4.8 check_smtp Message-ID: Bugs item #1742066, was opened at 2007-06-23 15:44 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1742066&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christoph Schell (cschell) >Assigned to: Matthias Eble (psychotrahe) Summary: nagios-plugins-1.4.8 check_smtp Initial Comment: buffer overflow in argument handling If I use check_smtp -H 127.0.0.1 -C "HELO Nagios" -R 250 -C "MAIL FROM:" -R 250 -C "RCPT TO:" -R 250 -C "DATA" -R 354 -C "." -R 250 -t 30 I got a buffer overflow in the argument handling. I fixed the problem with the attched patch. Christoph ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 21:52 Message: Logged In: YES user_id=1694341 Originator: NO Hi Cristoph, I slightly changed your patch and commited it to cvs. The changes were: 1. I use sizeof(char*) instead of sizeof(char**). Is there a reason why you used **? 2. changed the number in strncpy to 255. Why did you use only 250? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1742066&group_id=29880 From noreply at sourceforge.net Sat Jul 14 22:10:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jul 2007 13:10:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1681482 ] check_ifstatus - SNMPv3 - bug line 307 Message-ID: Bugs item #1681482, was opened at 2007-03-15 14:50 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1681482&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Geoffrey Lemaire (geolem) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus - SNMPv3 - bug line 307 Initial Comment: RHEL 4 - nagios 2.8 (via up2date) RHEL 4 - check_ifstatus version : check_ifstatus (nagios-plugins 1.4.5) 1.9 Hi, I have a problem with check_ifstatus and SNMPv3 at line 307. When I do a : --- ./check_ifstatus -H 127.0.0.1 -v 3 -L authNoPriv -a MD5 -U mylogin -A mypassword --- I have the message : --- Missing arguments! check_ifstatus -C -p -H Copyright (C) 2000 Christoph Kron Updates 5/2002 Subhendu Ghosh --- I put a lot of "printf" and I found a problem on the line 307 : --- unless ($seclevel eq ('noAuthNoPriv' || 'authNoPriv' || 'authPriv' ) ) { --- It forward me to the "usage();". When I do a (for testing my SNMPv3) : --- snmpget -v 3 -u mylogin -l authNoPriv -a MD5 -A mypassword localhost sysUpTime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (196856) 0:32:48.56 --- It's look ok... So, what we can do ? (started topic : http://forums.opsyx.com/viewtopic.php?p=21709#21709) Very thanks ! ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 22:10 Message: Logged In: YES user_id=1694341 Originator: NO Hi Geoffrey, is your problem fixed in the latest release? I'm setting this item to pending. It will get deleted automatically, if you won't post in the next 14 days. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Gavin Carr (gonzai) Date: 2007-03-16 13:13 Message: Logged In: YES user_id=674647 Originator: NO Yep, that's completely broken, and there's another couple of places just like it. Fix checked into CVS now. Cheers, Gavin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1681482&group_id=29880 From noreply at sourceforge.net Sat Jul 14 23:31:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jul 2007 14:31:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1595449 ] check_procs bus error, ... on Solaris 8, 9 & 10 Message-ID: Bugs item #1595449, was opened at 2006-11-13 09:23 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs bus error, ... on Solaris 8, 9 & 10 Initial Comment: check_procs bus error, segmentation fault or wrong output on Solaris 8, 9 & 10 Do first the next configure! ---------------------------- ./configure --with-ps_command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps_format='%s %d %d %d %d %d %f %s %s %n' --with-ps_cols=10 --with-ps_varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' --with-trusted-path=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin To solve the bus error and /or segmentation fault on Solaris 8: -------------------------------------------------- replace into check_procs.c if ( cols >= expected_cols ) { resultsum = 0; - asprintf (&procargs, "%s", input_line + pos); strip (procargs); with if ( cols >= expected_cols ) { resultsum = 0; + asprintf (&procargs, "%s", input_line); strip (procargs); To solve the wrong output on Solaris 8, 9 & 10: ----------------------------------------------- change into common.h MAX_INPUT_BUFFER 1024 to MAX_INPUT_BUFFER 4096 ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 23:31 Message: Logged In: YES user_id=1694341 Originator: NO Hi Alex, is the bus error still there? Matthias ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-17 15:05 Message: Logged In: YES user_id=375623 Originator: NO The patch can be found on bug #1630970. It is also fixed in the latest release, 1.4.6 https://sourceforge.net/tracker/index.php?func=detail&aid=1630970&group_id=29880&atid=397597 ---------------------------------------------------------------------- Comment By: msB (msbenjamin12) Date: 2007-02-16 13:41 Message: Logged In: YES user_id=1097533 Originator: NO Where is the original code, I need to fix this I get the wrong output on Solaris 9. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-17 06:37 Message: Logged In: YES user_id=375623 Originator: NO The wrong output bug should be fixed (1630970). I (or somebody else) will have to look further for the bus error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 From noreply at sourceforge.net Sat Jul 14 23:48:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jul 2007 14:48:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1569488 ] check_ifoperstatus.pl - -n option doesn't work, with fix Message-ID: Bugs item #1569488, was opened at 2006-10-02 21:12 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Sellens (jsellens) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifoperstatus.pl - -n option doesn't work, with fix Initial Comment: I wanted to use the -n option to check_ifoperstatus, but it wasn't working. The -n / --name option declarations set the $ifName variable, but the test around line 153 checks $name instead of $ifName, so the names are never compared. In the paragraph starting with the "Check to see if ifName match", change $name to $ifName in the 3 places it is used. thanks - cheers! John who's very surprised this has apparently existed this long without anyone noticing ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 23:48 Message: Logged In: YES user_id=1694341 Originator: NO Hi John, I've set up an snmp daemon to reproduce your problem. I haven't done much with snmp to be honest. I can reproduce the problem. But renaming the variables doesn't do the job in my environment. It seems that my setup has some other problems (the 1.3.6.1.2.1.31 tree is not available). After googling around, i think I need a if-mibII to get this going, But I could imagine to test the string against the description if the ifName is not available in the mib-tree. I cannot rate if this would be a good solution. Can anyone help? Matthias ---------------------------------------------------------------------- Comment By: John Sellens (jsellens) Date: 2006-10-02 21:20 Message: Logged In: YES user_id=8519 Oops - and also in the "if (defined $name) {" at line 143 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 From noreply at sourceforge.net Sun Jul 15 16:23:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jul 2007 07:23:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1463846 ] check_procs via nrpe - proc count Message-ID: Bugs item #1463846, was opened at 2006-04-03 23:43 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1463846&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: NotDisplayed123 (lbruun) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs via nrpe - proc count Initial Comment: nrpe uses the popen to execute the check command. This means that a new shell will be spawned. check_procs should take care to ignore this process. If not then if check_procs is used with the -a option it will count one too many processes it its count. At the moment when nrpe executes check_procs I see two processes on my system: ../libexec/check_procs ..... foo sh -c ../libexec/check_procs ...... foo If my check_procs -a argument is "foo" then both of the above will be matched. Only the first will be caught by the ignore self catch. If I go back to an old version of check_procs that uses the old method to ignore self (compare procname against string constant "check_procs") and the old method to extract the basename (a strtok() loop) then I have no problem. I'm not saying those fixes should be undone. It's just an observation. I must admit I cannot really see how this has worked in the past... but it did. One obvious fix to the problem would be to test not only against mypid but also against myppid. I'm on Solaris but I doubt there's any difference between Solaris and Linux in this respect. Lars ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-15 16:23 Message: Logged In: YES user_id=1694341 Originator: NO Hi Lars, is this still an issue? I tried this with the latest cvs and the problem doesn't seem to occur. Yet I could imagine also ignoring processes where ppid is check_procs' pid (to ignore the ps command called by check_procs). Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1463846&group_id=29880 From noreply at sourceforge.net Sun Jul 15 17:25:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jul 2007 08:25:22 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1280470 ] check_procs cannot detect zombies on AIX Message-ID: Bugs item #1280470, was opened at 2005-09-02 11:35 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) >Assigned to: Matthias Eble (psychotrahe) Summary: check_procs cannot detect zombies on AIX Initial Comment: ./check_procs -s Z -v Not parseable: Z 188558 98382 Not parseable: Z 196776 98382 PROCS OK: 0 processes with STATE = Z should return 2 zombies - AIX lists them as >> ps auxwww | egrep "USER|def" USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 188558 Z 0:00 root 196776 Z 0:00 >> ps -efal | egrep "UID|def" F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 50005 Z root 188558 98382 0 60 20 0:00 50005 Z root 196776 98382 0 60 20 0:00 ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-15 17:25 Message: Logged In: YES user_id=1694341 Originator: NO Hi Andrew, the change should be save and is now applied to CVS like proposed. It'd be nice, if someone could test new detection and report the result here. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Felix Frank (illtiz) Date: 2007-05-18 14:30 Message: Logged In: YES user_id=249077 Originator: NO The described patch could also work around a problem I encountered with solars. Check procs would return correct states, but the output would be overwritten by warning messages of the form "Not parseable: Z 107 21841 0 0 - defunct [newline] defunct". I have had no opportunity to give it a try but the phenomenon appears to be quite common. ---------------------------------------------------------------------- Comment By: wszenajch (wszenajch) Date: 2006-10-17 13:34 Message: Logged In: YES user_id=1622130 For nagios-plugins-HEAD-200610152352 I have made the following correction to make this plugin working correctly with processes on AIX 5.2: In file check_procs.c find line: if ( cols == (expected_cols - 1) && strstr(procstat, zombie) ) { and replace it with the following: if ( cols < expected_cols && strstr(procstat, zombie) ) { On AIX 5.2 it works correctly reporting total number of processes (which was wrong before this change) and number of zombie processes when option '-s Z' is used. This change does not seem to affect Linux systems: I made brief tests with OpenSUSE10.1 i386, SuSE 10.0 x86_64 and SLES10 ia64; but other platforms i.e. Solaris should be tested before applying this change for production. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 From noreply at sourceforge.net Mon Jul 16 17:41:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jul 2007 08:41:04 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1532272 ] Warnings Message-ID: Bugs item #1532272, was opened at 2006-08-01 10:48 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1532272&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ciro Iriarte (cyruspy) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings Initial Comment: source='utils_base.c' object='utils_base.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -g -c utils_base.c cc: Warning: utils_base.c, line 108: In this statement, "0" of type "int", is being converted to "pointer to struct thresholds_struct". (cvtdiftypes) if (*my_thresholds > 0) { /* Not sure why, but sometimes could be -1 */ ------------^ source='netutils.c' object='netutils.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c netutils.c cc: Warning: netutils.c, line 228: In this statement, "0" of type "int", is being converted to "pointer to int". (cvtdiftypes) if(sd < 0){ -------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_http check_http.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_ntp.c' object='check_ntp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_ntp.c cc: Warning: check_ntp.c, line 524: In this statement, performing pointer arithmetic on a pointer to void or a pointer to function is not allowed. The compiler will treat the type as if it were pointer to char. (badptrarith) memcpy((void*)peers+peer_offset, (void*)req.data, sizeof(ntp_assoc_status_pair)*npeers); -----------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_ntp check_ntp.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lm -lssl -lcrypto cc -g -o check_ntp check_ntp.o netutils.o utils.o source='check_smtp.c' object='check_smtp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_smtp.c cc: Warning: check_smtp.c, line 354: In this statement, the referenced type of the pointer value "((const char ...)("no authuser specified, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("no authuser specified, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 359: In this statement, the referenced type of the pointer value "((const char ...)("no authpass specified, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("no authpass specified, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 369: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after AUTH LOGIN, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after AUTH LOGIN, \n"); ------------------------------------------------^ cc: Warning: check_smtp.c, line 379: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after AUTH LOGIN, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after AUTH LOGIN, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 392: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after sending authuser, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after sending authuser, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 401: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after authuser, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after authuser, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 413: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after sending authpass, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after sending authpass, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 422: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after authpass, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after authpass, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 429: In this statement, the referenced type of the pointer value "((const char ...)("only authtype LOGIN is supported, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("only authtype LOGIN is supported, "); --------------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_smtp check_smtp.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_smtp check_smtp.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_ssh.c' object='check_ssh.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_ssh.c /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_ssh check_ssh.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_ssh check_ssh.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_tcp.c' object='check_tcp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_tcp.c cc: Warning: check_tcp.c, line 498: In this statement, "np_escaped_string(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) server_send = np_escaped_string(optarg); --------------------------------^ cc: Warning: check_tcp.c, line 518: In this statement, "np_escaped_string(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) server_quit = np_escaped_string(optarg); --------------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_tcp check_tcp.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_tcp check_tcp.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_procs.c' object='check_procs.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_procs.c cc: Warning: check_procs.c, line 192: In this statement, "base_name(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) procprog = base_name(procprog); ------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_procs check_procs.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lssl -lcrypto cc -g -o check_procs check_procs.o utils.o popen.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lssl -lcrypto ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-16 17:41 Message: Logged In: YES user_id=1694341 Originator: NO Hi Ciro, are you still seeing this with recent releases? Is your platform tru64? Have you tried using gcc? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1532272&group_id=29880 From klipp.m at Eppendorf.DE Wed Jul 18 17:08:11 2007 From: klipp.m at Eppendorf.DE (Marco Klipp) Date: Wed, 18 Jul 2007 17:08:11 +0200 Subject: [Nagiosplug-devel] Error in check_mrtg source code Message-ID: <469E48FB.262A.00CB.0@Eppendorf.DE> Hi nagios team, I Think I found an error in the plugin check_mrtg Please check : if ( rate > value_critical_threshold) result = STATE_CRITICAL; else if (rate > value_warning_threshold) result = STATE_WARNING; else result = STATE_OK; There is the last else missing. Without this the returnvalue would never be 0 (OK) ! I hope this helps. regards Marco Klipp System Manager IT Helpdesk eppendorf AG Fon : +49 40 53801 - 539 --------------------------------------------------------------------------------------- This email including its attachments is intended for the person or entity only to which it is addressed. It may contain confidential and/or privileged material. Any review, forwarding, dissemination, other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material from any computer system. --------------------------------------------------------------------------------------- Eppendorf AG, Hamburg, Barkhausenweg 1, 22339 Hamburg, Amtsgericht Hamburg HRB 76249 Vors. des Aufsichtsrats: Dr. Robert Mann Vorstand: Klaus Fink (Vorsitzender), Detmar Ammermann, Dr. Heinz G. Koehn, Dr. Michael Schroeder Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077 Gesch?ftsf?hrer: Rainer Treptow Eppendorf Biochip Systems GmbH, Hamburg, Amtsgericht Hamburg, HRB 96641 Gesch?ftsf?hrer: Dr. Sven Buelow Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250 Gesch?ftsf?hrer: Boris von Beichmann From matthias.eble at mailing.kaufland-informationssysteme.com Wed Jul 18 19:43:08 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Wed, 18 Jul 2007 19:43:08 +0200 Subject: [Nagiosplug-devel] Error in check_mrtg source code In-Reply-To: <469E48FB.262A.00CB.0@Eppendorf.DE> References: <469E48FB.262A.00CB.0@Eppendorf.DE> Message-ID: <469E512C.7030003@mailing.kaufland-informationssysteme.com> Marco Klipp schrieb: Hi Marco, > > if ( rate > value_critical_threshold) > result = STATE_CRITICAL; > else if (rate > value_warning_threshold) > result = STATE_WARNING; what about this one? It's not indented correctly but I can't see, why it shouldn't work. > else result = STATE_OK; > > There is the last else missing. > Without this the returnvalue would never be 0 (OK) ! Matthias From kmenard at servprise.com Wed Jul 18 23:19:55 2007 From: kmenard at servprise.com (Kevin Menard) Date: Wed, 18 Jul 2007 17:19:55 -0400 Subject: [Nagiosplug-devel] Plugin licensing Message-ID: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> Hi, As noted on the user list, I'm heading up a development effort to provide Nagios integration with our WebReboot line of products. We're committed to open sourcing them, but I've always been more partial to the BSD-style licenses. Actually, I tend to use the ASL for everything, since I work on ASF projects. Anyway, without getting into a licensing flamewar, I'm wondering to what extent the derivative works clause of the GPL applies to Nagios plugins. Given that a plugin is essentially just a command-line program that takes arguments and returns a status code, it would appear that an app may not be a derivative work at all. If the plugin starts using the Nagios environment variables or the status codes, then the area starts getting murkier. Given that I'm not a lawyer and don't profess to be one, I'll probably just go with the consensus here. Does a Nagios plugin have to be GPL'd? Thanks, Kevin -- Kevin Menard Servprise International, Inc. 800.832.3823 x308 From seanius at seanius.net Thu Jul 19 08:03:26 2007 From: seanius at seanius.net (sean finney) Date: Thu, 19 Jul 2007 08:03:26 +0200 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> Message-ID: <200707190803.37144.seanius@seanius.net> hi kevin, as a preface, i haven't been the most active developer as of late, so i would wait to hear from some of the other developers before considering a consensus reached. however, i have had to deal with this issue a few times, so i'll chime in. On Wednesday 18 July 2007 23:19:55 Kevin Menard wrote: > Anyway, without getting into a licensing flamewar, I'm wondering to what > extent the derivative works clause of the GPL applies to Nagios plugins. from the most common interpretation, "derivative works" usually includes: - modified versions of the plugins - other software that contains code (modified or not) copied from the plugins - other software that #includes header files from the plugins - other software that has linked against library files from the plugins and what it does not usually include: - other software that parses the output of a plugin run from the cmdline, exit status, etc - software that provides a "wrapper" for cmdline execution of the plugin - software that uses status codes and other values which are in the header files, but also described in the documentation (though not #including or linking to the source) > getting murkier. Given that I'm not a lawyer and don't profess to be > one, I'll probably just go with the consensus here. Does a Nagios > plugin have to be GPL'd? well, the plugins are still GPL'd, and if you distribute an app that includes the plugins, you're required to distribute a copy of the source code for the plugins under the terms of the GPL regardless of the licensing for the rest of the app. however, as long as you stay clear of what could make your code considered a derivative work, it shouldn't affect any licensing plans you have for the rest of the app. or at least, this is my 0.02 $currency. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From ton.voon at altinity.com Thu Jul 19 10:47:21 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 19 Jul 2007 09:47:21 +0100 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: <200707190803.37144.seanius@seanius.net> References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> <200707190803.37144.seanius@seanius.net> Message-ID: On 19 Jul 2007, at 07:03, sean finney wrote: > On Wednesday 18 July 2007 23:19:55 Kevin Menard wrote: >> getting murkier. Given that I'm not a lawyer and don't profess to be >> one, I'll probably just go with the consensus here. Does a Nagios >> plugin have to be GPL'd? Sean's response was accurate, from my point of view, so I've stuck it on our website: http://nagiosplugins.org/index.php? option=com_easyfaq&task=view&id=12&Itemid=29&mosmsg=Changes+to+item +saved Any comments? I was thinking that when I create a new C plugin, I usually copy an existing one and strip out everything except the getopt handling and the help stuff. Then the new bits are just the communication with the external system. However, under the definitions above, this would mean it is a derived work, so would have to be GPL'd. Then I was thinking, maybe we could provide a library with headers and have that under LGPL, but we use a lot of gnulib code (getopt handling, internationalisation) which is GPL'd, not LGPL'd, so our executable would have to be GPL'd. If you wanted to protect some intellectual property, you'd have to make a library which returned all the data you wanted, and then create a plugin which is GPL'd, but only uses the library API to get at the information. Alternatively, to make a plugin NOT under GPL, you'd have to write it from scratch without any external libraries which are GPL'd, which is certainly possible, though a bit more work. Remember, the aim of the Free Software Foundation is to make all software free. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From gavin at openfusion.com.au Thu Jul 19 13:02:07 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 19 Jul 2007 21:02:07 +1000 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> <200707190803.37144.seanius@seanius.net> Message-ID: <20070719110207.GC14961@openfusion.com.au> On Thu, Jul 19, 2007 at 09:47:21AM +0100, Ton Voon wrote: > > On 19 Jul 2007, at 07:03, sean finney wrote: > > > On Wednesday 18 July 2007 23:19:55 Kevin Menard wrote: > >> getting murkier. Given that I'm not a lawyer and don't profess to be > >> one, I'll probably just go with the consensus here. Does a Nagios > >> plugin have to be GPL'd? > > Sean's response was accurate, from my point of view, so I've stuck it > on our website: > > http://nagiosplugins.org/index.php? > option=com_easyfaq&task=view&id=12&Itemid=29&mosmsg=Changes+to+item > +saved > > Any comments? > > I was thinking that when I create a new C plugin, I usually copy an > existing one and strip out everything except the getopt handling and > the help stuff. Then the new bits are just the communication with the > external system. However, under the definitions above, this would > mean it is a derived work, so would have to be GPL'd. > > Then I was thinking, maybe we could provide a library with headers > and have that under LGPL, but we use a lot of gnulib code (getopt > handling, internationalisation) which is GPL'd, not LGPL'd, so our > executable would have to be GPL'd. > > If you wanted to protect some intellectual property, you'd have to > make a library which returned all the data you wanted, and then > create a plugin which is GPL'd, but only uses the library API to get > at the information. > > Alternatively, to make a plugin NOT under GPL, you'd have to write it > from scratch without any external libraries which are GPL'd, which is > certainly possible, though a bit more work. > > Remember, the aim of the Free Software Foundation is to make all > software free. Just to add another wrinkle to the discussion, on the perl side of things the Nagios::Plugin perl module (and hence plugins that use _that_, I guess) are licensed under the standard Perl licence (that was you, Ton, right?), which is to say it's dual-licensed (at the user's choice) under both GPL and the Perl Artistic Licence. My IANAL understanding is that the Perl Artistic Licence is somewhere between the GPL and BSD licences in terms of restrictions and freedom? Cheers, Gavin From dermoth at aei.ca Thu Jul 19 14:14:58 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 19 Jul 2007 08:14:58 -0400 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> <200707190803.37144.seanius@seanius.net> Message-ID: <469F55C2.2090101@aei.ca> On 19/07/07 04:47 AM, Ton Voon wrote: > > Sean's response was accurate, from my point of view, so I've stuck it > on our website: > > http://nagiosplugins.org/index.php? > option=com_easyfaq&task=view&id=12&Itemid=29&mosmsg=Changes+to+item > +saved > > Any comments? My POV is pretty much the same... I even roughly replied the same thing (not looking at headers though) but forgot to send it! :( > I was thinking that when I create a new C plugin, I usually copy an > existing one and strip out everything except the getopt handling and > the help stuff. Then the new bits are just the communication with the > external system. However, under the definitions above, this would > mean it is a derived work, so would have to be GPL'd. > > Then I was thinking, maybe we could provide a library with headers > and have that under LGPL, but we use a lot of gnulib code (getopt > handling, internationalisation) which is GPL'd, not LGPL'd, so our > executable would have to be GPL'd. > > If you wanted to protect some intellectual property, you'd have to > make a library which returned all the data you wanted, and then > create a plugin which is GPL'd, but only uses the library API to get > at the information. > > Alternatively, to make a plugin NOT under GPL, you'd have to write it > from scratch without any external libraries which are GPL'd, which is > certainly possible, though a bit more work. > > Remember, the aim of the Free Software Foundation is to make all > software free. I agree on this one and for that reason I wouldn't push for a LGPL library and BSD or public-domain plugin template. I personally don't see any benefit in giving out the tools to write proprietary Nagios plugins. Thomas From stefan.lambrev at sun-fish.com Thu Jul 19 16:16:53 2007 From: stefan.lambrev at sun-fish.com (Stefan Lambrev) Date: Thu, 19 Jul 2007 17:16:53 +0300 Subject: [Nagiosplug-devel] check_disk plugin problems Message-ID: <469F7255.8050906@sun-fish.com> Hello, I'm having some strange problems with nagios' check_disk plugin under FreeBSD i386 7-current. 1st if I use -p /some/path the plugin exits with segmentation fault - http://cheffo.freebsd-bg.org/ktrace.out provided if someone knows how to use ktrace/kdump 2nd problem is "-c" option does not work at all. Here is example: /usr/local/libexec/nagios/check_disk -c 99% DISK OK - free space: / 3792 MB (83% inode=99%); /dev 0 MB (0% inode=-); /tmp 4559 MB (99% inode=99%); /usr 91711 MB (97% inode=98%); /var 18101 MB (99% inode=99%);| /=769MB;;;0;4958 /dev=0MB;;;0;0 /tmp=2MB;;;0;4958 /usr=2006MB;;;0;101867 /var=144MB;;;0;19832 it is quite strange that -w is working may be they work in different ways ? Thanks in advance. P.S. I'm not subscribed so please CC me on replies. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From kmenard at servprise.com Thu Jul 19 20:49:33 2007 From: kmenard at servprise.com (Kevin Menard) Date: Thu, 19 Jul 2007 14:49:33 -0400 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office><200707190803.37144.seanius@seanius.net> Message-ID: <384329B8D7108B45A3064FB38FCF267B0E19A3@aristotle.servprise.office> Thanks for the write-up, Ton. Also, thanks to everyone else that chimed in. Based on what I'm hearing, I should be good to go with either the ASL or BSD. I'm writing the plugin(s) in Python and as such, am not linking in either the C headers or the CPAN module. I'll just have to be diligent about working from the documentation rather than the GPL plugins as sources of inspiration. Thanks again, Kevin > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Ton Voon > Sent: Thursday, July 19, 2007 4:47 AM > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Plugin licensing > > > On 19 Jul 2007, at 07:03, sean finney wrote: > > > On Wednesday 18 July 2007 23:19:55 Kevin Menard wrote: > >> getting murkier. Given that I'm not a lawyer and don't > profess to be > >> one, I'll probably just go with the consensus here. Does a Nagios > >> plugin have to be GPL'd? > > Sean's response was accurate, from my point of view, so I've > stuck it on our website: > > http://nagiosplugins.org/index.php? > option=com_easyfaq&task=view&id=12&Itemid=29&mosmsg=Changes+to+item > +saved > > Any comments? > > I was thinking that when I create a new C plugin, I usually > copy an existing one and strip out everything except the > getopt handling and the help stuff. Then the new bits are > just the communication with the external system. However, > under the definitions above, this would mean it is a derived > work, so would have to be GPL'd. > > Then I was thinking, maybe we could provide a library with > headers and have that under LGPL, but we use a lot of gnulib > code (getopt handling, internationalisation) which is GPL'd, > not LGPL'd, so our executable would have to be GPL'd. > > If you wanted to protect some intellectual property, you'd > have to make a library which returned all the data you > wanted, and then create a plugin which is GPL'd, but only > uses the library API to get at the information. > > Alternatively, to make a plugin NOT under GPL, you'd have to > write it from scratch without any external libraries which > are GPL'd, which is certainly possible, though a bit more work. > > Remember, the aim of the Free Software Foundation is to make > all software free. > > Ton > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by DB2 Express Download DB2 > Express C - the FREE version of DB2 express and take control > of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting > any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From matthias.eble at mailing.kaufland-informationssysteme.com Fri Jul 20 11:04:03 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 20 Jul 2007 11:04:03 +0200 Subject: [Nagiosplug-devel] check_disk plugin problems In-Reply-To: <469F7255.8050906@sun-fish.com> References: <469F7255.8050906@sun-fish.com> Message-ID: <46A07A83.7010209@mailing.kaufland-informationssysteme.com> Stefan Lambrev schrieb: > Hello, > > I'm having some strange problems with nagios' check_disk plugin under > FreeBSD i386 7-current. > > 1st if I use -p /some/path the plugin exits with segmentation fault - > http://cheffo.freebsd-bg.org/ktrace.out provided if someone knows > how to use ktrace/kdump > > 2nd problem is "-c" option does not work at all. > Here is example: > > /usr/local/libexec/nagios/check_disk -c 99% > DISK OK - free space: / 3792 MB (83% inode=99%); /dev 0 MB (0% inode=-); > /tmp 4559 MB (99% inode=99%); /usr 91711 MB (97% inode=98%); /var 18101 > MB (99% inode=99%);| /=769MB;;;0;4958 /dev=0MB;;;0;0 /tmp=2MB;;;0;4958 > /usr=2006MB;;;0;101867 /var=144MB;;;0;19832 > > it is quite strange that -w is working may be they work in different ways ? > > Thanks in advance. > > P.S. I'm not subscribed so please CC me on replies. > Hi Stefan, never used ktrace.. However. Which version of the plugins are you using? I have a freebsd 6.2 here and everything works fine. -w should work exactly like -c. I successfully ran the test cases for the latest snapshot on my freebsd box, too. Could you send an output of the segfaulting call with -vvvv turned on? Matthias From stefan.lambrev at sun-fish.com Fri Jul 20 11:26:39 2007 From: stefan.lambrev at sun-fish.com (Stefan Lambrev) Date: Fri, 20 Jul 2007 12:26:39 +0300 Subject: [Nagiosplug-devel] check_disk plugin problems In-Reply-To: <46A07A83.7010209@mailing.kaufland-informationssysteme.com> References: <469F7255.8050906@sun-fish.com> <46A07A83.7010209@mailing.kaufland-informationssysteme.com> Message-ID: <46A07FCF.1010103@sun-fish.com> Hello, Matthias Eble wrote: > Stefan Lambrev schrieb: >> Hello, >> >> I'm having some strange problems with nagios' check_disk plugin under >> FreeBSD i386 7-current. >> >> 1st if I use -p /some/path the plugin exits with segmentation fault - >> http://cheffo.freebsd-bg.org/ktrace.out provided if someone knows >> how to use ktrace/kdump >> >> 2nd problem is "-c" option does not work at all. >> Here is example: >> >> /usr/local/libexec/nagios/check_disk -c 99% >> DISK OK - free space: / 3792 MB (83% inode=99%); /dev 0 MB (0% >> inode=-); /tmp 4559 MB (99% inode=99%); /usr 91711 MB (97% >> inode=98%); /var 18101 MB (99% inode=99%);| /=769MB;;;0;4958 >> /dev=0MB;;;0;0 /tmp=2MB;;;0;4958 /usr=2006MB;;;0;101867 >> /var=144MB;;;0;19832 >> >> it is quite strange that -w is working may be they work in different >> ways ? >> >> Thanks in advance. >> >> P.S. I'm not subscribed so please CC me on replies. >> > Hi Stefan, > > never used ktrace.. However. Which version of the plugins are you using? > I have a freebsd 6.2 here and everything works fine. -w should work > exactly like -c. > I successfully ran the test cases for the latest snapshot on my > freebsd box, too. > Could you send an output of the segfaulting call with -vvvv turned on? > > Matthias I'm using check_disk (nagios-plugins 1.4.9) 1.91 /usr/local/libexec/nagios/check_disk -c 30% -w 40% -vvvv -p /tmp For /tmp, used_pct=1 free_pct=99 used_units=2 free_units=4559 total_units=4958 used_inodes_pct=1 free_inodes_pct=99 Freespace_units result=0 Freespace% result=0 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 zsh: segmentation fault (core dumped) /usr/local/libexec/nagios/check_disk -c 30% -w 40% -vvvv -p /tmp I can confirm that this plugin works ok with FreeBSD 6.2 (amd64/i386) -p option work under FreeBSD 7 amd64, but does not under i386 version. -c is not working on FreeBSD 7 (i386/amd64), but only FreeBSD 6.X The main differences between FreeBSD 6 and FreeBSD 7 are gcc and libc :) (6) gcc version 3.4.6 [FreeBSD] 20060305 (7) gcc version 4.2.0 20070514 [FreeBSD] I'm not sure what is the difference between libc 6 & 7, but all other apps that I tested works without a problems. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From matthias.eble at mailing.kaufland-informationssysteme.com Sun Jul 22 19:08:18 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sun, 22 Jul 2007 19:08:18 +0200 Subject: [Nagiosplug-devel] printf calls in library functions Message-ID: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> Hi list, we have an item in the Bugtracker (#1681516) that claims, that the output for various checks is too verbose due to printf statements in some library functions (for example netutils and sslutils). Example: > ./check_http -H foo -S >Name or service not known >HTTP CRITICAL - Unable to open TCP socket I'd like to know what you think about printing to stdout/stderr in a library. I see two possibilities to solve the issue: 1st: Always die on an error in a library (accepting the lack of the plugin name string in the output. 2nd: Add a verbosity argument to the library functions Maybe both could be combined and written down in the guidelines. What do you think? Btw: Why are the sslutils, etc located in the plugin directory? Matthias From dermoth at aei.ca Sun Jul 22 19:35:17 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 22 Jul 2007 13:35:17 -0400 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> Message-ID: <46A39555.4050604@aei.ca> On 22/07/07 01:08 PM, Matthias Eble wrote: > Hi list, > > we have an item in the Bugtracker (#1681516) that claims, that the > output for various checks is too verbose due to printf statements in > some library functions (for example netutils and sslutils). > > Example: > > ./check_http -H foo -S > >Name or service not known > >HTTP CRITICAL - Unable to open TCP socket > > > I'd like to know what you think about printing to stdout/stderr in a > library. I see two possibilities to solve the issue: > > 1st: Always die on an error in a library (accepting the lack of the > plugin name string in the output. > 2nd: Add a verbosity argument to the library functions > > Maybe both could be combined and written down in the guidelines. What do > you think? Btw: Why are the sslutils, etc located in the plugin directory? How problematic is it? Nagios and NRPE doesn't care about stderr. Also it's easy to add a 2>/dev/null when running it from another script/plug-in. For the solutions, can't we just redirect STDERR to /dev/null when the verbose level is 0? (That would require adding the -v switch to plugins that don't have one yet...). Thomas From matthias.eble at mailing.kaufland-informationssysteme.com Sun Jul 22 21:38:42 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sun, 22 Jul 2007 21:38:42 +0200 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A39555.4050604@aei.ca> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A39555.4050604@aei.ca> Message-ID: <46A3B242.1040806@mailing.kaufland-informationssysteme.com> > How problematic is it? Nagios and NRPE doesn't care about stderr. Also > it's easy to add a 2>/dev/null when running it from another script/plug-in. > > For the solutions, can't we just redirect STDERR to /dev/null when the > verbose level is 0? (That would require adding the -v switch to plugins > that don't have one yet...). We could do so, if all output came on stderr. As far as I've seen, some output is even explicitely put on stdout like: ERR_print_errors_fp (stdout); And printfs like in the tracker aren't written to stderr, either. What we could do is that we could generally print library output to stderr. But that might confuse people seeing different output in the gui and the shell. Matthias From ton.voon at altinity.com Mon Jul 23 12:20:24 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Jul 2007 11:20:24 +0100 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> Message-ID: Hi, On 22 Jul 2007, at 18:08, Matthias Eble wrote: > we have an item in the Bugtracker (#1681516) that claims, that the > output for various checks is too verbose due to printf statements in > some library functions (for example netutils and sslutils). > > Example: >> ./check_http -H foo -S >> Name or service not known >> HTTP CRITICAL - Unable to open TCP socket > > > I'd like to know what you think about printing to stdout/stderr in a > library. I see two possibilities to solve the issue: > > 1st: Always die on an error in a library (accepting the lack of the > plugin name string in the output. > 2nd: Add a verbosity argument to the library functions My initial feeling is to not use stderr at all and all errors go to stdout. Usually when you have errors in the library, it is left to the calling program can decide what to do with the error. But in our case, I think we could always exit with UNKNOWN and the error message. This would also have the advantage of having a consistent error message and simpler programming at the plugin level. For warnings type messages, it would make sense to use the verbosity flag (though I'm not sure of any examples right now). Comments? > Btw: Why are the sslutils, etc located in the plugin directory? Historical. We had issues compiling from an external directory before. I'm happy to have them moved to lib/ now that the infrastructure is in place to allow this easily. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Jul 23 12:44:30 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Jul 2007 11:44:30 +0100 Subject: [Nagiosplug-devel] Plugin licensing In-Reply-To: <20070719110207.GC14961@openfusion.com.au> References: <384329B8D7108B45A3064FB38FCF267B0E1981@aristotle.servprise.office> <200707190803.37144.seanius@seanius.net> <20070719110207.GC14961@openfusion.com.au> Message-ID: <72B198CA-901E-455B-ACA0-85BBFE86CA1B@altinity.com> On 19 Jul 2007, at 12:02, Gavin Carr wrote: > Just to add another wrinkle to the discussion, on the perl side of > things > the Nagios::Plugin perl module (and hence plugins that use _that_, I > guess) are licensed under the standard Perl licence (that was you, > Ton, > right?), which is to say it's dual-licensed (at the user's choice) > under > both GPL and the Perl Artistic Licence. My IANAL understanding is that > the Perl Artistic Licence is somewhere between the GPL and BSD > licences > in terms of restrictions and freedom? I have to admit, I don't get the differences between the Artistic license and the GPL. FSF suggest not to use the Artistic license except for perl code: http://www.fsf.org/licensing/licenses/index_html#PerlLicense And in their FAQ, they explicitly say that using GPL'd perl modules mean the overall program must be GPL'd: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL I don't have a firm opinion on the licencing of the perl modules. Off the record, I think there's less of a concern with perl (or indeed, any interpreted language) because, while you may not have the right to change the code, the ability to do so is possible (which is not the case with binary distributions). Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jul 23 15:18:54 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 23 Jul 2007 15:18:54 +0200 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> Message-ID: <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> > My initial feeling is to not use stderr at all and all errors go to > stdout. Makes sense to me, too - If the output is guaranteed to be formated properly. > Usually when you have errors in the library, it is left to the > calling program can decide what to do with the error. Problem is, that the return value needs to be a struct with a numeric and a string value in that case. > But in our > case, I think we could always exit with UNKNOWN and the error > message. This would also have the advantage of having a consistent > error message and simpler programming at the plugin level. If I got it right, the definition of UNKNOWN in the guidelines won't let us do so in every case(strictly speaking). We could introduce a global variable containing the short upper case service name (eg DISK)to also print it in library functions. This might, but hopefully won't affect translation strings. > For warnings type messages, it would make sense to use the verbosity > flag (though I'm not sure of any examples right now). I can't remember to having seen some cases where this would be needed, too. >> Btw: Why are the sslutils, etc located in the plugin directory? > > Historical. We had issues compiling from an external directory > before. I'm happy to have them moved to lib/ now that the > infrastructure is in place to allow this easily. Fine. Let's move them after switching to svn. Matthias From Christoph.Kroeger at heimeier.com Mon Jul 23 15:33:37 2007 From: Christoph.Kroeger at heimeier.com (Christoph Kroeger) Date: Mon, 23 Jul 2007 15:33:37 +0200 Subject: [Nagiosplug-devel] working with inside and outside ranges Message-ID: <20070723153337208.00000003288@THE345> Hello, I'm currently working on a plug-in to check the cpu usage of an NETAPP FS270 and all appliances which are using the same SNMP MIB. I have read the developer guidelines on the pages of http://nagiosplug.sourceforge.net/developer-guidelines.html and found a paragraph about ranges. I don't understand the part where the usage of the @ is described. My understanding is the following: * If I give my program the parameters -w 70 and -c 80, then I will get a warning alert if the cpu usage is between 70 and 80 and a critical alert if the usage is upper 80%. * Now my program gets a range for warning like 60:70 and range for critical like 80:90. The zones for an OK state are now between 60 and 70 and 80 and 90. Is the area outside the ranges warning or critical? * If the range are lead by an @ the program has to post a warning between 60 and 70 and an critical alert between 80 and 90. Am I right with my understanding until now? Thanks for helping, Christoph Kroeger __ Christoph Kr?ger Fachinformatiker -Systemintegration- IT-Professional with specialization on system integration Tel.: 02943 891-371 Fax.: 02943 891-9371 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jul 23 16:27:21 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 23 Jul 2007 16:27:21 +0200 Subject: [Nagiosplug-devel] working with inside and outside ranges In-Reply-To: <20070723153337208.00000003288@THE345> References: <20070723153337208.00000003288@THE345> Message-ID: <46A4BAC9.9090205@mailing.kaufland-informationssysteme.com> Christoph Kroeger schrieb: > Hello, > > > > I?m currently working on a plug-in to check the cpu usage of an NETAPP > FS270 and all appliances which are using the same SNMP MIB. I have read > the developer guidelines on the pages of > http://nagiosplug.sourceforge.net/developer-guidelines.html and found a > paragraph about ranges. I don?t understand the part where the usage of > the @ is described. My understanding is the following: > > > > * If I give my program the parameters ?w 70 and ?c 80, then I will > get a warning alert if the cpu usage is between 70 and 80 and a > critical alert if the usage is upper 80%. In this case ranges 0:70 and 0:80 are assumed. State is OK if the value is inside both ranges (0-69), warning if value is outside warn and inside crit. > * Now my program gets a range for warning like 60:70 and range for > critical like 80:90. The zones for an OK state are now between 60 > and 70 and 80 and 90. Is the area outside the ranges warning or > critical? The area outside both ranges would be critical. But 65 would be critical either. There will be no ok state with these ranges. OK Zone is 60-70 if you define define -w 60:70 -c 60:80. 60-70 is inside both ranges here. > * If the range are lead by an @ the program has to post a warning > between 60 and 70 and an critical alert between 80 and 90. That's correct. But you might want to take care for the upper limit. > Fachinformatiker -Systemintegration- What a cool ausbildungsberuf ^^ Matthias From ton.voon at altinity.com Mon Jul 23 16:56:11 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Jul 2007 15:56:11 +0100 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> Message-ID: <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> On 23 Jul 2007, at 14:18, Matthias Eble wrote: >> But in our >> case, I think we could always exit with UNKNOWN and the error >> message. This would also have the advantage of having a consistent >> error message and simpler programming at the plugin level. > If I got it right, the definition of UNKNOWN in the guidelines > won't let > us do so in every case(strictly speaking). Good point that the exit is not always UNKNOWN. I'm happy that the exit code is appropriate for the failure. > We could introduce a global variable containing the short upper case > service name (eg DISK)to also print it in library functions. > This might, but hopefully won't affect translation strings. I agree about the short name. Some plugins change the short name (such as check_tcp), but I think it is reasonable to assume that the short name is set before calling various common functions. I'm not too worried about the short name as this is not part of the interface with Nagios. > Let's move them after switching to svn. Sigh. I think I'm still the bottleneck here. I'll spend sometime this evening trying to work out how tinderbox talks to CVS and amend that to SVN. Regardless of the outcome, I'll do a re-import of the latest CVS data and then we can make the svn repo live for tomorrow. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Mon Jul 23 17:37:16 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 23 Jul 2007 17:37:16 +0200 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> Message-ID: <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> >> If I got it right, the definition of UNKNOWN in the guidelines >> won't let >> us do so in every case(strictly speaking). > > Good point that the exit is not always UNKNOWN. I'm happy that the > exit code is appropriate for the failure. So I'd say that I'll change the libs from return/printf to die where appropriate in the next days. > >> We could introduce a global variable containing the short upper case >> service name (eg DISK)to also print it in library functions. >> This might, but hopefully won't affect translation strings. > > I agree about the short name. Some plugins change the short name > (such as check_tcp), but I think it is reasonable to assume that the > short name is set before calling various common functions. I'm not > too worried about the short name as this is not part of the interface > with Nagios. Will look at this, too. >> Let's move them after switching to svn. > > Sigh. I think I'm still the bottleneck here. I'll spend sometime this > evening trying to work out how tinderbox talks to CVS and amend that > to SVN. Regardless of the outcome, I'll do a re-import of the latest > CVS data and then we can make the svn repo live for tomorrow. No need to hurry.. Btw. The cvs links in the webgui don't work anymore :( We might want to create a list with long term goals. Like the new performance data format, N::P inclusion, etc. A Wiki would be neat for that (this might also be an approach for the extended docs) - maybe a part of nagios-community.org? Matthias From ton.voon at altinity.com Mon Jul 23 17:45:49 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 23 Jul 2007 16:45:49 +0100 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> Message-ID: <79B0FF04-3F0E-44AB-A4A3-883B155927B8@altinity.com> On 23 Jul 2007, at 16:37, Matthias Eble wrote: > No need to hurry.. > Btw. The cvs links in the webgui don't work anymore :( Ssshhh - those links never worked.... > We might want to create a list with long term goals. Like the new > performance data format, N::P inclusion, etc. > A Wiki would be neat for that (this might also be an approach for the > extended docs) - maybe a part of nagios-community.org? Good idea. I was thinking I need to get better managing all the things that are happening. I was going to use nagiosplugins.org because it is specifically Nagios Plugins related, but I hate the editting format at the moment. Benoit has been promising me a wiki style editing facility, but it hasn't appeared yet. I'll give him a week, then I'll try on the nagioscommunity site instead (that should get him fired up...) Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From holger at CIS.FU-Berlin.DE Mon Jul 23 19:11:49 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 23 Jul 2007 19:11:49 +0200 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> Message-ID: <20070723171149.GF17833409@CIS.FU-Berlin.DE> * Matthias Eble [2007-07-23 17:37]: > >> If I got it right, the definition of UNKNOWN in the guidelines > >> won't let us do so in every case(strictly speaking). > > > > Good point that the exit is not always UNKNOWN. I'm happy that the > > exit code is appropriate for the failure. > > So I'd say that I'll change the libs from return/printf to die where > appropriate in the next days. IMO, doing so is fine within library functions where we can (more or less safely) assume that no caller will ever want to handle any error condition within that function in any different way than exiting immediately. In this case, the advantage of dying within the library function is that the caller won't have to check for success, which is nice. I'd document that by not returning success/failure from such functions at all (that is, by returning void if the function doesn't return other stuff). Obviously, in this case the dying function must print the reason for the suicide to STDOUT itself. However, if the caller might want to handle some error condition himself, I'd never die within that function, as all callers will then always have to check for success anyway. Another reason not to die might be that the desired exit status might depend on the context. In these cases, I'd only return failure and make the error message available to the caller by using some global errno(3)-like variable or some errstr() function which uses a static errno within the library, for example. (If we extended our libraries to provide the caller with a struct holding the library state, this struct could hold the errno variable, but this would of course require more work.) Whether or not library functions should optionally provide verbose output and how to implement that seems to be an unrelated issue to me. (I'd simply use a global variable, initialized to "no verbose output" optionally modifiable by the caller.) > >> We could introduce a global variable containing the short upper case > >> service name (eg DISK)to also print it in library functions. > >> This might, but hopefully won't affect translation strings. > > > > I agree about the short name. Some plugins change the short name > > (such as check_tcp), but I think it is reasonable to assume that the > > short name is set before calling various common functions. I'm not > > too worried about the short name as this is not part of the interface > > with Nagios. I never really understood why it's printed at all. That's another story, but as my idea of simply removing it from the plugin output would make things easier here, I'll take the chance to start another thread regarding this question later this evening :-) Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From holger at CIS.FU-Berlin.DE Tue Jul 24 01:12:52 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 24 Jul 2007 01:12:52 +0200 Subject: [Nagiosplug-devel] Plugin output format Message-ID: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> The development guidelines state: | Output should be in the format: | | SERVICE STATUS: Information text [ http://nagiosplug.sf.net/developer-guidelines.html#AEN34 ] I don't remember having seen exactly this format, but, as you all know, most plugin output is in the format "SERVICE STATUS - Information text". Some output is in some arbitrary other format. Anyway, my question is: Why do we print out SERVICE and STATUS at all? AFAICS, when a plugin is called via Nagios in order to perform a service check, adding SERVICE and STATUS to the output is completely redundant. At least, I'm not aware of a place where Nagios prints the plugin output without (being able to) also printing the service_description and the symobolic name of the exit status the plugin returned. And when a plugin is called on the command line for testing, I see no use in printing out the SERVICE string, either. If I call check_http, I know it does HTTP. However, for debugging, it does of course make sense to print out the STATUS so that the user won't have to check and interpret the exit code manually. But IMO it would be perfectly reasonable to print such debug output only when called with "--verbose", not in production. The reason I'm concerned about this is that the space for plugin output is sometimes scarce, so that we should try to keep the output "short and to the point" (as the guide states) and not waste space with redundant information. For example, when sending alerts via SMS, the number of characters which can be sent is sometimes limited. If the notification message exceeds this number, the alert will at best be truncated, or, at worst, the SMS software will refuse to send the alert. To give another example, we use nsc[*], a curses-based tool which displays the status of all monitored services using one line per service. Assuming an 80-character-width terminal, the line for a CRITICAL LDAP service looks similar to this one: 0---------1---------2---------3---------4---------5---------6---------7--------- Host Service Status Upd/Chg Try Plugin Output foobar LDAP CRITICAL 12s/4m 3/3 LDAP CRITICAL - interesting plu Here, some of the "interesting plugin output" is truncated. Yes, I could resize my XTerm, but still, repeating the SERVICE and STATUS within the plugin output seems neither nice nor useful to me. While the standard web interface normally won't truncate the plugin output, I'd personally still prefer not to display duplicated information within that field in the web interface, either. At least, I don't see any benefit in doing so. So, my suggestion would be to change the standard plugin output to print only the "Information text" and to print "STATUS: Information text" when the plugin was called with "--verbose". Opinions? Holger [*] http://nsc-gothix.sf.net/ -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From ton.voon at altinity.com Tue Jul 24 02:52:05 2007 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 24 Jul 2007 01:52:05 +0100 Subject: [Nagiosplug-devel] Switching to svn In-Reply-To: <804160344192334BB21922E8082EA6C0A7145B@seaex01.180solutions.com> References: <46641BF8.6090202@mailing.kaufland-informationssysteme.com><2BCAFA09-CBC8-4D2D-BFE6-B73D1F0D2DDA@altinity.com> <5308DA16-7FE3-417A-BE69-A3862B011BDC@altinity.com> <804160344192334BB21922E8082EA6C0A7145B@seaex01.180solutions.com> Message-ID: On 9 Jul 2007, at 17:08, Thomas Guyot-Sionnest wrote: > I have to change my tinderbox script to update from SVN but that's > only a > one word change :) I'm ready when you are. > Finally done! SVN is now live for the Nagios Plugins project! I've left CVS on for now but followed Thomas' suggestion of adding a warning. In fact, the configure script will just exit if you use the CVS HEAD version. Will probably switch CVS access off in a month's time. I've run a snapshot and this is using the SVN repository now. All the various links I think have been updated - let me know if you spot any problems. I expect a few teething problems in the next few weeks. I've updated Tinderbox and fixed the URLs so they actually point to the correct ViewCV links on Sourceforge too (awful hack of Tinderbox scripts...). Also, the emails have been updated so that commits are emailed as usual. Finally, I've reconsidered about restricting parts of the repository after reading the SVN guide: http://svnbook.red-bean.com/nightly/en/ svn-book.html#svn.serverconfig.pathbasedauthz. So now everyone in the team has access to change any code in any of the projects. I'll see how that goes. For those that don't know about subversion, a basic guide is here: http://nagiosplugins.org/index.php? option=com_easyfaq&task=view&id=11&Itemid=29 Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Tue Jul 24 15:49:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jul 2007 06:49:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1532272 ] Warnings Message-ID: Bugs item #1532272, was opened at 2006-08-01 10:48 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1532272&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: CVS >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Ciro Iriarte (cyruspy) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings Initial Comment: source='utils_base.c' object='utils_base.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../intl -I../plugins -g -c utils_base.c cc: Warning: utils_base.c, line 108: In this statement, "0" of type "int", is being converted to "pointer to struct thresholds_struct". (cvtdiftypes) if (*my_thresholds > 0) { /* Not sure why, but sometimes could be -1 */ ------------^ source='netutils.c' object='netutils.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c netutils.c cc: Warning: netutils.c, line 228: In this statement, "0" of type "int", is being converted to "pointer to int". (cvtdiftypes) if(sd < 0){ -------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_http check_http.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_ntp.c' object='check_ntp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_ntp.c cc: Warning: check_ntp.c, line 524: In this statement, performing pointer arithmetic on a pointer to void or a pointer to function is not allowed. The compiler will treat the type as if it were pointer to char. (badptrarith) memcpy((void*)peers+peer_offset, (void*)req.data, sizeof(ntp_assoc_status_pair)*npeers); -----------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_ntp check_ntp.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lm -lssl -lcrypto cc -g -o check_ntp check_ntp.o netutils.o utils.o source='check_smtp.c' object='check_smtp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_smtp.c cc: Warning: check_smtp.c, line 354: In this statement, the referenced type of the pointer value "((const char ...)("no authuser specified, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("no authuser specified, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 359: In this statement, the referenced type of the pointer value "((const char ...)("no authpass specified, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("no authpass specified, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 369: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after AUTH LOGIN, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after AUTH LOGIN, \n"); ------------------------------------------------^ cc: Warning: check_smtp.c, line 379: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after AUTH LOGIN, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after AUTH LOGIN, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 392: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after sending authuser, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after sending authuser, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 401: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after authuser, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after authuser, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 413: In this statement, the referenced type of the pointer value "((const char ...)("recv() failed after sending authpass, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("recv() failed after sending authpass, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 422: In this statement, the referenced type of the pointer value "((const char ...)("invalid response received after authpass, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("invalid response received after authpass, "); ------------------------------------------------^ cc: Warning: check_smtp.c, line 429: In this statement, the referenced type of the pointer value "((const char ...)("only authtype LOGIN is supported, "))" is const, but the referenced type of the target of this assignment is not. (notconstqual) error_msg = _("only authtype LOGIN is supported, "); --------------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_smtp check_smtp.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_smtp check_smtp.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_ssh.c' object='check_ssh.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_ssh.c /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_ssh check_ssh.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_ssh check_ssh.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_tcp.c' object='check_tcp.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_tcp.c cc: Warning: check_tcp.c, line 498: In this statement, "np_escaped_string(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) server_send = np_escaped_string(optarg); --------------------------------^ cc: Warning: check_tcp.c, line 518: In this statement, "np_escaped_string(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) server_quit = np_escaped_string(optarg); --------------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_tcp check_tcp.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto cc -g -o check_tcp check_tcp.o sslutils.o netutils.o utils.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv -lssl -lcrypto source='check_procs.c' object='check_procs.o' libtool=no DEPDIR=.deps depmode=tru64 /bin/ksh ../depcomp cc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -c check_procs.c cc: Warning: check_procs.c, line 192: In this statement, "base_name(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes) procprog = base_name(procprog); ------------------------^ /bin/ksh ../libtool --tag=CC --mode=link cc -g -L. -o check_procs check_procs.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lssl -lcrypto cc -g -o check_procs check_procs.o utils.o popen.o -L/usr/users/iriartec/src/nagios-plugins-HEAD-200607312352/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lssl -lcrypto ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-24 15:49 Message: Logged In: YES user_id=1694341 Originator: NO Hi Ciro, I'm setting this item to pending meaning that it will get deleted if you won't send a comment in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-07-16 17:41 Message: Logged In: YES user_id=1694341 Originator: NO Hi Ciro, are you still seeing this with recent releases? Is your platform tru64? Have you tried using gcc? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1532272&group_id=29880 From noreply at sourceforge.net Tue Jul 24 15:50:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jul 2007 06:50:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1463846 ] check_procs via nrpe - proc count Message-ID: Bugs item #1463846, was opened at 2006-04-03 23:43 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1463846&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: JamesMontrois (lbruun) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs via nrpe - proc count Initial Comment: nrpe uses the popen to execute the check command. This means that a new shell will be spawned. check_procs should take care to ignore this process. If not then if check_procs is used with the -a option it will count one too many processes it its count. At the moment when nrpe executes check_procs I see two processes on my system: ../libexec/check_procs ..... foo sh -c ../libexec/check_procs ...... foo If my check_procs -a argument is "foo" then both of the above will be matched. Only the first will be caught by the ignore self catch. If I go back to an old version of check_procs that uses the old method to ignore self (compare procname against string constant "check_procs") and the old method to extract the basename (a strtok() loop) then I have no problem. I'm not saying those fixes should be undone. It's just an observation. I must admit I cannot really see how this has worked in the past... but it did. One obvious fix to the problem would be to test not only against mypid but also against myppid. I'm on Solaris but I doubt there's any difference between Solaris and Linux in this respect. Lars ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-24 15:50 Message: Logged In: YES user_id=1694341 Originator: NO Hi James, I'm setting this item to pending meaning that it will get deleted if you won't send a comment in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-07-15 16:23 Message: Logged In: YES user_id=1694341 Originator: NO Hi Lars, is this still an issue? I tried this with the latest cvs and the problem doesn't seem to occur. Yet I could imagine also ignoring processes where ppid is check_procs' pid (to ignore the ps command called by check_procs). Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1463846&group_id=29880 From noreply at sourceforge.net Tue Jul 24 17:34:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jul 2007 08:34:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1753164 ] configure script fails to recognise radius libs Message-ID: Bugs item #1753164, was opened at 2007-07-13 05:22 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753164&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arya (alphamega) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails to recognise radius libs Initial Comment: There's a good chance this has already been fixed in CVS (and apologies if this is the case), but just in case it hasnt.... It looks like the configure script doesnt detect the radiusclient libs, even though they are present. OS: Solaris 10 Plugins Version: 1.4.9 Radiusclient Version: 0.3.2 [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # echo $PATH /usr/local/bin:/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/dt/bin:/usr/local/bin:/usr/local/sbin:/usr/sfw/bin:/usr/sfw/sbin:/usr/ccs/bin:/usr/local/ssl/bin:/opt/64/bin:/opt/64/sbin:/opt/SUNWspro/bin:/usr/ucb:/usr/local/BerkeleyDB.4.4/bin:/usr/local/apache2/bin:/usr/local/mysql/bin/:/usr/local/net-snmp/bin:/usr/local/net-snmp/sbin:/usr/local/openldap/bin:/usr/local/openldap/sbin:/usr/local/php5/bin:/usr/local/radiusclient/sbin:/usr/local/rrdtool/bin [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # crle Configuration file [version 4]: /var/ld/ld.config Default Library Path (ELF): /lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.4/lib:/usr/local/apache2/lib:/usr/local/mysql/lib/mysql:/usr/local/net-snmp/lib:/usr/local/openldap/lib:/usr/local/php5/lib:/usr/local/radiusclient/lib:/usr/local/rrdtool/lib:/usr/lib:/usr/sfw/lib Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.4/lib:/usr/local/apache2/lib:/usr/local/mysql/lib/mysql:/usr/local/net-snmp/lib:/usr/local/openldap/lib:/usr/local/php5/lib:/usr/local/radiusclient/lib:/usr/local/rrdtool/lib:/usr/lib:/usr/sfw/lib [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # cat configure-script.sh export CPPFLAGS="-I/usr/local/radiusclient/include -I/usr/local/openldap/include" export LDFLAGS="-L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib" export CC=gcc ./configure --prefix=/usr/local/nagios [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # ./configure-script.sh checking for libpq-fe.h... no checking for rc_read_config in -lradiusclient... no configure: WARNING: Skipping radius plugin configure: WARNING: install radius libs to compile this plugin (see REQUIREMENTS). checking for main in -lldap... yes checking for ldap_set_option... yes checking for ldap_init... yes checking for ldap_set_option... (cached) yes checking for ldap_get_option... yes checking for ldap_start_tls_s... yes config.status: creating po/Makefile --with-apt-get-command: --with-ping6-command: --with-ping-command: /usr/sbin/ping -n -s %s 56 %d --with-ipv6: yes --with-mysql: /usr/local/mysql/bin//mysql_config --with-openssl: yes --with-gnutls: no --with-perl: /usr/local/bin/perl --with-cgiurl: /nagios/cgi-bin --with-trusted-path: /bin:/sbin:/usr/bin:/usr/sbin [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9] # cd /usr/local [root at cbr-x2200-02 /usr/local] # ls -ld radiusclient* 2 lrwxrwxrwx 1 root root 19 Jul 12 16:07 radiusclient -> radiusclient-0.3.2/ 2 drwxr-xr-x 7 root root 512 Jul 12 15:54 radiusclient-0.3.2 [root at cbr-x2200-02 /usr/local] # du -a radiusclient/ 6 radiusclient/include/includes.h 24 radiusclient/include/radiusclient.h 4 radiusclient/include/messages.h 2 radiusclient/include/pathnames.h 38 radiusclient/include 154 radiusclient/lib/libradiusclient.so.0.0.1 2 radiusclient/lib/libradiusclient.so.0 2 radiusclient/lib/libradiusclient.so 2 radiusclient/lib/libradiusclient.la 224 radiusclient/lib/libradiusclient.a 386 radiusclient/lib 52 radiusclient/sbin/radlogin 24 radiusclient/sbin/radstatus 26 radiusclient/sbin/radacct 22 radiusclient/sbin/radexample 126 radiusclient/sbin 2 radiusclient/etc/radiusclient/servers 2 radiusclient/etc/radiusclient/issue 2 radiusclient/etc/radiusclient/port-id-map 6 radiusclient/etc/radiusclient/radiusclient.conf 14 radiusclient/etc/radiusclient/dictionary 26 radiusclient/etc/radiusclient/dictionary.ascend 4 radiusclient/etc/radiusclient/dictionary.compat 2 radiusclient/etc/radiusclient/dictionary.merit 60 radiusclient/etc/radiusclient 62 radiusclient/etc 18 radiusclient/doc/instop.html 20 radiusclient/doc 634 radiusclient Once I comment out some lines in configure (lines 20994 - 21003): #if test "$ac_cv_lib_radiusclient_rc_read_config" = "yes"; then EXTRAS="$EXTRAS check_radius" RADIUSLIBS="-lradiusclient" #else # { echo "$as_me:$LINENO: WARNING: Skipping radius plugin" >&5 #echo "$as_me: WARNING: Skipping radius plugin" >&2;} # { echo "$as_me:$LINENO: WARNING: install radius libs to compile this plugin (see REQUIREMENTS)." >&5 #echo "$as_me: WARNING: install radius libs to compile this plugin (see REQUIREMENTS)." >&2;} #fi I can re-run ./configure-script.sh. Obviously configure will still report this: checking for rc_read_config in -lradiusclient... no However, it pretends it's there, and when I run a 'make', viola, it works. To install radiusclient, I did a simple "./configure --prefix=/usr/local/radiusclient && make && make install" -- which works. [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9/plugins] # make check_radius if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT check_radius.o -MD -MP -MF ".deps/check_radius.Tpo" -c -o check_radius.o check_radius.c; \ then mv -f ".deps/check_radius.Tpo" ".deps/check_radius.Po"; else rm -f ".deps/check_radius.Tpo"; exit 1; fi In file included from check_radius.c:42: common.h:191: warning: static declaration of 'floorf' follows non-static declaration if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT netutils.o -MD -MP -MF ".deps/netutils.Tpo" -c -o netutils.o netutils.c; \ then mv -f ".deps/netutils.Tpo" ".deps/netutils.Po"; else rm -f ".deps/netutils.Tpo"; exit 1; fi In file included from netutils.c:36: common.h:191: warning: static declaration of 'floorf' follows non-static declaration if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/local/ssl/include -I/usr/local/radiusclient/include -I/usr/local/openldap/include -D_REENTRANT -I/usr/local/ssl/include -g -O2 -MT utils.o -MD -MP -MF ".deps/utils.Tpo" -c -o utils.o utils.c; \ then mv -f ".deps/utils.Tpo" ".deps/utils.Po"; else rm -f ".deps/utils.Tpo"; exit 1; fi In file included from utils.c:17: common.h:191: warning: static declaration of 'floorf' follows non-static declaration /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib -L. -L/usr/local/ssl/lib -o check_radius check_radius.o netutils.o utils.o ../lib/libnagiosplug.a ../gl/libgnu.a -lnsl -lsocket -lresolv -lradiusclient -lnsl -lsocket mkdir .libs gcc -g -O2 -o check_radius check_radius.o netutils.o utils.o -L/usr/local/radiusclient/lib -L/usr/local/openldap/lib -L/usr/local/src/nagios-plugins-1.4.9/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../gl/libgnu.a -lresolv /usr/local/radiusclient/lib/libradiusclient.so -lcrypt -lnsl -lsocket -R/usr/local/radiusclient/lib -R/usr/local/radiusclient/lib -R/usr/local/openldap/lib [root at cbr-x2200-02 /usr/local/src/nagios-plugins-1.4.9/plugins] # ldd ./check_radius libresolv.so.2 => /lib/libresolv.so.2 libradiusclient.so.0 => /usr/local/radiusclient/lib/libradiusclient.so.0 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libc.so.1 => /lib/libc.so.1 libgen.so.1 => /lib/libgen.so.1 libmp.so.2 => /lib/libmp.so.2 libmd5.so.1 => /lib/libmd5.so.1 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libm.so.2 => /lib/libm.so.2 I suspect what's happening here is that configure is a little too optimistic about how configured the radiusclient installation is :-) ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-07-24 17:34 Message: Logged In: YES user_id=1694341 Originator: NO does your installed radiusclient library actually have a function called rc_read_config? Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1753164&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jul 24 18:42:38 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 24 Jul 2007 18:42:38 +0200 Subject: [Nagiosplug-devel] printf calls in library functions In-Reply-To: <20070723171149.GF17833409@CIS.FU-Berlin.DE> References: <46A38F02.3090405@mailing.kaufland-informationssysteme.com> <46A4AABE.7000307@mailing.kaufland-informationssysteme.com> <59177DD5-A392-4915-B8FE-FB11AA79122F@altinity.com> <46A4CB2C.5020906@mailing.kaufland-informationssysteme.com> <20070723171149.GF17833409@CIS.FU-Berlin.DE> Message-ID: <46A62BFE.3040200@mailing.kaufland-informationssysteme.com> Hi Holger, > I'd document that by not returning success/failure from such > functions at all (that is, by returning void if the function doesn't > return other stuff). Obviously, in this case the dying function must > print the reason for the suicide to STDOUT itself. I don't know if defining this for a complete function is possible. Of course it would be clearer. > However, if the caller might want to handle some error condition > himself, I'd never die within that function, as all callers will then > always have to check for success anyway. Another reason not to die > might be that the desired exit status might depend on the context. In > these cases, I'd only return failure and make the error message > available to the caller by using some global errno(3)-like variable or > some errstr() function which uses a static errno within the library, for > example. (If we extended our libraries to provide the caller with a > struct holding the library state, this struct could hold the errno > variable, but this would of course require more work.) Good idea. > Whether or not library functions should optionally provide verbose > output and how to implement that seems to be an unrelated issue to me. > (I'd simply use a global variable, initialized to "no verbose output" > optionally modifiable by the caller.) To me it would be fine, too, if we only put sth. out in libraries, when a global verbosity variable variable is set. The plugin output could then be handled with some errstr()-like functionality. Matthias From matthias.eble at mailing.kaufland-informationssysteme.com Tue Jul 24 18:47:54 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 24 Jul 2007 18:47:54 +0200 Subject: [Nagiosplug-devel] Plugin output format In-Reply-To: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> References: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> Message-ID: <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> > So, my suggestion would be to change the standard plugin output to print > only the "Information text" and to print "STATUS: Information text" when > the plugin was called with "--verbose". Opinions? Hi again, long mail, short answer from my side: I agree. But somehow I like the status string even though I can't find an argument for that. Yet I'd cast my vote to remove both and declare them optional in the guidelines. Matthias Btw. check_http and check_procs seem to use the : instead - at least in some cases :) From Thomas at zango.com Tue Jul 24 19:11:08 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 24 Jul 2007 10:11:08 -0700 Subject: [Nagiosplug-devel] Plugin output format In-Reply-To: <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> References: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> Message-ID: <804160344192334BB21922E8082EA6C0B213ED@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Matthias Eble > Sent: July 24, 2007 12:48 > To: Nagios Plugins Development > Subject: Re: [Nagiosplug-devel] Plugin output format > > > > So, my suggestion would be to change the standard plugin output to print > > only the "Information text" and to print "STATUS: Information text" when > > the plugin was called with "--verbose". Opinions? > > Hi again, > > long mail, short answer from my side: > I agree. But somehow I like the status string even though I can't find > an argument for that. Yet I'd cast my vote to remove both and declare > them optional in the guidelines. I like the status line too :) Why not do the opposite and add a --quiet option. --verbose is already used for debugging, so that would mean we'd need to change all --verbose into --debug or something similar. Also since we'll likely want the sort option too, it might be worth checking how many plugins use -q, -Q, -d and -D... Alternatively we could just start a new tree and commit all changes that break compatibility for an eventual NP 2.0, making it clear that it's not backwards-compatible. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Tue Jul 24 19:30:09 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 24 Jul 2007 19:30:09 +0200 Subject: [Nagiosplug-devel] Plugin output format In-Reply-To: <804160344192334BB21922E8082EA6C0B213ED@seaex01.180solutions.com> References: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C0B213ED@seaex01.180solutions.com> Message-ID: <20070724173009.GM17833409@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2007-07-24 10:11]: > > > So, my suggestion would be to change the standard plugin output to print > > > only the "Information text" and to print "STATUS: Information text" when > > > the plugin was called with "--verbose". Opinions? > > > > I agree. But somehow I like the status string even though I can't find > > an argument for that. Yet I'd cast my vote to remove both and declare > > them optional in the guidelines. > > I like the status line too :) > > Why not do the opposite and add a --quiet option. I don't want the plugin to be --quiet, I want --no-redundant-output ;-) Well, yes, if people really want the STATUS and/or SERVICE output, I'd prefer having such an option over not even having it, of course. > --verbose is already used for debugging, so that would mean we'd need to > change all --verbose into --debug or something similar. As I thought that printing out the STATUS _is_ only interesting for debugging purposes, my idea was to keep it simple and just add the STATUS to the current (possibly multi-line) --verbose output. I didn't really see the need to have the option of printing out a single line including the STATUS _next_ to the option of printing out the STATUS if requesting the "--verbose" output. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Thu Jul 26 02:14:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jul 2007 17:14:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1218235 ] unicast support for check_dhcp Message-ID: Patches item #1218235, was opened at 2005-06-10 15:49 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1218235&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: Accepted Priority: 5 Private: No Submitted By: Andreas Ericsson (ageric) Assigned to: Holger Weiss (hweiss) Summary: unicast support for check_dhcp Initial Comment: Heiti Ernits, an employee at Boras Kommun has added unicast support to the check_dchp plugin. I reworked it a bit to be more general and removed the hardcoded stuff. I also added detection of ones own IP-address to use for the return route. It gives check_dhcp the ability to mimic a dhcp-relay server, which use unicast when talking to the server and therefore can be used to query dhcp-servers on separate and even remote subnets. There are routing rules ofcourse. Querying a dhcp-server with ip 192.168.0.4 on subnet A from 192.168.0.3 on subnet B won't work, as the dhcp-server then will redirect its responses to a host on the same subnet (which may or may not exist) rather than the correct server. Sane networks probably won't suffer from it, and it may be possible to work around it (although I can't imagine how). Apply with patch -p1 < nagiosplug-check_dhcp-unicast.diff ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-07-26 02:14 Message: Logged In: YES user_id=759506 Originator: NO I reviewed the code, updated the patch for the current revision of check_dhcp.c, tested the functionality and committed it with the following changes: 1) The patch included a *huge* amount of white-space changes and other unrelated, purely cosmetic stuff. I went through the patch line by line and backed out all that stuff before committing, otherwise the commit diff would've been pretty unreadable. This reduced the size of the unidiff from about 1900 to 220 lines (with my additional changes, it's now about 280 lines). *If* we change white-space, we should do so in one big seperate commit which cleans things up (though I still don't really like the idea of making diffs crossing such a commit unreadable). Must be discussed on the list, somewhere along the way ... 2) The patch required the user to specify the value to use for the 'hops' field of the DHCP packet as an argument to the new "-u, --unicast" flag. The 'hops' field is a count of the number of DHCP relay agents which have seen the packet so far, each agent must increment the value of this field if forwarding the packet (see RFC 1542, 4.1.1). I guess having to specify such a value might be confusing for users and I don't see how using a value != 1 could be useful. So, I changed "--unicast" to not take an argument and hardcoded a 'hops' value of 1 for unicast requests. 3) The patch uses an ioctl(2) call to detect the IP address of the client's interface. This call was only done if __linux__ is #defined (unicast requests wouldn't have worked on other platforms), though the call is actually quite portable. So now, the call will be done on all platforms which define the request macro used by the call (SIOCGIFADDR). This works on all platforms I tested (though I had to include for Solaris). On platforms which don't #define SIOCGIFADDR, "--unicast" will spit out an error. 4) I moved the IP address detection out of get_hardware_address() into a seperate get_ip_address() function. 5) Various minor cleanups. I'll also add an option to specify the MAC address to use on the command line, but that's not really related to this patch. Thank you, Holger ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-07-11 17:38 Message: Logged In: YES user_id=759506 Originator: NO Thank you very much. I hope I'll find the time to look into the patch and test it Really Soon Now[tm]. Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1218235&group_id=29880 From noreply at sourceforge.net Thu Jul 26 04:20:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jul 2007 19:20:04 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653253 ] check_nt: Wrong Unit in perfdata Message-ID: Bugs item #1653253, was opened at 2007-02-06 04:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Matthias Eble (psychotrahe) Summary: check_nt: Wrong Unit in perfdata Initial Comment: These Plugin puts everytime I call it, an % into the perfdata. The % is the Perfunit like this: Perfdata= 65.000000%;0.000000;0.000000;0 Is there an patch available or must I execute the check_nt plugin in an other way? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-07-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-07-11 14:09 Message: Logged In: YES user_id=1694341 Originator: NO Hi Flitti, is this still an issue? I have tested several calls and could not reproduce your problem. I cannot judge if you need to call the plugin otherwise Without knowing your command. However: ./check_nt -v CPULOAD -H 192.168.1.2 -l 10,90,95,10,90,95 -p 12489 CPU Load 0% (10 min average) 0% (10 min average) | '10 min avg Load'=0%;90;95;0;100 '10 min avg Load'=0%;90;95;0;100 -> looks fine ./check_nt -v MEMUSE -H 192.168.1.2 -l C -p 12489 Memory usage: total:1250,25 Mb - used: 331,50 Mb (27%) - free: 918,75 Mb (73%) | 'Memory usage'=331,50Mb;0,00;0,00;0.00;1250,25 -> looks fine ./check_nt -v USEDDISKSPACE -H 192.168.1.2 -l C -p 12489 C:\ - total: 156,25 Gb - used: 89,10 Gb (57%) - free 67,15 Gb (43%) | 'C:\ Used Space'=89,10Gb;0,00;0,00;0.00;156,25 -> looks fine the source doesn't look like if there is such a problem and the source has not changed significantly for long. I'm setting this issue to pending. It'll get deleted automatically if you won't post a comment in the next 14 days. Best regards Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 From eji at facebook.com Thu Jul 26 02:27:14 2007 From: eji at facebook.com (Eric Ji) Date: Wed, 25 Jul 2007 17:27:14 -0700 Subject: [Nagiosplug-devel] More options about check_http Message-ID: Hi Nagios plugin developer, I added two options for check_http to take care of corner cases that user doesn't want to alert if the host is unreachable or socket timeouts, under certain scenario. The patch is attached and if it can get into mainline more users may use it if they want to do the same. Thanks, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http.patch Type: application/octet-stream Size: 3774 bytes Desc: not available URL: From ton.voon at altinity.com Thu Jul 26 16:49:44 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 26 Jul 2007 15:49:44 +0100 Subject: [Nagiosplug-devel] Plugin output format In-Reply-To: <20070724173009.GM17833409@CIS.FU-Berlin.DE> References: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C0B213ED@seaex01.180solutions.com> <20070724173009.GM17833409@CIS.FU-Berlin.DE> Message-ID: On 24 Jul 2007, at 18:30, Holger Weiss wrote: > * Thomas Guyot-Sionnest [2007-07-24 10:11]: >>>> So, my suggestion would be to change the standard plugin output >>>> to print >>>> only the "Information text" and to print "STATUS: Information >>>> text" when >>>> the plugin was called with "--verbose". Opinions? >>> >>> I agree. But somehow I like the status string even though I can't >>> find >>> an argument for that. Yet I'd cast my vote to remove both and >>> declare >>> them optional in the guidelines. >> >> I like the status line too :) >> >> Why not do the opposite and add a --quiet option. > > I don't want the plugin to be --quiet, I want --no-redundant- > output ;-) > Well, yes, if people really want the STATUS and/or SERVICE output, I'd > prefer having such an option over not even having it, of course. Just to put some context to this, there was a hot dispute at the time this was included in the dev guidelines. I think I proposed it and Karl, then team lead, said OK grudgingly as long as there was a note saying that the format is not to be relied upon. So that's how we got here. I guess the SERVICE part can be dropped. I like the STATUS line (though it gets confusing if you run negate :) - I side with Matthias here: "I'm not sure why". >> --verbose is already used for debugging, so that would mean we'd >> need to >> change all --verbose into --debug or something similar. > > As I thought that printing out the STATUS _is_ only interesting for > debugging purposes, my idea was to keep it simple and just add the > STATUS to the current (possibly multi-line) --verbose output. I > didn't > really see the need to have the option of printing out a single line > including the STATUS _next_ to the option of printing out the > STATUS if > requesting the "--verbose" output. I definitely do not want more options on command line, at least not yet. My feeling is that if we can get a single function to return the output, used by all our plugins, then it is easy to change the removal of the status part on a global basis (configure time option?). That's where the hard work is. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From holger at CIS.FU-Berlin.DE Thu Jul 26 17:10:10 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 26 Jul 2007 17:10:10 +0200 Subject: [Nagiosplug-devel] Plugin output format In-Reply-To: References: <20070723231252.GJ17833409@CIS.FU-Berlin.DE> <46A62D3A.2010706@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C0B213ED@seaex01.180solutions.com> <20070724173009.GM17833409@CIS.FU-Berlin.DE> Message-ID: <20070726151010.GC18228969@CIS.FU-Berlin.DE> * Ton Voon [2007-07-26 15:49]: > My feeling is that if we can get a single function to return the > output, used by all our plugins, then it is easy to change the > removal of the status part on a global basis (configure time > option?). That's where the hard work is. Yes, that's how I would/will implement such a change, I just wanted to ask whether you're fine with changing the output format (by default or optionally) before discussing implementation details :-) And yes, all in all it'll be quite a bit of work, but AFAICS there's no need to change all plugins at once. While at it, I'd also like to implement some functions which provide an interface similar to syslog(3) for verbose output and convert the plugins to use these functions instead of doing "if (verbose) printf()". Making the output format a ./configure option would be fine with me. I could (and if no one objects will) do these changes for the C plugins. Thanks, Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From holger at CIS.FU-Berlin.DE Thu Jul 26 19:33:04 2007 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 26 Jul 2007 19:33:04 +0200 Subject: [Nagiosplug-devel] usage() calls commented out in check_dhcp.c Message-ID: <20070726173304.GD18228969@CIS.FU-Berlin.DE> Within the getopt_long(3) loop of check_dhcp.c, some usage() calls have been commented out. Anyone happen to know why? I couldn't find a reason for this in the SVN/CVS logs, so I commented most of them back in (those that were relevant for the stuff I added to check_dhcp with my latest commits). Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Thu Jul 26 22:49:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jul 2007 13:49:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 15:21 Message generated for change (Comment added) made by lisme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 15:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 16:53 Message: Logged In: YES user_id=1537 Originator: NO I experienced the problem today. On debian etch. I'm running check_dhcp and the dhcp server on the same interface. The dhcp server otherwise runs fine. strace /usr/lib/nagios/plugins/check_dhcp -s dhcp.dmz.tld -i eth2 ... read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0 mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c17000 mmap2(0xb7c2a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c2a000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c16000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c15000 mprotect(0xb7d57000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c156c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f04000, 8510) = 0 brk(0) = 0x804f000 brk(0x8070000) = 0x8070000 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth2\0\0\0\0\0\0\0\0\0\0\0\0\17\0\0\0\4\0\0\0\5\0\0\0$"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:13:72:40:39:0a}) = 0 time(NULL) = 1179697853 sendto(3, "\1\1\6\0b\\:\347\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1179697853]) = 1179697853 time([1179697853]) = 1179697853 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1179697855]) = 1179697855 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f06000 write(1, "CRITICAL: No DHCPOFFERs were rec"..., 39CRITICAL: No DHCPOFFERs were received. ) = 39 munmap(0xb7f06000, 4096) = 0 exit_group(2) = ? Process 15586 detached ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-20 09:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I'm setting this one back to Resolution: None, because reuben's problem is reproducable using the cvs version for me. First i didn't get dhcpd to send a reply at all. That was caused by incorrect udp checksums which dhcpd didn't like. So I switched off checksum offloading in the network driver and finally came into reuben's situation. So I did some investigations and have following notes now: - problem encounters if check_dhcp is run from the same system serving dhcp - the select times out according to strace - offers are sent according to tcpdump/ethereal - dhcpcd-test works flawlessly - check_dhcp works on remote system The fact that select times out makes me think that no data actually arrives at the socket. If two servers are online, i get only the response from the remote server. One more thing I noticed is that dhcpcd-test sends discovers with source ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip the client doesn't even know - and cannot bind a socket on. I can't imagine how this works at all. Any hints? Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 08:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 06:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 08:29 Message: Logged In: YES user_id=26209 In my case the problem seems to be caused by the plugin being run on the *same system* as the DHCP server. I did raise this earlier but I don't think it was investigated and obviously not fixed. Regardless, that is still the case and seems to be the cause of the problem for me. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-25 23:32 Message: Logged In: YES user_id=26209 Nope, still broken for me with current CVS. The DHCP server offers the lease but it is not responded to..and the check_dhcp test fails. I'll do some more looking into this this weekend. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 13:11 Message: Logged In: YES user_id=2225 Based on previous comments, it looks like this was already fixed in CVS a while ago... ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 12:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 03:33 Message: Logged In: YES user_id=724669 Right. I *should have* tried the CVS. I compiled it on my dev box (FC3), copied it to my FC2 machine and it worked fine there. So I suppose the bug isn't all that, now. But that made me curious. I went and got each previous revision of check_dhcp.c, recompiled and they all worked. So I suspected a problem in Dag's rpm package. I copied the "bad" binary to another FC2 machine and there it works. The only difference is an SMP kernel where it failed, and the UP kernel (same version) on the other. But that's just useless trivia now I suppose since the version compiled by hand works either way. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-02-07 18:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 13:45 Message: Logged In: YES user_id=724669 I have to apologize, I haven't been monitoring this report (I was kind of hoping SF would send notification emails on activity, but it didn't). Anyway, I noticed a difference between my strace and the others, that may be significant. Specifically, the select() call returns with data on the socket in my version (but the recvfrom still fails!), while it times out in the others. So we may be dealing with two different problems here. Yes, exactly what you wanted to hear, isn't it... I'll try the CVS version later on tonight and let you know. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 05:48 Message: Logged In: YES user_id=26209 Ok it's a flat topology: * Single switch * Single router, with 192.168.0.1 internally, 60.234.x.x address externally doing NAT * Single Linux server, 2.6.11-rc1-mm2 (at the moment), with eth0 (192.168.0.3) eth0:0 (192.168.0.4) gre0 (172 address) and a loopback. The machine has only one NIC. Clients are also on the 192.168.0.0/24 network. Simple home network ;-) dhcpd is not bound to any particular interface, but when I shut down gre0 and eth0:0 and then restarted dhcpd to avoid binding problems, same result when running check_dhcp :( Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Wrote 0 deleted host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 0 new dynamic host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 4 leases to leases file. Jan 24 23:08:03 tornado dhcpd: Listening on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on Socket/fallback/fallback-net Jan 24 23:13:03 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 Jan 24 23:13:04 tornado dhcpd: DHCPOFFER on 192.168.0.11 to 00:0d:61:5e:8b:b3 via eth0 ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 05:31 Message: Logged In: YES user_id=395628 Thanks very much for your comment Reuben. Please would you consider letting me know 1 whether eth0:0 is a 'virtual' interface ? Does the host running check dhcp have two (2) NICs ? 2 try and sketch the topology for me Is it | |--------- check_dhcp/dhcpd --------| | etho eth1 | | some other /x |------------ router 192.168.0.0/24 ? Which interface is dhcpd bound to ? You are welcome to write me direct (SHopcroft at IPAustralia.Gov.AU) if that's more convenient. Thank you. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 05:09 Message: Logged In: YES user_id=26209 I've just down'ed eth0:0 and restarted dhcpd, still same result....... :( Router is connected to 192.168.0.0/24 and external (routable) IP address only. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 05:04 Message: Logged In: YES user_id=395628 Firstly, a very heart felt thank you to zytak and reuben for their willingness to test, listen to my silly remarks and retest. This release owes a lot to both gentlemen. (your initiative also saved you hearing more silly remarks such as did you regen configure ? ...) All ones (ie 255.255.255.255) broadcasts has some 'minor gotchas' that appear to be evident here. (See Unix Network Programming vol 1 p 471-2) I think what is happening is that 1 check_dhcp broadcasts are only being sent from the primary (eth0) interface and are being transformed from 'all-ones' to 'subnet-directed' broadcast (the broadcast ip address of eth0). 2 your dhcp server is replying with a broadcast on _that_ prefix network which your secondary interface - check_dhcp - is not connected to. Presumably, your router is connected to both LANs and will reply on _all_ interfaces - since some OS's replicate broadcasts on _all_ their interfaces. Thanks very much for your comments. Will update the usage information ... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 04:12 Message: Logged In: YES user_id=26209 Ok, some progress. If I serve up DHCP from my cisco router with dhcpd off on my server, check_dhcp works just fine: [root at tornado ~]# /usr/lib/nagios/plugins/check_dhcp DHCP ok: Received 1 DHCPOFFER(s), max lease time = 86400 sec. If I then turn dhcp off on the router and re-enable dhcpd on my server, it fails again. So it appears that running check_dhcp from the same host as the dhcp server is a no-go, at least in my case......... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 04:02 Message: Logged In: YES user_id=26209 I still experience the problem even with my iptables rules off: [root at tornado nagiosplug]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- network.reub.net/16 !network.reub.net/16 tcp dpt:http to:192.168.0.3:3128 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# Other possible ideas: * I have two IP addresses, a main and a secondary IP address on eth0(:0) * My server which does the monitoring also does DHCP If I can come up with anything I'll post here. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 03:59 Message: Logged In: YES user_id=26209 Firstly, can I confirm that sourceforge CVS has the most current version? Latest CVS has: $Id: check_dhcp.c,v 1.6 2004/12/30 00:41:39 opensides Exp $ I don't think your latest changes have made it into the publically visible repo :( Here's an strace: [root at tornado nagiosplug]# strace /usr/lib/nagios/plugins/check_dhcp execve("/usr/lib/nagios/plugins/check_dhcp", ["/usr/lib/nagios/plugins/check_dhcp"], [/* 22 vars */]) = 0 uname({sys="Linux", node="tornado", ...}) = 0 brk(0) = 0x804e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39607, ...}) = 0 old_mmap(NULL, 39607, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff6000 close(3) = 0 open("/lib/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320D\7"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=97608, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff5000 old_mmap(0x4b071000, 88064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b071000 old_mmap(0x4b083000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x4b083000 old_mmap(0x4b085000, 6144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b085000 close(3) = 0 open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\343"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=81252, ...}) = 0 old_mmap(0x4b02c000, 75944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b02c000 old_mmap(0x4b03b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x4b03b000 old_mmap(0x4b03d000, 6312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b03d000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \277\353"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1521596, ...}) = 0 old_mmap(0x4aea7000, 1215644, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4aea7000 old_mmap(0x4afca000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0x4afca000 old_mmap(0x4afce000, 7324, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4afce000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff4000 mprotect(0x4afca000, 8192, PROT_READ) = 0 mprotect(0x4b03b000, 4096, PROT_READ) = 0 mprotect(0x4b083000, 4096, PROT_READ) = 0 mprotect(0x4aea3000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff46c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7ff6000, 39607) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39591472, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7df4000 mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x1029) = 0xb7dc2000 brk(0) = 0x804e000 brk(0x806f000) = 0x806f000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x1072) = 0xb7dc1000 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\264\356\377\277\370"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, 0xbfffedd0) = 0 time(NULL) = 1106556165 sendto(3, "\1\1\6\0\34|\211\212\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1106556165]) = 1106556165 time([1106556165]) = 1106556165 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1106556167]) = 1106556167 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc0000 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7da0000 read(3, "# Locale name alias data base.\n#"..., 131072) = 2528 read(3, "", 131072) = 0 close(3) = 0 munmap(0xb7da0000, 131072) = 0 open("/usr/share/nagios/locale/en_US/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/nagios/locale/en/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(1, "DHCP problem: No DHCPOFFERs were"..., 43DHCP problem: No DHCPOFFERs were received. ) = 43 munmap(0xb7dc0000, 4096) = 0 exit_group(2) = ? [root at tornado nagiosplug]# Also: [root at tornado nagiosplug]# /usr/lib/nagios/plugins/check_dhcp -v DHCP socket: 3 Hardware address: 000d615e8bb3 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 842612958 (0x323940DE) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. [root at tornado nagiosplug]# ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-24 03:48 Message: Logged In: YES user_id=544197 Wooooops :/ Shame on me =) flushed all iptables rules and now it works... The "strange thing" is: dhcp is fully functional if I use the same rulebase !! Here are the rules ---- schnippi ---- Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited ---- schnappi ---- ?m... no idea which rule stops the check_dhcp plug... :/ ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-23 21:57 Message: Logged In: YES user_id=395628 Dear Folks, I am perplexed about this problem. 1 the open socket won't ignore a broadcast reply with the dhcp client port unless the reply is filtered by some kernel packet filter (iptable on Linux ?), or there is a firewall or router between the client and server. Given the PRs this doesn't seem likely. 2 the failure is however consistent with L.C's (Laurentiu C. Badea) PR showing EINVAL from the recvfrom call. Please would either L.C., Rueben Farrelly or zyta2k do an strace or equivalent (truss/ktrace ?) to show if recvfrom is still returning -1/EINVAL from a CVS copy (not many changes from L.C's report of the prob with the 1.3 plugins but its nice to be sure) EINVAL seems to suggest an argument problem but I can't imagine what this may be - the parms seem fine. Thank you. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-21 04:35 Message: Logged In: YES user_id=395628 Thank you for a superb PR. Unfortunately, this is unlikely to help you much but would you please try the latest CVS (not tar ball) and post your command invocation (changes have been made to get it to build properly on Linux and FreeBSD - you seem to have done this yourself). On FreeBSD 4.10 and ISC dhcpd (V3.0.1rc14), it works Ok. The reply to the discover should be a broadcast (methinks) since the client has no ip. Thanks for your help. ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-04 05:41 Message: Logged In: YES user_id=544197 I can confirm the problem... === Verbose Output From Plugin === DHCP socket: 3 Hardware address: 00110a32c75e DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 1269450911 (0x4BAA489F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. ============= TCPDUMP ============ # tcpdump -vv dst port 68 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:25:54.418410 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418675 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418975 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.421156 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 4 packets captured 4 packets received by filter 0 packets dropped by kernel ========== MY SYSTEM ============= Distribution: Fedora Core 3 Kernel: 2.6.9 Glibc: 2.3.4 Plugin Version: CVS v 1.6 2004/12/30 00:41:39 hth zyta2k ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 15:48 Message: Logged In: YES user_id=26209 Still no go here either using bleeding edge CVS (on FC3): sendto(3, "\1\1\6\0\6\372\275\241\377\0\200\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1104698558]) = 1104698558 time([1104698558]) = 1104698558 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1104698560]) = 1104698560 close(3) = 0 Returns with "DHCP problem: No DHCPOFFERs were received." Meanwhile the DHCP server has seen the DHCPDISCOVER come in and DHCPOFFER'ed an address to 255.255.255.255.bootpc ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 13:42 Message: Logged In: YES user_id=388184 Hi, could you test with the lastest cvs, and report your findings Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 From eji at facebook.com Thu Jul 26 23:09:54 2007 From: eji at facebook.com (Eric Ji) Date: Thu, 26 Jul 2007 14:09:54 -0700 Subject: [Nagiosplug-devel] More options about check_http In-Reply-To: Message-ID: > From: Eric Ji > Date: Wed, 25 Jul 2007 17:27:14 -0700 > To: > Conversation: More options about check_http > Subject: More options about check_http > > > Hi Nagios plugin developer, > > I added two options for check_http to take care of corner cases that user > doesn't want to alert if the host is unreachable or socket timeouts, under > certain scenario. The patch is attached and if it can get into mainline more > users may use it if they want to do the same. > > Thanks, > Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http.patch Type: application/octet-stream Size: 2791 bytes Desc: not available URL: From paa.listas at gmail.com Sat Jul 28 17:27:27 2007 From: paa.listas at gmail.com (Paa.listas) Date: Sat, 28 Jul 2007 12:27:27 -0300 Subject: [Nagiosplug-devel] PHP as script language for plugins Message-ID: <46ab6062.2586460a.4c43.ffffc8ce@mx.google.com> Hello, I am new to Nagios and more new to writing plugins for it. I am train to code one in PHP, but I always receive this answere in the Nagios front-end: Status Information: (No output returned from plugin) The simplest plugin is this: ------------------------------------------------- #!/usr/bin/php ------------------------------------------------- My tftp.cfg file looks like this (I am not using the parameters right now): ------------------------------------------------- # 'check_tftp' command definition define command{ command_name check_tftp command_line /usr/lib/nagios/plugins/check_tftp.real $HOSTADDRESS$ $ARG1$ $ARG2$ } ------------------------------------------------- And my service like this: ------------------------------------------------- define service{ use generic-service host_name tftpHost service_description TFTP Server test check_command check_tftp!argument1!argument2 } ------------------------------------------------- There are any problems with PHP or with this code? Thanks in advance and sorry for my bad English. Saludos. Pablo. From noreply at sourceforge.net Sun Jul 29 04:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jul 2007 19:20:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1681482 ] check_ifstatus - SNMPv3 - bug line 307 Message-ID: Bugs item #1681482, was opened at 2007-03-15 06:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1681482&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Geoffrey Lemaire (geolem) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus - SNMPv3 - bug line 307 Initial Comment: RHEL 4 - nagios 2.8 (via up2date) RHEL 4 - check_ifstatus version : check_ifstatus (nagios-plugins 1.4.5) 1.9 Hi, I have a problem with check_ifstatus and SNMPv3 at line 307. When I do a : --- ./check_ifstatus -H 127.0.0.1 -v 3 -L authNoPriv -a MD5 -U mylogin -A mypassword --- I have the message : --- Missing arguments! check_ifstatus -C -p -H Copyright (C) 2000 Christoph Kron Updates 5/2002 Subhendu Ghosh --- I put a lot of "printf" and I found a problem on the line 307 : --- unless ($seclevel eq ('noAuthNoPriv' || 'authNoPriv' || 'authPriv' ) ) { --- It forward me to the "usage();". When I do a (for testing my SNMPv3) : --- snmpget -v 3 -u mylogin -l authNoPriv -a MD5 -A mypassword localhost sysUpTime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (196856) 0:32:48.56 --- It's look ok... So, what we can do ? (started topic : http://forums.opsyx.com/viewtopic.php?p=21709#21709) Very thanks ! ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-07-28 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-07-14 13:10 Message: Logged In: YES user_id=1694341 Originator: NO Hi Geoffrey, is your problem fixed in the latest release? I'm setting this item to pending. It will get deleted automatically, if you won't post in the next 14 days. Thanks for your report. Matthias ---------------------------------------------------------------------- Comment By: Gavin Carr (gonzai) Date: 2007-03-16 05:13 Message: Logged In: YES user_id=674647 Originator: NO Yep, that's completely broken, and there's another couple of places just like it. Fix checked into CVS now. Cheers, Gavin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1681482&group_id=29880 From Sven.Probst at WDR.DE Mon Jul 30 13:56:47 2007 From: Sven.Probst at WDR.DE (Sven Probst) Date: Mon, 30 Jul 2007 13:56:47 +0200 Subject: [Nagiosplug-devel] NRMH Bug in check_nwstat.c Message-ID: <46ADEE1F020000F600003E96@wdr.de> Hello, there is a small bug in check_nwstat.c: NRMH-Status seems to be always GOOD. (This is good, but not correct.) The following patch fixes this problem: 555c555 < asprintf (&send_buffer,"NRMH\r\n"); --- > asprintf (&send_buffer,"NRMH:Server_Health_Status\r\n"); 563c563 < result=STATE_OK; --- > result=STATE_CRITICAL; 566,567c566 < else { < if (nrm_health_status==1) { --- > else if (nrm_health_status==1) { 571c570 < --- > else { 574d572 < Best regards Sven Probst From Thomas at zango.com Mon Jul 30 19:56:08 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 30 Jul 2007 10:56:08 -0700 Subject: [Nagiosplug-devel] PHP as script language for plugins In-Reply-To: <46ab6062.2586460a.4c43.ffffc8ce@mx.google.com> References: <46ab6062.2586460a.4c43.ffffc8ce@mx.google.com> Message-ID: <804160344192334BB21922E8082EA6C0B21CBC@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of Paa.listas > Sent: July 28, 2007 11:27 > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] PHP as script language for plugins > > Hello, > > I am new to Nagios and more new to writing plugins for it. I am train to > code one in PHP, but I always receive this answere in the Nagios front- > end: > > Status Information: (No output returned from plugin) I've been using PHP plugins without any problems... When you run it do you see any blank line before the output? I'm not a php programmer but I guess the blank line before " From jim.nelson at neteasyinc.com Mon Jul 30 22:43:13 2007 From: jim.nelson at neteasyinc.com (Jim Nelson) Date: Mon, 30 Jul 2007 16:43:13 -0400 Subject: [Nagiosplug-devel] [PATCH] Fix problems with some perl plugins and 'use strict; ' Message-ID: <46AE4D61.3070302@neteasyinc.com> Current versions of several plugins in the /contrib directory fail with errors when run in CentOS 5. The attached patch allows these plugins to be run. -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-fix-perl-include.patch Type: text/x-patch Size: 2054 bytes Desc: not available URL: From paa.listas at gmail.com Tue Jul 31 12:49:33 2007 From: paa.listas at gmail.com (Paa.listas) Date: Tue, 31 Jul 2007 07:49:33 -0300 Subject: [Nagiosplug-devel] PHP as script language for plugins In-Reply-To: <804160344192334BB21922E8082EA6C0B21CBC@seaex01.180solutions.com> Message-ID: <46af13c1.2586460a.4c43.ffffe623@mx.google.com> Thanks you very much. That blank line was the source of the problem!!! Now its works fine. Saludos. Pablo. # -----Mensaje original----- # De: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- # devel-bounces at lists.sourceforge.net] En nombre de Thomas Guyot-Sionnest # Enviado el: Lunes, 30 de Julio de 2007 02:56 p.m. # Para: Nagios Plugin Development Mailing List # Asunto: Re: [Nagiosplug-devel] PHP as script language for plugins # # > -----Original Message----- # > Sent: July 28, 2007 11:27 # > To: nagiosplug-devel at lists.sourceforge.net # > Subject: [Nagiosplug-devel] PHP as script language for plugins # > # > Hello, # > # > I am new to Nagios and more new to writing plugins for it. I am train # to code one in PHP, but I always receive this answere in the Nagios front- # > end: # > # > Status Information: (No output returned from plugin) # # # I've been using PHP plugins without any problems... When you run it do you # see any blank line before the output? I'm not a php programmer but I guess # the blank line before " Patches item #1764502, was opened at 2007-07-31 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1764502&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Wilson (gcc) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for directories to check_file_age Initial Comment: I added to the check_file_age plugin the ability to check directories (with the -d option) as well as files. I also made some cosmetic improvements to reduce the scope of variables to prevent accidental use in future. I hope that these are useful and will be included in the plugin in future. Patch attached against check_file_age (nagios-plugins 1.4.2) $Id: check_file_age.pl,v 1.2 2003/10/21 15:56:35 tonvoon Exp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1764502&group_id=29880