From noreply at sourceforge.net Mon May 1 12:09:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon May 1 12:09:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1476457 ] check_disk from 1.4.3 broken on Solaris Message-ID: Bugs item #1476457, was opened at 2006-04-25 19:05 Message generated for change (Comment added) made by bubbafat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476457&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: Pending Resolution: None Priority: 5 Submitted By: Jason Kau (bubbafat) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk from 1.4.3 broken on Solaris Initial Comment: 1.4.2 generally worked fine: darlene:/home/gtri/nagios/nagios-plugins- 1.4.2/plugins> ./check_disk -c 10% -w 20% -p / DISK OK - free space: / 148 MB (62%);| /=92MB;192;216;0;240 But 1.4.3 is totally broken: darlene:/home/gtri/nagios/nagios-plugins- 1.4.3/plugins> ./check_disk -c 10% -w 20% -p / INPUT ERROR: C_IDFP (576757562146984196887840714641773148777678636223636702 2532588820893046978288185192879572621223612389130957129 0848500887014776227174023686652499354620705377775907971 98162364903456768.000000) should be less than W_IDFP (536865219293231826318811839788020090938367133084499836 1682498849996091152805464249751663763505429901150414412 5179723248934633655425911613390532121950804833986559378 194432.0) and both should be between zero and 100 percent, inclusive for / check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [- v] [-q] I will look into the code when I get time but would appreciate someone else looking into it too and I'm not a great programmer (I'm the router/firewall guy). ---------------------------------------------------------------------- >Comment By: Jason Kau (bubbafat) Date: 2006-05-01 15:08 Message: Logged In: YES user_id=1495257 jfidell, your patch fixes the problem on Solaris it would appear: darlene:/home/gtri/nagios/nagios-plugins- 1.4.3/plugins> ./check_disk -c 10% -w 20% -p / DISK OK - free space: / 148 MB (62% inode=96%);| /=92MB;192;216;96;240 Someone please committ this to CVS ---------------------------------------------------------------------- Comment By: James (jfidell) Date: 2006-04-26 09:17 Message: Logged In: YES user_id=1510516 I posted some details on this to the devel list a week or so back: On a quick inspection of the code it looks like the c_idfp and w_idfp elements of struct namelist aren't always being initialised when they should be. The following patch fixes my particular problem: --- check_disk.c~ 2006-04-19 13:56:39.000000000 +0100 +++ check_disk.c 2006-04-19 15:23:11.000000000 +0100 @@ -462,6 +462,8 @@ se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; @@ -547,6 +549,8 @@ se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found =0; se->found_len = 0; *pathtail = se; but it isn't clear to me whether a similar change is required for the options -x and -X ---------------------------------------------------------------------- Comment By: Andreas Hoppe (ahoppe) Date: 2006-04-26 04:39 Message: Logged In: YES user_id=1510323 same here: Solaris 9 SPARC, gcc 2.95.3, GNU-make 3.80 Version 1.4.2 works fine, Version 1.4.3 wont accept the -p / -x parameter ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-04-25 19:09 Message: Logged In: YES user_id=1495257 This is Solaris 8/SPARC system and gcc 3.3.2. The same problem occurs when compiled on Solaris 7/SPARC system with egcs-1.1.2 so I don't think it's Solaris or compiler specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476457&group_id=29880 From seanius at seanius.net Mon May 1 15:14:03 2006 From: seanius at seanius.net (sean finney) Date: Mon May 1 15:14:03 2006 Subject: [Nagiosplug-devel] new version of check_ntp.c, new default check_ntp plugin Message-ID: <20060501221322.GA27754@seanius.net> hey folks, just fyi, after the latest commit i've done the incredibly heavy-handed act of making the check_ntp.c the default ntp-checking plugin. there may be some bugs lurking in the code, but i feel pretty good about it overall and so i think it's high time to get it some real testing. specifically, if you have a 64bit and/or big-endian machine, i'd like to hear of confirmations/bugs regarding the plugin. also, i suspect that there may be platforms that don't implement poll(), which is used to greatly speed up the querying process (it's really fast, faster than the perl plugin on my machines). if so, we'll probably need to make some kind of wrapper voodoo select(), which i think should be pretty much everywhere. i've also been in contact with a few of the peeps from the ntp-hackers list, who have helped find the flaw in my offset calculation as well as offered to give the plugin some testing on the nagios system that they use to monitor the ntp project machines :) so, let me know what you think. also, if this is too big/quick of an unannounced change, let it be known that you think so! i've also set up the configure script to automatically build check_apt if appropriate, so give that a spin too if you're interested! and finally, barring any further tweaks on the ntp/apt plugin based on feedback/bugs, i'll be easing off the gas a bit in the next few weeks as i have a bit of a backlog of work in other areas and will be attending debconf in mid-may. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Tue May 2 01:21:08 2006 From: ton.voon at altinity.com (Ton Voon) Date: Tue May 2 01:21:08 2006 Subject: [Nagiosplug-devel] new version of check_ntp.c, new default check_ntp plugin In-Reply-To: <20060501221322.GA27754@seanius.net> References: <20060501221322.GA27754@seanius.net> Message-ID: On 1 May 2006, at 23:13, sean finney wrote: > hey folks, > > just fyi, after the latest commit i've done the incredibly heavy- > handed > act of making the check_ntp.c the default ntp-checking plugin. there > may be some bugs lurking in the code, but i feel pretty good about > it overall and so i think it's high time to get it some real testing. > specifically, if you have a 64bit and/or big-endian machine, i'd like > to hear of confirmations/bugs regarding the plugin. also, i suspect > that there may be platforms that don't implement poll(), which is used > to greatly speed up the querying process (it's really fast, faster > than the perl plugin on my machines). if so, we'll probably need to > make some kind of wrapper voodoo select(), which i think should be > pretty much everywhere. Sean, Thanks very much for your work on this. I'll add some basic tests for check_ntp. I seem to recall something about poll() that can be implemented using select() calls instead, but we can wait for someone to shout... > i've also been in contact with a few of the peeps from the ntp-hackers > list, who have helped find the flaw in my offset calculation as > well as offered to give the plugin some testing on the nagios > system that they use to monitor the ntp project machines :) Excellent! > so, let me know what you think. also, if this is too big/quick > of an unannounced change, let it be known that you think so! I think given the problems raised with the perl version, I think this will be okay. I'll update the CHANGES file - could you remember to update this with major changes too? > i've also set up the configure script to automatically build > check_apt if appropriate, so give that a spin too if you're > interested! Cheers for this too. If I have a system to run this on, I'll add some tests here too. Good work! 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 May 2 01:33:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 2 01:33:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1476457 ] check_disk from 1.4.3 broken on Solaris Message-ID: Bugs item #1476457, was opened at 2006-04-26 00:05 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476457&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 Submitted By: Jason Kau (bubbafat) >Assigned to: Ton Voon (tonvoon) Summary: check_disk from 1.4.3 broken on Solaris Initial Comment: 1.4.2 generally worked fine: darlene:/home/gtri/nagios/nagios-plugins- 1.4.2/plugins> ./check_disk -c 10% -w 20% -p / DISK OK - free space: / 148 MB (62%);| /=92MB;192;216;0;240 But 1.4.3 is totally broken: darlene:/home/gtri/nagios/nagios-plugins- 1.4.3/plugins> ./check_disk -c 10% -w 20% -p / INPUT ERROR: C_IDFP (576757562146984196887840714641773148777678636223636702 2532588820893046978288185192879572621223612389130957129 0848500887014776227174023686652499354620705377775907971 98162364903456768.000000) should be less than W_IDFP (536865219293231826318811839788020090938367133084499836 1682498849996091152805464249751663763505429901150414412 5179723248934633655425911613390532121950804833986559378 194432.0) and both should be between zero and 100 percent, inclusive for / check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [- v] [-q] I will look into the code when I get time but would appreciate someone else looking into it too and I'm not a great programmer (I'm the router/firewall guy). ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-02 09:32 Message: Logged In: YES user_id=664364 Jason, James, Thanks for the report and the fix. This was on my list, but hadn't got round to it yet... Applied to CVS now. Please try the snapshot at http://nagiosplug.sf.net/ snapshot. BTW, pending means a call will be automatically closed, so that's not the right state to place the call into :) Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-01 20:08 Message: Logged In: YES user_id=1495257 jfidell, your patch fixes the problem on Solaris it would appear: darlene:/home/gtri/nagios/nagios-plugins- 1.4.3/plugins> ./check_disk -c 10% -w 20% -p / DISK OK - free space: / 148 MB (62% inode=96%);| /=92MB;192;216;96;240 Someone please committ this to CVS ---------------------------------------------------------------------- Comment By: James (jfidell) Date: 2006-04-26 14:17 Message: Logged In: YES user_id=1510516 I posted some details on this to the devel list a week or so back: On a quick inspection of the code it looks like the c_idfp and w_idfp elements of struct namelist aren't always being initialised when they should be. The following patch fixes my particular problem: --- check_disk.c~ 2006-04-19 13:56:39.000000000 +0100 +++ check_disk.c 2006-04-19 15:23:11.000000000 +0100 @@ -462,6 +462,8 @@ se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; @@ -547,6 +549,8 @@ se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found =0; se->found_len = 0; *pathtail = se; but it isn't clear to me whether a similar change is required for the options -x and -X ---------------------------------------------------------------------- Comment By: Andreas Hoppe (ahoppe) Date: 2006-04-26 09:39 Message: Logged In: YES user_id=1510323 same here: Solaris 9 SPARC, gcc 2.95.3, GNU-make 3.80 Version 1.4.2 works fine, Version 1.4.3 wont accept the -p / -x parameter ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-04-26 00:09 Message: Logged In: YES user_id=1495257 This is Solaris 8/SPARC system and gcc 3.3.2. The same problem occurs when compiled on Solaris 7/SPARC system with egcs-1.1.2 so I don't think it's Solaris or compiler specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476457&group_id=29880 From antoine.lecomte at herve-consultants.net Tue May 2 01:58:00 2006 From: antoine.lecomte at herve-consultants.net (LECOMTE Antoine) Date: Tue May 2 01:58:00 2006 Subject: [Nagiosplug-devel] A propos des plugins sous Nagios Message-ID: Bonjour, Je suis actuellement en train d'?tudier les fonctionnalit?s de Nagios (version 1.3) sous Debian Sarge. J'essaie depuis quelques jours d'en savoir un peu plus sur la cr?ation d'un plugin. En effet, je cherche ? surveiller un service bien particulier tournant sur une machine du r?seau. J'ai donc dans un premier temps envisag? de cr?er le service en question dans le fichier services.cfg. Je me suis alors apercu qu'il fallait renseign?, dans ses propri?t?s, un check_command. J'ai alors compris, apr?s avoir fait des recherches, qu'il fallait pour cela cr?er un plugin qui correspondrait au service que je veux surveiller. Mais je n'ai pas r?ussi ? voir en d?tail comment cr??ions-nous le plugin. Pourriez vous m'indiquer un endroit ou je pourrais avoir + d'infos ? ce sujet, ou bien avez-vous de votre c?t? des infos pr?cises? Vous remerciant par avance pour votre r?ponse, ? bientot. LECOMTE A From ae at op5.se Tue May 2 02:19:02 2006 From: ae at op5.se (Andreas Ericsson) Date: Tue May 2 02:19:02 2006 Subject: [Nagiosplug-devel] A propos des plugins sous Nagios In-Reply-To: References: Message-ID: <445723C5.1070302@op5.se> This is an english-speaking mailing-list. By sending email in french you reach about 5% of the audience and manage to annoy/irritate/aggravate/be ignored by the remaining 95%. LECOMTE Antoine wrote: > Bonjour, > > Je suis actuellement en train d'?tudier les fonctionnalit?s de Nagios (version 1.3) sous Debian Sarge. J'essaie depuis quelques jours d'en savoir un peu plus sur la cr?ation d'un plugin. > En effet, je cherche ? surveiller un service bien particulier tournant sur une machine du r?seau. J'ai donc dans un premier temps envisag? de cr?er le service en question dans le fichier services.cfg. Je me suis alors apercu qu'il fallait renseign?, dans ses propri?t?s, un check_command. J'ai alors compris, apr?s avoir fait des recherches, qu'il fallait pour cela cr?er un plugin qui correspondrait au service que je veux surveiller. > Mais je n'ai pas r?ussi ? voir en d?tail comment cr??ions-nous le plugin. Pourriez vous m'indiquer un endroit ou je pourrais avoir + d'infos ? ce sujet, ou bien avez-vous de votre c?t? des infos pr?cises? > > Vous remerciant par avance pour votre r?ponse, ? bientot. > > LECOMTE A > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 > _______________________________________________________ > 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 > -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Tue May 2 04:57:03 2006 From: ton.voon at altinity.com (Ton Voon) Date: Tue May 2 04:57:03 2006 Subject: [Nagiosplug-devel] A propos des plugins sous Nagios In-Reply-To: <445723C5.1070302@op5.se> References: <445723C5.1070302@op5.se> Message-ID: <817F538E-E45D-4DD3-8B26-990FE4EA0460@altinity.com> On 2 May 2006, at 10:17, Andreas Ericsson wrote: > This is an english-speaking mailing-list. By sending email in > french you reach about 5% of the audience and manage to annoy/ > irritate/aggravate/be ignored by the remaining 95%. As one of the mail administrators, I allowed this email to pass through because there is no specific French mailing list (please correct me if I am wrong and I will publicise links to it) and if no one could read or was interested, it would be quietly ignored. Andreas, while you are free to make suggestions, it is not your position to state what can or cannot appear on this mailing list. Ton > > LECOMTE Antoine wrote: >> Bonjour, >> Je suis actuellement en train d'?tudier les fonctionnalit?s de >> Nagios (version 1.3) sous Debian Sarge. J'essaie depuis quelques >> jours d'en savoir un peu plus sur la cr?ation d'un plugin. En >> effet, je cherche ? surveiller un service bien particulier >> tournant sur une machine du r?seau. J'ai donc dans un premier >> temps envisag? de cr?er le service en question dans le fichier >> services.cfg. Je me suis alors apercu qu'il fallait renseign?, >> dans ses propri?t?s, un check_command. J'ai alors compris, apr?s >> avoir fait des recherches, qu'il fallait pour cela cr?er un plugin >> qui correspondrait au service que je veux surveiller. Mais je n'ai >> pas r?ussi ? voir en d?tail comment cr??ions-nous le plugin. >> Pourriez vous m'indiquer un endroit ou je pourrais avoir + d'infos >> ? ce sujet, ou bien avez-vous de votre c?t? des infos pr?cises? >> Vous remerciant par avance pour votre r?ponse, ? bientot. >> LECOMTE A Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From benoit.mortier at opensides.be Tue May 2 07:43:04 2006 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue May 2 07:43:04 2006 Subject: [Nagiosplug-devel] A propos des plugins sous Nagios In-Reply-To: <817F538E-E45D-4DD3-8B26-990FE4EA0460@altinity.com> References: <445723C5.1070302@op5.se> <817F538E-E45D-4DD3-8B26-990FE4EA0460@altinity.com> Message-ID: <200605021642.08061.benoit.mortier@opensides.be> Le Mardi 2 Mai 2006 13:56, Ton Voon a ?crit?: > On 2 May 2006, at 10:17, Andreas Ericsson wrote: > > This is an english-speaking mailing-list. By sending email in > > french you reach about 5% of the audience and manage to annoy/ > > irritate/aggravate/be ignored by the remaining 95%. > > As one of the mail administrators, I allowed this email to pass > through because there is no specific French mailing list (please > correct me if I am wrong and I will publicise links to it) and if no > one could read or was interested, it would be quietly ignored. Hi, There is a french mailing list but there is not much traffic on it nagios-french at lists.unixtech.be Cheers -- Benoit Mortier CEO www.opensides.be From noreply at sourceforge.net Tue May 2 10:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 2 10:11:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480538 ] -Wall breaks compilation for non-gcc compilers (rel 1.4.3) Message-ID: Bugs item #1480538, was opened at 2006-05-02 19:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480538&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 Submitted By: Ralph R????ner (ralph_roessner) Assigned to: Nobody/Anonymous (nobody) Summary: -Wall breaks compilation for non-gcc compilers (rel 1.4.3) Initial Comment: Including the -Wall compiler flag via AM_CFLAGS in plugins/Makefile.in breaks compilation for all compilers that don't understand this option (all except gcc, I guess). Suggested fix: Either remove this option (who wants warnings from a distribution tarball, anyway?) or make this flag depend on the gcc detection. Please find attached a patch against the Makefile.in that implements the first suggestion (not that you would need me to tell you how to go about it). Regards, Ralph R????ner ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480538&group_id=29880 From noreply at sourceforge.net Tue May 2 11:04:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 2 11:04:15 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480574 ] check_disk is missing -lm on Solaris (rel. 1.4.3) Message-ID: Bugs item #1480574, was opened at 2006-05-02 20:03 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=1480574&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 Submitted By: Ralph R????ner (ralph_roessner) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk is missing -lm on Solaris (rel. 1.4.3) Initial Comment: The common.h include defines, on Solaris only, a replacement definition for floorf(), which Solaris (up to and including version 8) does not have. Thus, on Solaris only, all plugins including common.h need a definition of floor() (on Linux that would be necessary only for those plugins that actually use floorf()), i.e. they need to link libm.so . The Makefile.in does not respect that need, and consequently compiling check_disk on Solaris fails. I would expect all other plugins that include common.h to have the same problem, but strangely that appears not to be the case. For my needs it was sufficient to add MATHLIBS to the dependency line for check_disk in the plugins/Makefile.in, and I include a patch that does exactly that. However, this should probably be resolved more generally. Regards, Ralph R????ner ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 From crpimentel at al.sp.gov.br Tue May 2 13:17:01 2006 From: crpimentel at al.sp.gov.br (Carlos Rodrigues Pimentel) Date: Tue May 2 13:17:01 2006 Subject: [Nagiosplug-devel] Using Nagios to log a host event to an external data-base Message-ID: Hi, Please, can you give some light about using Nagios to log to an external data-base at the same time that it sends a notification by e-mail? What I need to do is write in a file with the .xlm extension ( MS Excel ), that is in a host with MS Windows OS, if it?s possible. My doubt is about the script itself. Can you help me, or indicate some site or something like that, where I can find those explanations? Thanks, Carlos e-mail: crpimentel at al.sp.gov.br From seanius at seanius.net Tue May 2 23:54:17 2006 From: seanius at seanius.net (sean finney) Date: Tue May 2 23:54:17 2006 Subject: [Nagiosplug-devel] Using Nagios to log a host event to an external data-base In-Reply-To: References: Message-ID: <20060503065328.GA30638@seanius.net> hi carlos, On Tue, May 02, 2006 at 04:38:42PM -0300, Carlos Rodrigues Pimentel wrote: > Please, can you give some light about using Nagios to log to an external > data-base at the same time that it sends a notification by e-mail? you should probably take this up on the nagios-devel or nagios-user mailing list, as the plugins project is not the part of nagios in which this would be implmeneted. depending on how you want to implement it (notification hook, ndo2db, NEB), it shouldn't be too hard. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mb at computer-leipzig.com Wed May 3 02:50:06 2006 From: mb at computer-leipzig.com (mb at computer-leipzig.com) Date: Wed May 3 02:50:06 2006 Subject: [Nagiosplug-devel] check_http crashes with -a x Message-ID: <1146649790.44587cbeca64c@mail.computer-leipzig.com> Hi, I want to inform you that ./check_http google.com -a c leads to a crash. To reproduce this bug, the string given to -a must be exactly one character. Kindest regards, Michael Bunk ----------------------------------------- Gesendet mit Computer Leipzig - WebMail http://www.computer-leipzig.de From noreply at sourceforge.net Wed May 3 04:36:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 04:36:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481019 ] Parsing problem within check_ntp Message-ID: Bugs item #1481019, was opened at 2006-05-03 13:35 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=1481019&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: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Nobody/Anonymous (nobody) Summary: Parsing problem within check_ntp Initial Comment: Hallo everybody, I have a little problem with check_ntp. I can work around it by redirecting Stderrout to /dev/null but since this problem exists also in the newest Plugin release 1.4.3 I want to submit this request. Here is what I get when calling check_ntp. Lines are numbered by me! Line 1: Argument "(not parsed)" isn't numeric in abs at /opt/nagios/plugins/check_ntp line 408. Line 2: NTP OK: Offset 0.003125 secs, jitter (not parsed) msec, peer is stratum 1|offset=0.003125, jitter=0,peer_stratum=1 Thanks in advance. Tobias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481019&group_id=29880 From noreply at sourceforge.net Wed May 3 07:15:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:15:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1070929 ] hpjdres Message-ID: Bugs item #1070929, was opened at 2004-11-22 11:17 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1070929&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 Submitted By: SupaFly (amincheneau) >Assigned to: Ton Voon (tonvoon) Summary: hpjdres Initial Comment: Hi I have the error message "No output" in Nagios GUI. The plugin works in command line with root or nagios users. The rights on it are -rwxr-xr-x 1 nagios nagios. my checkcommands.cfg define command { command_name check_hpjdres command_line $USER1$/check_hpjdres -k 1 -H $HOSTADDRESS$ my services.cfg: Define service{ host_name FR40 service_description check_hpjdres check_command toner_black max_check_attempts 3 normal_check_interval 3 retry_check_interval 1 check_period 24x7 notification_interval 0 notification_period 24x7 notification_options w,u,c,r contact_groups admins } ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-12-01 06:19 Message: Logged In: YES user_id=395628 Dear aimincheneau, The plugin works fine both from the CLI and also a test Nag (a 1.0) but that shouldn't be relevant - (%../bin/nagios -m Nagios 1.0 Copyright (c) 1999-2002 Ethan Galstad (nagios at nagios.org) Last Modified: 11-24-2002 License: GPL External Data I/O ----------------- Object Data: TEMPLATE Status Data: DEFAULT Retention Data: DEFAULT Comment Data: DEFAULT Downtime Data: DEFAULT Performance Data: DEFAULT Options ------- * Embedded Perl compiler (With caching) ). Here are the test nag results tsitc> more status.log # Nagios 1.0 Status File [1101880675] PROGRAM;1101880570;87996;0;1101880640;0;1;1;1;1;0;0;1;0 [1101880675] HOST;asterix;PENDING;0;0;0;0;0;0;0;0;1;1;1;1;0;0.0;0;1;1;(Not enough data to determine host status yet) [1101880675] HOST;oradev;UP;1074256506;1074256200;0;27624370;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 0.41 ms [1101880675] HOST;ta27;UP;1101880640;1101880630;0;0;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 1.73 ms [1101880675] SERVICE;ta27;Troublesome check_hpjdres;CRITICAL;1/3;SOFT;1101880630;1101880690;ACTIVE;1;1;1;1101880640;0;OK;0;0;0;0;0;0;1;0;0;1;0;0.00;0;1;1;1;CRITICA L: Toner Cartridge HP C4127X: 2.82608695652174 % tsitc> more status.log # Nagios 1.0 Status File [1101880810] PROGRAM;1101880570;87996;0;1101880810;0;1;1;1;1;0;0;1;0 [1101880810] HOST;asterix;PENDING;0;0;0;0;0;0;0;0;1;1;1;1;0;0.0;0;1;1;(Not enough data to determine host status yet) [1101880810] HOST;oradev;UP;1074256506;1074256200;0;27624370;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 0.41 ms [1101880810] HOST;ta27;UP;1101880760;1101880630;0;0;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 1.70 ms [1101880810] SERVICE;ta27;Troublesome check_hpjdres;CRITICAL;3/3;HARD;1101880750;1101880810;ACTIVE;1;1;1;1101880760;0;CRITICAL;120;0;0;0;1101880760;1;1;0;0;1;0;0.0 0;0;1;1;1;CRITICAL: Toner Cartridge HP C4127X: 2.82608695652174 % tsitc> more status.log # Nagios 1.0 Status File [1101880870] PROGRAM;1101880570;87996;0;1101880870;0;1;1;1;1;0;0;1;0 [1101880870] HOST;asterix;PENDING;0;0;0;0;0;0;0;0;1;1;1;1;0;0.0;0;1;1;(Not enough data to determine host status yet) [1101880870] HOST;oradev;UP;1074256506;1074256200;0;27624370;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 0.41 ms [1101880870] HOST;ta27;UP;1101880820;1101880630;0;0;0;0;0;0;1;1;1;1;0;0.00;0;1;1;PING ok - Packet loss = 0%, RTA = 1.76 ms [1101880870] SERVICE;ta27;Troublesome check_hpjdres;CRITICAL;3/3;HARD;1101880810;1101880870;ACTIVE;1;1;1;1101880760;0;CRITICAL;120;0;0;0;1101880760;1;1;0;0;1;0;0.0 0;0;1;1;1;CRITICAL: Toner Cartridge HP C4127X: 2.82608695652174 % tsitc> >From the CLItsitc> ../libexec/check_hpjdres -H ta27 -k 1 CRITICAL: Toner Cartridge HP C4127X: 2.82608695652174 % tsitc> so it works the same as in Nagios. I found I had to slighlt butcher the plugin to get it to work with perl5.005_03/Net::SMP v3, but if you got it woirk from the CLI that is not your problem. At this point, I am at a loss for helpful remarks tsitc> ../libexec/check_hpjdres -V check_hpjdres (nagios-plugins 1.4.0alpha1) 1.0 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. tsitc> Here's my checkcommand entry # 'check_hpjdres' command definition define command{ command_name check_hpjdres command_line $USER1$/check_hpjdres -H $HOSTADDRESS$ -k 1 } % It's the same as yours. What version of Net::SNMP do you use ? ---------------------------------------------------------------------- Comment By: SupaFly (amincheneau) Date: 2004-11-29 11:49 Message: Logged In: YES user_id=1133930 Hi stanley and thank you to help me! I'm not sure to understand what you did! The plugin works for me just in command line, does it work for you in nagios or in command line? Regards ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-26 08:49 Message: Logged In: YES user_id=395628 Dear aimincheneau, Plugin should be comitted (like me) RSN to /contrib. The plugin seems to work Ok for me. eg from the CLI pc09011> ./check_hpjdres -H ta27 -k 1 WARNING: Toner Cartridge HP C4127X: 14.3478260869565 % pc09011> ./check_hpjdres -H ta28 -k 1 CRITICAL: Toner Cartridge HP C4127X: 0 % pc09011> ./check_hpjdres -H ta29 -k 1 UNKNOWN: Unable to resolve destination UDP/IPv4 address 'ta29'pc09011> pc09011> ./check_hpjdres -H print001 -k 1 UNKNOWN: Unable to resolve destination UDP/IPv4 address 'print001'pc09011> pc09011> ./check_hpjdres -H n001 -k 1 CRITICAL: Toner Cartridge HP C4127X: 0 % With an embedded Perl Nagios simulator it also seems to work. pc09011> ./test_epn_arg1.pl check_hpjdres -H ta28 -k 1 (2, 'CRITICAL: Toner Cartridge HP C4127X: 0 %'). pc09011> ./test_epn_arg1.pl check_hpjdres -H ta27 -k 1 (1, 'WARNING: Toner Cartridge HP C4127X: 14.3478260869565 %'). pc09011> Give it a crack noting that 1 if you use embedded Perl Nagios at the present release level - you get NO FEEDBACK if the plugin raises a runtime exception. This is being addressed (in both versions of Nag 1.x and 2.x). If you use embedded Perl please write something positive about it. I use it and I LIKE it but then again I am biased. Give iit a shot. Yours sincerely. ---------------------------------------------------------------------- Comment By: SupaFly (amincheneau) Date: 2004-11-24 12:57 Message: Logged In: YES user_id=1133930 You're fully apologized! I send you the link to download check_hpjdres: http://sourceforge.net/tracker/download.php? group_id=29880&atid=541465&file_id=44083&aid=692207 You need to install the net::snmp module to make workt it! http://search.cpan.org/CPAN/authors/id/D/DT/DTOWN/Net- SNMP-5.0.1.tar.gz But to test this plugin you need to have a hp or Xerox network printer, it gives you the state of your toners. when you type ./check_hpjdres -k 1 -H "address of your printer" "-k 1" it's for black toner, you can change the value by 2,3,4 if you have a color printer and more for Xerox. Regards. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-24 11:51 Message: Logged In: YES user_id=395628 Dear aimincheneau, Sorry for the stupid answer; oh dear ! As for check_hpjdres, there doesn't seem to be a plugin named check_hpjdres in the 1.4alpha distro (I am working from the CVS but the tar-ball should be the same). I am sorry to be speaking with all the grace and intellect of a donkey, but I am confused. pc09011> pwd /usr/home/anwsmh/build/nagios-plugins_HEAD/nagiosplug pc09011> find . -name 'check_hp*' -ls 1865383 16 -rwxr-xr-x 1 anwsmh anwsmh 7502 Nov 23 17:25 ./contrib/check_hprsc.pl 1896751 2 -rw-r--r-- 1 anwsmh anwsmh 637 Nov 23 17:25 ./plugins/t/check_hpjd.t 1896776 22 -rw-r--r-- 1 anwsmh anwsmh 10356 Nov 23 17:25 ./plugins/check_hpjd.c 1896823 2 -rw-r--r-- 1 anwsmh anwsmh 96 Nov 23 17:25 ./plugins/tests/check_hpjd 1904794 6 -rw-r--r-- 1 anwsmh anwsmh 2199 Nov 23 19:09 ./plugins/.deps/check_hpjd.Po 1897436 62 -rw-r--r-- 1 anwsmh anwsmh 30844 Nov 23 19:09 ./plugins/check_hpjd.o 1897437 336 -rwxr-xr-x 1 anwsmh anwsmh 157162 Nov 23 19:09 ./plugins/check_hpjd pc09011> Could you tell me about this plugin - or send me a copy, and I'll put it back where it belongs ? With regret, ---------------------------------------------------------------------- Comment By: SupaFly (amincheneau) Date: 2004-11-24 11:13 Message: Logged In: YES user_id=1133930 Thanks for your answer stanley, I have a problem with check_hpjdres plugin and not with check_hpjd (which is working fine). ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-24 03:10 Message: Logged In: YES user_id=395628 Dear aimincheneau, The latest plugin versions do _not_ have a k option (-k in your command_line). pc09011> ./check_hpjd -h check_hpjd (nagios-plugins 1.4.0alpha2) 1.18 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. Copyright (c) 1999 Ethan Galstad Copyright (c) 2000-2003 Nagios Plugin Development Team This plugin tests the STATUS of an HP printer with a JetDirect card. Net-snmp must be installed on the computer running the plugin. Usage: check_hpjd -H host [-C community] check_hpjd (-h | --help) for detailed help check_hpjd (-V | --version) for version information Options: -h, --help Print detailed help screen -V, --version Print version information -C, --community=STRING The SNMP community name (default=public) Send email to nagios-users at lists.sourceforge.net if you have questions regarding use of this software. To submit patches or suggest improvements, send email to nagiosplug-devel at lists.sourceforge.net pc09011> ./check_hpjd -H ta27 Printer ok - (STRING: "PROCESSING JOB.FROM TRAY 3") pc09011> ./check_hpjd -H ta27 -k 1 ./check_hpjd: invalid option -- k Invalid argument Usage: check_hpjd -H host [-C community] check_hpjd (-h | --help) for detailed help check_hpjd (-V | --version) for version information pc09011> Could this be a mistake in your command_line ? ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-24 00:59 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1070929&group_id=29880 From noreply at sourceforge.net Wed May 3 07:15:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:15:15 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-853461 ] check_flexlm always reports OK Message-ID: Bugs item #853461, was opened at 2003-12-03 18:15 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=853461&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 Submitted By: Nico Kadel-Garcia (nkadel) >Assigned to: Ton Voon (tonvoon) Summary: check_flexlm always reports OK Initial Comment: Under nagios 1.1, nagios-plugins-1.4.0alpha1 on RedHat 9. the return result of the check_flexlm has no effect on nagios results. Turning off a license server entirely shows no failure in Nagios, with or without the patches I've been working on to more correctly report down servers. Here's the output of the old check_flexlm: ./check_flexlm -F /usr/local/flexlm/licenses/license.dat License Servers NOT running:lmgrd is not running: Cannot connect to license server (-15,570 |flexlm::up:0;down:1 The new one that I've modified to better report quorum license servers also has the same result. But it just doesn't show up in Nagios as being down at all, and I don't understand the details of Nagios handling of the "$ERRORS" enough to debug it myself without investing a bunch of time. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-24 00:52 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-23 09:01 Message: Logged In: YES user_id=395628 It appears that this plugin is the subject of enhancements/corrections by nkadel. Will wait to hear from NKadel. ---------------------------------------------------------------------- Comment By: Nico Kadel-Garcia (nkadel) Date: 2003-12-11 15:52 Message: Logged In: YES user_id=923047 I'm sorry, this should have been submitted by me as a bug. In any case, the problem is a mis-parsing by the check_flexlm.pl script of services.cfg entries that have a '%' in filename (there was a typo there), and the results not showing up in the check_flexlm.pl output due to Perl style mis-handling of that character. I'm modifying my copy of it to actually check for the existence of an openable license file before passing off the arguments to the lmstat command, which should deal with the problem. ---------------------------------------------------------------------- Comment By: Nico Kadel-Garcia (nkadel) Date: 2003-12-11 15:33 Message: Logged In: YES user_id=923047 This should have been put in as a bug report, not a feature request. My apologies. It turns out that if you have a '%' on the end of the filename in for the check_flexlm service test in services.cfg, the check_flexlm.pl does not detect or parse it or the flexlm error messages correctly. The '%' gets interpreted at various points by the Perl parser itself, which leads to the confusion. I'm working on some other new features, such as testing for the existence of the license file in the check_flexlm.pl itself and more correctly parsing lines that have multiple ':' characters in them, and will submit it when done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=853461&group_id=29880 From noreply at sourceforge.net Wed May 3 07:15:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:15:17 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-694259 ] Cannot map "tcp" to protocol number Message-ID: Bugs item #694259, was opened at 2003-02-27 09:50 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=694259&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: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Alexander Wolters (diamondlink) >Assigned to: Ton Voon (tonvoon) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-24 00:50 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2004-11-22 07:30 Message: Logged In: YES user_id=1156501 The problem is that a nice port number like "1248" is used by a few applications. It was a bad choice for a default. Microsoft Exchange uses it, something called "hermes" uses it, and possible AppleTalk too. You need to change the port number by editing the registry. See \HKEY_LOCAL_MACHINE\SOFTWARE\NSClient We (as Nagios) should probably consider changing the default port number. Port 2151 looks free. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-22 06:36 Message: Logged In: YES user_id=395628 Dear Diamond link, Firstly, sorry for the slow response; thanks for your patience. A recent question on Nag users about this matter was caused by a bad libc (IIRC). http://article.gmane.org/gmane.network.nagios.user/24992/match=++map+protocol Is this any help ? If not, is tcp in /etc/protocols ? HTH, Yours sincerely. ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-03-12 19:54 Message: Logged In: YES user_id=10485 Is this still an issue with 1.3.0 final release? Has it been tested and confirmed as still being a problem with CVS version? ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 10:17 Message: Logged In: YES user_id=721439 nagios-1.0 nagios-plugins-1.3.0.b2 ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 10:02 Message: Logged In: YES user_id=721439 It's FreeBSD 5.0 ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 09:39 Message: Logged In: YES user_id=721439 I'm getting the error message @ the unix machine ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 16:19 Message: Logged In: YES user_id=46572 where are you getting the error? on the windows machine or on the unix machine? What versions are you running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=694259&group_id=29880 From noreply at sourceforge.net Wed May 3 07:15:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:15:19 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-668778 ] check_ircd - invalid argument Message-ID: Bugs item #668778, was opened at 2003-01-15 22:51 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&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 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Ton Voon (tonvoon) Summary: check_ircd - invalid argument Initial Comment: Any ideas what im doing wrong here libexec]# ./check_ircd -v -H xxx.xxx.xxx.xxx MAIN(debug): hostname = something.host.name MAIN(debug): binding to remote host: xxx.xxx.xxx.xxx - > 6667 -> something.host.name IRCD UNKNOWN: Could not connect socket (Invalid argument) something.host.name and xxx.xxx.xxx.xxx are valid hostnames and ips just edited out in this post I get the same (IRCD UNKNOWN: Could not connect socket (Invalid argument)) as status when it is run by nagios. ./check_ircd -V check_ircd (nagios-plugins 1.3.0-beta2) 1.3 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. This is when it is run in its unmodified form installed from source and compiled, or usign an rpm build Thanks in advance for any advice. Sarah ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2004-12-05 22:31 Message: Logged In: YES user_id=983566 I'm having this problem in my testing as well (perl, v5.8.4 debian unstable). It seems to be something broken in perl's socket code. It's mentioned here http://wiki.apache.org/spamassassin/IoSocketInetInvalidArgument The solution for me was to remove my computers hostname from the /etc/hosts loopback 127.0.0.1 azul localhost to 127.0.0.1 localhost and poof it works... strange problem indeed! ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-24 00:50 Message: Logged In: YES user_id=664364 Moving to Bugs tracker as Support Requests will be closed. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-23 04:56 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-23 03:06 Message: Logged In: YES user_id=395628 I can't repeat this behaviour (ie invalid argument -H) with check_ircd in the 1.4 alpha plugins release (check_ircd (nagios-plugins 1.4.0alpha2) 1.3). Would you retry with this release ? (Unfortch I can't test the plugin function). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-01-16 05:58 Message: Logged In: YES user_id=46572 Is your IRC server running on port 6667 ?? Please followup on the mailing list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=668778&group_id=29880 From noreply at sourceforge.net Wed May 3 07:16:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:16:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1196550 ] Fixed typo in Lotus Plugin Message-ID: Patches item #1196550, was opened at 2005-05-06 13:58 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1196550&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 Submitted By: B. Czech (bczech) >Assigned to: Ton Voon (tonvoon) Summary: Fixed typo in Lotus Plugin Initial Comment: The Server DN was checked in a case sensetive way. Source: contrib/check_lotus.pl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1196550&group_id=29880 From noreply at sourceforge.net Wed May 3 07:16:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 07:16:09 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1041571 ] simap,spop certificate check and new check_nntps check Message-ID: Patches item #1041571, was opened at 2004-10-06 17:05 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1041571&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Chen (chen23) >Assigned to: Ton Voon (tonvoon) Summary: simap,spop certificate check and new check_nntps check Initial Comment: these patches add a certificate check for check_simap and check_spop. this also adds a new check for nntps this also requires adding to configure.in: check_tcp_ssl="check_simap check_spop check_nntps" patches agains nagios-plugins-1.3.1 built on Solaris 9 w/ Forte Developer 7 C 5.4 ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-12-03 21:57 Message: Logged In: YES user_id=395628 Dear Eric, Thanks for your patience once again. Corrected -D option processing in CVS. pc09011> ./check_tcp -H pericles.IPAustralia.Gov.AU -p 443 -D 3 Certificate will expire on 04/30/2005 23:5. pc09011> ---------------------------------------------------------------------- Comment By: Eric Chen (chen23) Date: 2004-12-03 12:16 Message: Logged In: YES user_id=271106 the last patch isn't quite what i submitted. the diff added ":D" when it should have been "D:". i haven't tested the code, but i expect that it probably still fails. thanks. -eric ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-12-03 04:00 Message: Logged In: YES user_id=395628 Dear Eric, Thank you for your patches, testing and feedback. Your corection has been added to the CVS. Thank you ! revision 1.49 date: 2004/12/02 21:03:26; author: stanleyhopcroft; state: Exp; lines: +4 -4 Tracker 1041571: appended :D to getopt_long() args (for cert expiry check). Eric Chen. ---------------------------- ---------------------------------------------------------------------- Comment By: Eric Chen (chen23) Date: 2004-12-02 14:59 Message: Logged In: YES user_id=271106 from: nagios-plugins-HEAD-200412020547 missing "-D" arg in getopt in plugins/check_tcp.c: c = getopt_long (argc, argv, "+hVv46H:s:e:q:m:c:w:t:p:C:W:d:Sr: jD:",longopts, &option); otherwise functioning as expected ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-12-01 08:34 Message: Logged In: YES user_id=395628 Committed to head. Sorry for the delay - blast need to deal with configure.in also. Would you mind testing ? ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-11-30 03:23 Message: Logged In: YES user_id=395628 Dear Eric, Thanks for the patches and your patience with the long wait for a response. I hope to apply them as soon as I can understand them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1041571&group_id=29880 From noreply at sourceforge.net Wed May 3 23:05:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 3 23:05:06 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 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=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Thu May 4 01:43:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 4 01:43:12 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1481689 ] Support HP-UX Ansi C Message-ID: Feature Requests item #1481689, was opened at 2006-05-04 10:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1481689&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: Support HP-UX Ansi C Initial Comment: Hi, if you configure the plugins using the hp- ux /opt/ansic/bin/cc compiler, openssl libraries in non-system locations will not be found. if test "$OPENSSL" != "/usr"; then CPPFLAGS="$CPPFLAGS -I$OPENSSL/include" LDFLAGS="$LDFLAGS -R$OPENSSL/lib" fi So if you have a /tmp/nagios/local/lib/libssl like i have, there will be a call like: cc -Ae .... -R/tmp/nagios/local/lib which fails because the hp-ux compiler does not accept the -R option. I propose to replace the -R with a -L in the configure.in Greetings from Munich, Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1481689&group_id=29880 From ronneil.camara at wamu.net Fri May 5 01:34:06 2006 From: ronneil.camara at wamu.net (Camara, Ronneil) Date: Fri May 5 01:34:06 2006 Subject: [Nagiosplug-devel] nagios-plugins-1.4.3 make problems Message-ID: <1156390DD9D2B4499A0B9809AB20BE950315FD89@exmsea011.us.wamu.net> Please help. I'm getting an error when doing a make. check_snmp.c: In function `main': check_snmp.c:341: syntax error before `char' check_snmp.c:342: `str' undeclared (first use in this function) check_snmp.c:342: (Each undeclared identifier is reported only once check_snmp.c:342: for each function it appears in.) *** Error code 1 Stop in /usr/local/src/nagios-plugins-1.4.3/plugins. *** Error code 1 Stop in /usr/local/src/nagios-plugins-1.4.3/plugins. *** Error code 1 Stop in /usr/local/src/nagios-plugins-1.4.3. *** Error code 1 Stop in /usr/local/src/nagios-plugins-1.4.3. Thanks, Ronneil From noreply at sourceforge.net Fri May 5 01:38:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 01:38:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 07:04 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) >Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-05 09:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Fri May 5 01:46:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 01:46:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-822662 ] check_tcp does not return "TCP CRITICAL" Message-ID: Bugs item #822662, was opened at 2003-10-13 12:00 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=822662&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: Open Resolution: None Priority: 5 Submitted By: Hugo Monteiro (hvm_pt) >Assigned to: Ton Voon (tonvoon) Summary: check_tcp does not return "TCP CRITICAL" Initial Comment: check_tcp plugin should return a "TCP CRITICAL: Connection refused by host" when the tcp service port checked is down. example: "check_tcp server1 -p 3128" (SQUID Port) If the squid service is down we get a "Connection refused by host" but we should get a "TCP CRITICAL: etc.." since this service is down. Because of this, Nagios puts this service in the critical services group, but we can't get any availability report because services checked by this plugin (using check_tcp xxx -p xxxx) are not returning valid exit codes/echoes: "TCP OK", "TCP WARNING" or "TCP CRITICAL". This service check not even appear has unknown!?!! ---------------------------------------------------------------------- Comment By: Chris Funderburg (funderburg) Date: 2005-05-19 13:54 Message: Logged In: YES user_id=10827 This still appears to not work even in CVS code. Is Nagios not being maintained anymore ? ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-10-13 17:23 Message: Logged In: YES user_id=10485 I believe if you check the contents of nagios-10-10-2003-00.log thru nagios-10-10-2003-23.log you would find that all the entries are for the same day but the logs have been truncated because they grew to be too long... What you need to do when doing reports is to tell it that it can go back through more logs by setting the "Backtracked Archives" to higher than the default (which for me is 2)... ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-10-13 16:48 Message: Logged In: YES user_id=664364 I had a problem with extra nagios logs being created (with - 23). It turned out to be an NTP problem on the server I was using. See http://www.nagios.org/faqs/viewfaq.php? faq_id=93 for the resolution. ---------------------------------------------------------------------- Comment By: Hugo Monteiro (hvm_pt) Date: 2003-10-13 16:37 Message: Logged In: YES user_id=12156 Additional notes: The exit code seems to be valid to NAGIOS process, it can process it well. The problem was that something broke the archived LOG, it appeared "nagios-10-10-2003-23.log" (notice the -23) instead of "nagios-10-10-2003-00.log". That was why this services didn't appear in the Availability Report. (I'm still searching what caused this.) Besides this, i've added the following lines to 'netutils.c' starting line 309: -- cut here -- printf ("CONNECTION CRITICAL: "); --- end cut --- So, if we cannot make a connection it will print something like CONNECTION CRITICAL: "+"Error message from the 'switch/case on the line below"' example: "CONNECTION CRITICAL: Connection refused by host." PS: Check all information i sent and see if this really is an check_tcp plugin issue, and something needs to be modified, or if this bug report can be closed. ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-10-13 14:28 Message: Logged In: YES user_id=10485 As I've done quite a few changes in the current CVS HEAD version of the check_tcp code I believe I know where this problem lies. It seems to be in the actual connection code and not in the processing of the reply as it never gets the connection socket to open. I'll look into it and see if this is possible to preface with "TCP CRITICAL" however the code to my knowledge DOES return the proper exit code it is just the human readable details that is failing to display. ---------------------------------------------------------------------- Comment By: Hugo Monteiro (hvm_pt) Date: 2003-10-13 12:46 Message: Logged In: YES user_id=12156 The problem seems to be in "netutils.c" file between line 308 and 320. Even if this errors are not known, a plugin should always return a known error (OK, WARNING, CRITICAL or UNKNOWN) if it sends anything besides this, it will break Nagios service information (reports, stats, etc.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=822662&group_id=29880 From noreply at sourceforge.net Fri May 5 01:46:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 01:46:06 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-772366 ] check_udp2 on 1.3.1 ? Message-ID: Bugs item #772366, was opened at 2003-07-16 16:04 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=772366&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Release (specify) Status: Open Resolution: Invalid Priority: 5 Submitted By: R?nald CASAGRAUDE (kipit) >Assigned to: Ton Voon (tonvoon) Summary: check_udp2 on 1.3.1 ? Initial Comment: Is it normal that check_udp2 (symbolic link to check_tcp) disappear from this release ? This link is present on nagios-plugins-CVS and creating the link by hand with 1.3.1 (release) do the job... If the disappearance of check_udp2 is normal, how to check if an udp port is open ? ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-07-17 06:15 Message: Logged In: YES user_id=10485 The link was removed from the 1.3.1 release as it was only added to the CVS HEAD tag... It also has been found to not operate properly, thus it's removal keeps repeated bugs saying it doesn't work from being filed until it can be fixed properly... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=772366&group_id=29880 From noreply at sourceforge.net Fri May 5 01:46:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 01:46:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-731467 ] check_udp returns exit code 0 everytime Message-ID: Bugs item #731467, was opened at 2003-05-02 18:13 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=731467&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 Submitted By: Kevin O'Brien (irishpadres) >Assigned to: Ton Voon (tonvoon) Summary: check_udp returns exit code 0 everytime Initial Comment: If I use the check_tcp symlinked version of check_udp I get and exit code of 0 every time I run the script. I can give it any host and and any port and it will always exit 0 with 0.0001 second response time. I've tried this on both a Linux and Solaris box with the same result. ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-06-30 18:45 Message: Logged In: YES user_id=10485 I believe the problem lies in actually how the UDP ports are being check'd as I'm sure if you ran the same tests you ran with check_udp2 using check_udp they would all give the same result... Only difference is that result would be a no data from host failure... I'm looking into this to see how it can be handled better and more accurately... ---------------------------------------------------------------------- Comment By: Kevin O'Brien (irishpadres) Date: 2003-06-30 18:41 Message: Logged In: YES user_id=753604 yes, I'm talking about check_udp2. I've tested against many different kind of udp ports (ntp, dns, nfs, etc) on localhost and remote hosts and always returns the same exit code regardless of whether they are up or not (and yes the ports are actually open). ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-06-29 19:02 Message: Logged In: YES user_id=10485 I assume you mean check_udp2? Are you checking against UDP ports you know to be open and closed or are they unknown and trying to use it to test? I'm the one that added the symlink but haven't been able to give it a full test for accuracy yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=731467&group_id=29880 From noreply at sourceforge.net Fri May 5 01:48:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 01:48:00 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-647959 ] check_dns fix Message-ID: Patches item #647959, was opened at 2002-12-03 18:11 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=647959&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: 1 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Ton Voon (tonvoon) Summary: check_dns fix Initial Comment: check_dns fix, uses a dns resolver directly, instead of the nslookup program. Gutted (changed) a decent amount of code, also NOTE the diff is run against nagiosplug-1.3-beta1 ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-03-16 23:50 Message: Logged In: YES user_id=10485 As this is a new plugin (check_dns_resolver) rather than a patch to check_dns... As well the patch is reversed and unable to be applied to current code base... Please subit check_dns_resolver.c as a new plugin under the appropriate new plugin tracker for evaluation and inclusion... ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-03-12 19:56 Message: Logged In: YES user_id=10485 I'm looking into the patch as I'm making updates for AF-independent code and working on similar fix for check_ping ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-02-11 18:39 Message: Logged In: YES user_id=10485 I would recommend holding off to 1.4 as well since it's a major overhaul... Although the same idea may be applied at that time to others (ie- check_ping and check_dig) as well... ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2003-01-29 06:32 Message: Logged In: YES user_id=1671 I'm thinking this is a little to big a change for 1.3 -- If we do theis now, I''d suggest as a contrib until 1.4. Other thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=647959&group_id=29880 From noreply at sourceforge.net Fri May 5 09:04:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 09:04:08 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 Message generated for change (Comment added) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Tobias Mucke (mucke) Date: 2006-05-05 16:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 10:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Fri May 5 18:50:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 18:50:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1482832 ] check_smtp problem with TLS+AUTH using Exim Message-ID: Bugs item #1482832, was opened at 2006-05-06 03:49 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=1482832&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Holger Weiss (hweiss) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp problem with TLS+AUTH using Exim Initial Comment: When checking SMTP AUTH via TLS using Exim, you'll get a "503 AUTH command used when not advertised" error if trying to use AUTH without (re)sending EHLO _after_ the TLS negotiation. RFC 3207 (4.2) says: "The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation." The attached patch does just that in order to make the check_smtp plugin work with TLS+AUTH using Exim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482832&group_id=29880 From noreply at sourceforge.net Fri May 5 19:30:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 5 19:30:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1482840 ] check_radius from 1.4.3 fails to build Message-ID: Bugs item #1482840, was opened at 2006-05-06 04:29 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=1482840&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 Submitted By: Holger Weiss (hweiss) Assigned to: Nobody/Anonymous (nobody) Summary: check_radius from 1.4.3 fails to build Initial Comment: check_radius from the 1.4.3 release fails to build on Debian Sarge (the 1.4.2 release works fine): /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -o check_radius check_radius.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lradiusclient -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_radius check_radius.o netutils.o utils.o -L/server/nagios/src/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so -lcrypt -lnsl -lssl -lcrypto gcc: /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so: No such file or directory make[3]: *** [check_radius] Error 1 Manually building check_radius by replacing the broken path to libradiusclient.so with "-lradiusclient" works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&group_id=29880 From noreply at sourceforge.net Mon May 8 11:09:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon May 8 11:09:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 Message generated for change (Comment added) made by ralph_roessner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- Comment By: Ralph R????ner (ralph_roessner) Date: 2006-05-08 20:08 Message: Logged In: YES user_id=1515003 Hi everybody! I have a similar problem on Solaris, only I get bitten by validate_arguments(), which complains that "C_IDFP (67065044...467904.000000) should be less than W_IDFP (0.0)". It appears that the minimum free inode percentage was not correctly initialized. This only appears when file systems are selected with "-p". The reason I suspect is that the c_idfp and w_idfp members of the path list structure are never initialized in this case, at least not at the point where c_dfp and w_dfp are (check_disk.c lines 457ff). So random malloc()ed memory is passed to validate_arguments(), and the results vary according to architecture and phase of the moon. I created a patch that treats the [cw]_idfp like [cw]_dfp at the point where the "-p" argument is parsed. This makes the problem go away for me. If there are other places where the path list is added to then there is a good chance that the same oversight happened there too. Since I don't find a way to attach a file to a thread I did not open, I will include the patch here: --8><----------------------------------- *** nagios-plugins-1.4.3/plugins/check_disk.c.orig Mon May 8 19:50:33 2006 --- nagios-plugins-1.4.3/plugins/check_disk.c Mon May 8 19:49:48 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; --8><----------------------------------- Hope this helps, Ralph R????ner ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-05 16:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 10:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Tue May 9 09:32:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 9 09:32:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 16:31 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=1484822&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 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From noreply at sourceforge.net Tue May 9 09:36:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 9 09:36:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484825 ] check_dhcp fails to link on Solaris 2.6 Message-ID: Bugs item #1484825, was opened at 2006-05-09 16:35 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=1484825&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 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp fails to link on Solaris 2.6 Initial Comment: /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a -liconv -lgen -lnsl gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/tmp/nagios-plugins-1.4.3/plugins-root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lresolv ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lnsl -R/usr/local/lib -R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 ===== Modifying the Makefile EXTRA_NETOBJS = getaddrinfo.o gethostbyname.o to EXTRA_NETOBJS = ../plugins/getaddrinfo.o ../plugins/gethostbyname.o fixes it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 From noreply at sourceforge.net Wed May 10 06:10:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 10 06:10:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1485559 ] Changes to the check_ntp perl-plugin Message-ID: Patches item #1485559, was opened at 2006-05-10 13:09 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=1485559&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 Submitted By: Johan Nilsson (riksdagen) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to the check_ntp perl-plugin Initial Comment: In the course of upgrading Nagios from 1.3 to 2.1 on a Debian/GNU-machine, I saw a problem with the check_ntp perl-script. The plugin returns "UNKNOWN" if the ntp-server replies to the ntpdate-request, but the ntpq-request times out. The exact error-message is "Use of uninitialized value in division (/) at ./check_ntp line 431.", but on the next row the plugin reports the status of the ntp-server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1485559&group_id=29880 From tom.moore at sas.com Wed May 10 08:11:02 2006 From: tom.moore at sas.com (Tom Moore) Date: Wed May 10 08:11:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1476451 ] pst3 does not exist In-Reply-To: References: Message-ID: <20060510143650.28D5C4F476B@desire.netways.de> Hi SourceForge.net I'm getting the exact same errors, on Solaris 10. Seems like we are missing a library that provides the kvm_* functions. Any idea what provides that? - Tom Moore (tmoore) ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofa q_pi1[showUid]=17648 From noreply at sourceforge.net Wed May 10 08:20:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 10 08:20:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1485683 ] check_disk addition to exclude all mountpoints within a path Message-ID: Feature Requests item #1485683, was opened at 2006-05-10 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1485683&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk addition to exclude all mountpoints within a path Initial Comment: check_disk currently allows mount points to be excluded via the -x /mount/point command; however, this is causing some issues with Solaris and its cdrom. It would be nice to have the -x command updated to allow a wildcard to be used to exclude all mountpoints within a path. ie -x /cdrom/* I've included some output to illustrate why I believe this to be necessary. Here is a snippet of output from the check_disk command: /cdrom/sol_9_905_sparc/s2=0MB;0;0;0;0 /cdrom/sol_9_905_sparc/s1=494MB;444;469;0;494 /cdrom/sol_9_905_sparc/s0=2349MB;2114;2231;0;2349 df -h: /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s5 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s5 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s4 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s4 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s3 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s3 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s2 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s2 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s1 495M 468M 0K 100% /cdrom/sol_9_905_sparc/s1 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s0 2.3G 2.3G 0K 100% /cdrom/sol_9_905_sparc/s0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1485683&group_id=29880 From noreply at sourceforge.net Wed May 10 10:53:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 10 10:53:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 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=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Wed May 10 11:32:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 10 11:32:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485847 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485847, was opened at 2006-05-10 14:31 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=1485847&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 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485847&group_id=29880 From noreply at sourceforge.net Wed May 10 11:33:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 10 11:33:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485847 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485847, was opened at 2006-05-10 14:31 Message generated for change (Settings changed) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485847&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: Deleted Resolution: None Priority: 5 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485847&group_id=29880 From mwilson at uindy.edu Wed May 10 11:48:02 2006 From: mwilson at uindy.edu (Matthew Wilson) Date: Wed May 10 11:48:02 2006 Subject: [Nagiosplug-devel] check_dhcp / rogue dhcp server detection Message-ID: <4462352C.4050708@uindy.edu> Has anyone given any thought to adding a flag to check_dhcp, so that when IPs are returned, the specified servers are the ONLY servers that can respond. Currently, check_dhcp makes sure that each server in the list responds, but what if there's an additional dhcp server that responds? This might be an effective way to actively monitor for rogue dhcp servers on your network. I was considering having a stab at it myself, but I'd rather not if someone's already implemented it (not to mention my C skills are rather lacking). Thanks! Matthew From seanius at seanius.net Wed May 10 12:48:03 2006 From: seanius at seanius.net (sean finney) Date: Wed May 10 12:48:03 2006 Subject: [Nagiosplug-devel] check_dhcp / rogue dhcp server detection In-Reply-To: <4462352C.4050708@uindy.edu> References: <4462352C.4050708@uindy.edu> Message-ID: <20060510194736.GA17089@seanius.net> On Wed, May 10, 2006 at 02:47:08PM -0400, Matthew Wilson wrote: > Has anyone given any thought to adding a flag to check_dhcp, so that > when IPs are returned, the specified servers are the ONLY servers that > can respond. Currently, check_dhcp makes sure that each server in the > list responds, but what if there's an additional dhcp server that > responds? This might be an effective way to actively monitor for rogue > dhcp servers on your network. that's a pretty cool idea. i don't imagine it would be too hard to implement. if you threw together a rough proof of concept i'd be happy to take a look if no one else gets to it first. i'll be in mexico at debconf next week, send me a ping after that if no one else has picked this up. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From benny at bennyvision.com Wed May 10 14:07:03 2006 From: benny at bennyvision.com (C. Bensend) Date: Wed May 10 14:07:03 2006 Subject: [Nagiosplug-devel] check_dhcp / rogue dhcp server detection In-Reply-To: <20060510194736.GA17089@seanius.net> References: <4462352C.4050708@uindy.edu> <20060510194736.GA17089@seanius.net> Message-ID: <3052.134.244.169.17.1147295156.squirrel@webmail.stinkweasel.net> >> Has anyone given any thought to adding a flag to check_dhcp, so that >> when IPs are returned, the specified servers are the ONLY servers that >> can respond. Currently, check_dhcp makes sure that each server in the >> list responds, but what if there's an additional dhcp server that >> responds? This might be an effective way to actively monitor for rogue >> dhcp servers on your network. > > that's a pretty cool idea. i don't imagine it would be too hard to > implement. if you threw together a rough proof of concept i'd be > happy to take a look if no one else gets to it first. > > i'll be in mexico at debconf next week, send me a ping after that > if no one else has picked this up. This is exactly the thing I proposed late last year, after a rogue DHCP server was accidentally started on our LAN. I bantered back and forth with several members of the list (I remember Andreas for sure), but it was beyond my meager (nay, pathetic!) programming skills. Benny -- "God help us all if cats had thumbs." -- Me, 2006 From cmr at financial.com Wed May 10 23:23:01 2006 From: cmr at financial.com (Christoph Maser) Date: Wed May 10 23:23:01 2006 Subject: [Nagiosplug-devel] nagiosplug contrib section Message-ID: <4462D82C.8080907@financial.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, i wonder what happens to modules in the contrib-dir of nagiosplug. One of my plugins is in there and i currently update it a bit. So shall i post my updates somewhere except nagiosexchange.org? Also there is a patch in the patchtracker of nagiosplug for this plugin unassigned since december 05, what will happen to it? Would't it be best to kill of the contrib in nagiosplug and let it all happen elswhere (nagiosexchange)? Chris - -- financial.com AG Maria-Probst-Stra?e 19 Tel.: ++49(0)89/318528-44 D- 80939 M?nchen Fax.: ++49(0)89/318528-28 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEYtgssLjW0HYht7URAv0cAKDdkzYctK+HOEgaEzXgnVwcUHSY6gCgj0S4 oMHS2AuxPLJr9pVF7hYna/E= =MdGX -----END PGP SIGNATURE----- From ton.voon at altinity.com Thu May 11 02:14:02 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu May 11 02:14:02 2006 Subject: [Nagiosplug-devel] nagiosplug contrib section In-Reply-To: <4462D82C.8080907@financial.com> References: <4462D82C.8080907@financial.com> Message-ID: <3A36F095-758F-4DFA-B688-0BB10FF746DE@altinity.com> Hi Chris, The intention is that the contrib directory will be removed. Nagiosexchange is the official area for third party repositories. We just haven't gone through the work of removing all contributed plugins. I understand this must cause confusion. Can you drop me an email offline re: which plugins you want removed and we'll take them out of the distribution. I think my work will be: - mark a notice in the README of the dist that the contrib area will be removed in a future release and to reference nagiosexchange - drop an email to all developers of each contrib plugin to say that they should post to nagiosexchange - close any SF trackers re: contrib plugins Would this be sufficient? Ton On 11 May 2006, at 07:22, Christoph Maser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > i wonder what happens to modules in the contrib-dir of nagiosplug. > One of my plugins is in > there and i currently update it a bit. So shall i post my updates > somewhere except > nagiosexchange.org? Also there is a patch in the patchtracker of > nagiosplug for this > plugin unassigned since december 05, what will happen to it? > Would't it be best to kill of > the contrib in nagiosplug and let it all happen elswhere > (nagiosexchange)? > > Chris http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From wolvverine at tarchomin.pl Thu May 11 02:21:05 2006 From: wolvverine at tarchomin.pl (=?iso-8859-2?Q?Micha=B3?= Panasiewicz) Date: Thu May 11 02:21:05 2006 Subject: [Nagiosplug-devel] check_snmp_mem.pl - allways bee critical because linux all free RAM reserwed for buffers/cache In-Reply-To: <20060319164513.0C5E61953BD@mail.proy.org> References: <20060319164513.0C5E61953BD@mail.proy.org> Message-ID: <1147339210.23398.2.camel@localhost> Dnia 19-03-2006, nie o godzinie 17:45 +0100, Patrick Proy napisa?(a): > Hi, > > You can find here the latest version of check_snmp_mem.pl wich doesn't include cached memory in the used memory (derived from a patch of Erik Romijn) : > http://www.manubulon.com/nagios/dev/check_snmp_mem.pl > There is still an option to include it if needed (-m). write me: ***** Nagios ***** Notification Type: PROBLEM Service: Memory RAM+SWAP Host: Serwer1 Address: 192.168.0.1 State: CRITICAL Date/Time: Sat May 6 17:01:43 CEST 2006 Additional Info: (Return code of 13 is out of bounds) other info: # LC_ALL=C LANG=C /usr/lib/nagios/plugins/check_snmp_mem.pl -H 127.0.0.1 -C xkancelax642 -2 -N -w 80,20 -c 90,30 Ram : 23%, Swap : 0% : ; OK in /etc/nagios/services_serwer.cfg define service{ use comp_serwer service_description Memory RAM+SWAP check_command check_snmp_lin_mem!public!80,20! 90,30 } in /etc/nagios/checkcommands.cfg : # Check Linux memoryRAM,SWAP -w ram,swap -c ram,swap define command { command_name check_snmp_lin_mem command_line LC_ALL=C LANG=C $USER1$/check_snmp_mem.pl -f -H $HOSTADDRESS$ -C $ARG1$ -2 -w $ARG2$ -c $ARG3$ } From noreply at sourceforge.net Thu May 11 11:21:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 11 11:21:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Thu May 11 14:54:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 11 14:54:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Thu May 11 22:22:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 11 22:22:17 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484825 ] check_dhcp fails to link on Solaris 2.6 Message-ID: Bugs item #1484825, was opened at 2006-05-09 12:35 Message generated for change (Comment added) made by bubbafat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&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 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp fails to link on Solaris 2.6 Initial Comment: /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a -liconv -lgen -lnsl gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/tmp/nagios-plugins-1.4.3/plugins-root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lresolv ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lnsl -R/usr/local/lib -R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 ===== Modifying the Makefile EXTRA_NETOBJS = getaddrinfo.o gethostbyname.o to EXTRA_NETOBJS = ../plugins/getaddrinfo.o ../plugins/gethostbyname.o fixes it ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 01:19 Message: Logged In: YES user_id=1495257 Same thing occurs on Solaris 7 using gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release): source='check_dhcp.c' object='check_dhcp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -c check_dhcp.c /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a - lgen -lnsl -lssl -lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket - lresolv ../intl/libintl.a -lgen -lnsl -lssl -lcrypto - R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 However on Solaris 8 using gcc version 3.3.2 this problem does not occurr: if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -MT check_dhcp.o -MD -MP -MF ".deps/check_dhcp.Tpo" -c - o check_dhcp.o check_dhcp.c; \ then mv -f ".deps/check_dhcp.Tpo" ".deps/check_dhcp.Po"; else rm -f ".deps/check_dhcp.Tpo"; exit 1; fi /bin/bash ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket - lresolv ../intl/libintl.a -liconv -lgen -lsocket -lssl - lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o - L/home/gtri/nagios/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl - lresolv ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 From noreply at sourceforge.net Thu May 11 22:28:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 11 22:28:21 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 12:31 Message generated for change (Comment added) made by bubbafat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&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 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 01:25 Message: Logged In: YES user_id=1495257 Same thing happens on Solaris 7 with gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release). source='check_smtp.c' object='check_smtp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/local/include -I/usr/local/include -Wall -g -O2 -c check_smtp.c check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3' make: *** [all] Error 2 A lame fix is: --- nagios-plugins-1.4.3/plugins/check_smtp.c Wed Nov 2 03:47:26 2005 +++ nagios-plugins-1.4.3m/plugins/check_smtp.c Mon Apr 24 22:52:01 2006 @@ -26,6 +26,7 @@ #include "common.h" #include "netutils.h" #include "utils.h" +#include #ifdef HAVE_SSL int check_cert = FALSE; However, on Solaris 8 with gcc version 3.3.2, this is not needed. netdb.h gets included somehow. Haven't been able to trace it down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From noreply at sourceforge.net Thu May 11 22:46:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 11 22:46:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1476451 ] pst3 does not exist Message-ID: Bugs item #1476451, was opened at 2006-04-25 18:54 Message generated for change (Comment added) made by bubbafat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476451&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: Fixed Priority: 5 Submitted By: Jason Kau (bubbafat) Assigned to: Ton Voon (tonvoon) Summary: pst3 does not exist Initial Comment: On Solaris, check_procs on nagios-plugins-1.4.3 is trying to use pst3 instead of a 'ps'. There is no pst3.c in the 1.4.3, 1.4.2, 1.4.2 tarballs and it's not in HEAD-200604251152 either but it's in CVS. What is the deal with this file? darlene:/home/gtri/nagios/nagios-plugins-1.4.2> grep PS_COMMAND config.h #define PS_COMMAND "/usr/bin/ps -Ao 's uid pid ppid vsz rss pcpu comm args'" darlene:/home/gtri/nagios/nagios-plugins-1.4.3> grep PS_COMMAND config.h #define PS_COMMAND "/usr/local/nagios/libexec/pst3" ---------------------------------------------------------------------- >Comment By: Jason Kau (bubbafat) Date: 2006-05-12 01:42 Message: Logged In: YES user_id=1495257 Note quite: gcc -g -O2 -o pst3 pst3.o -L/home/gtri/nagios/nagios plugins-HEAD-200605081152/plugins- root ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib Undefined first referenced symbol in file kvm_getproc pst3.o kvm_getu pst3.o kvm_close pst3.o kvm_getcmd pst3.o kvm_open pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status make[2]: *** [pst3] Error 1 make[2]: Leaving directory `/home/gtri/nagios/nagios- plugins-HEAD-200605081152/plugins-root' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gtri/nagios/nagios- plugins-HEAD-200605081152' make: *** [all] Error 2 It would appear that a -lkvm is missing. I added it to the LIBS= line in the Makefile and viola: /bin/bash ../libtool --mode=link gcc -g -O2 -L. - R/usr/local/lib -o pst3 pst3.o ../intl/libintl.a -liconv - lgen -lsocket -lssl -lcrypto -lkvm gcc -g -O2 -o pst3 pst3.o -L/home/gtri/nagios/nagios- plugins-HEAD-200605081152/plugins- root ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto -lkvm - R/usr/local/lib -R/usr/local/lib darlene:/home/gtri/nagios/nagios-plugins-HEAD- 200605081152/plugins-root> ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-04-28 04:46 Message: Logged In: YES user_id=664364 Jason, Thanks for the report. Just applied a fix to CVS. Please try the snapshot and let us know: http://nagiosplug.sf.net/snapshot. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476451&group_id=29880 From noreply at sourceforge.net Fri May 12 10:39:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 12 10:39:53 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487560 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487560, was opened at 2006-05-12 12: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=1487560&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: Open Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487560&group_id=29880 From noreply at sourceforge.net Fri May 12 11:08:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 12 11:08:45 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487578 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487578, was opened at 2006-05-12 12:55 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=1487578&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: Open Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487578&group_id=29880 From mwilson at uindy.edu Fri May 12 12:02:35 2006 From: mwilson at uindy.edu (Matthew Wilson) Date: Fri May 12 12:02:35 2006 Subject: [Nagiosplug-devel] check_dhcp / rogue dhcp server detection In-Reply-To: <3052.134.244.169.17.1147295156.squirrel@webmail.stinkweasel.net> References: <4462352C.4050708@uindy.edu> <20060510194736.GA17089@seanius.net> <3052.134.244.169.17.1147295156.squirrel@webmail.stinkweasel.net> Message-ID: <4464D77A.5040307@uindy.edu> After thinking it through, I think a better implementation would be a list of "authorized servers" (-a maybe) be passed -- this could be used in addition/conjunction to the -s parameter... Here's how I imagine it working with -s: ./check_dhcp -s 192.168.0.1 -s 192.168.0.2 Both servers MUST respond Others MAY also respond ./check_dhcp -a 192.168.0.1 -a 192.168.0.2 Either or both MAY respond Others MAY NOT respond ./check_dhcp -s 192.168.0.1 -s 192.168.0.2 -a 192.168.0.1 -a 192.168.0.2 Both servers MUST respond Others MAY NOT respond ./check_dhcp -s 192.168.0.1 -a 192.168.0.1 -a 192.168.0.2 192.168.0.1 MUST respond 192.168.0.2 MAY respond Others MAY NOT respond ./check_dhcp -s 192.168.0.1 -s 192.168.0.2 -a 192.168.0.1 Invalid use of -s and -a. This would fail every time. Perhaps this could produce an "Unknown" error. At the University of Indianapolis at least 4 times per year, we'll have a student plug in a linksys router backwards and put an unauthorized dhcp server on our network. This handy addition would minimize the effects... Thanks! Matthew C. Bensend wrote: >>>Has anyone given any thought to adding a flag to check_dhcp, so that >>>when IPs are returned, the specified servers are the ONLY servers that >>>can respond. Currently, check_dhcp makes sure that each server in the >>>list responds, but what if there's an additional dhcp server that >>>responds? This might be an effective way to actively monitor for rogue >>>dhcp servers on your network. >>> >>> >>that's a pretty cool idea. i don't imagine it would be too hard to >>implement. if you threw together a rough proof of concept i'd be >>happy to take a look if no one else gets to it first. >> >>i'll be in mexico at debconf next week, send me a ping after that >>if no one else has picked this up. >> >> > >This is exactly the thing I proposed late last year, after a rogue >DHCP server was accidentally started on our LAN. I bantered back >and forth with several members of the list (I remember Andreas >for sure), but it was beyond my meager (nay, pathetic!) programming >skills. > >Benny > > > > From noreply at sourceforge.net Fri May 12 12:25:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 12 12:25:15 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487609 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487609, was opened at 2006-05-12 14:11 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=1487609&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: Open Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487609&group_id=29880 From noreply at sourceforge.net Sat May 13 05:31:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat May 13 05:31:19 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487578 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487578, was opened at 2006-05-12 12:55 Message generated for change (Settings changed) made by wfjarrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487578&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: Deleted Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487578&group_id=29880 From cmr at financial.com Sun May 14 06:48:03 2006 From: cmr at financial.com (Christoph Maser) Date: Sun May 14 06:48:03 2006 Subject: [Nagiosplug-devel] devolper guidelines Message-ID: <4467332A.1070807@financial.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, there is a point in the developer-guidelines wich i think is a bit problematic. It says: "The -? option, or any other unparsable set of options, should print out a short usage statement. Character width should be 80 and less and no more that 23 lines should be printed (it should display cleanly on a dumb terminal in a server room)." The problem i see with this is that if you missconfigure the plugin inside nagios you might get something like non-ok exitcode with no ouput at all (lead to the famous "No output returned from plugin". Since the output can be multiline and the 1st line can be empty. An example where this happens is check_nrp called with wrong flags. It reutrns a decent error-message on STDERR but usage with an empty 1st line on STDOUT. I've seen this leading to long sessions of debugging. I would propose to rephrase that part to sth like the following: "The -? option should print out a short usage statement on STDOUT. Character width should be 80 and less and no more that 23 lines should be printed (it should display cleanly on a dumb terminal in a server room). Any unparsable or unusable set of options should return exitcode 3 (unknown) and _one line_ on STDOUT indicating the plugin was called with and unparsable or unusable set of options, and the usage statement on STDERR." Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEZzMpsLjW0HYht7URAtpxAJ9WY/EAvZ9XwZgWQaksrbwLOkTzgACfQJTR xnE/qk01GM4OJ5TtVNOKMN8= =nhuE -----END PGP SIGNATURE----- From sghosh at sghosh.org Sun May 14 18:31:53 2006 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sun May 14 18:31:53 2006 Subject: [Nagiosplug-devel] RPM/Debian packaging Message-ID: Hi all I am looking at the issues packagers are having with the plugins distribution. I would like to see what we can do to resolve them. Can package maintainers provide some comments and feedback on the direction we should be heading? I am open to generating multiple binary RPMs from the single src.rpm -- -regards -sg From ton.voon at altinity.com Mon May 15 06:33:38 2006 From: ton.voon at altinity.com (Ton Voon) Date: Mon May 15 06:33:38 2006 Subject: [Nagiosplug-devel] devolper guidelines In-Reply-To: <4467332A.1070807@financial.com> References: <4467332A.1070807@financial.com> Message-ID: <24A6C430-44CD-44FE-A08F-ED60ADE98784@altinity.com> On 14 May 2006, at 14:39, Christoph Maser wrote: > > Hi, > > there is a point in the developer-guidelines wich i think is a bit > problematic. > > It says: > "The -? option, or any other unparsable set of options, should > print out a short usage > statement. Character width should be 80 and less and no more that > 23 lines should be > printed (it should display cleanly on a dumb terminal in a server > room)." > > The problem i see with this is that if you missconfigure the plugin > inside nagios you > might get something like non-ok exitcode with no ouput at all (lead > to the famous "No > output returned from plugin". Since the output can be multiline and > the 1st line can be empty. > > An example where this happens is check_nrp called with wrong flags. > It reutrns a decent > error-message on STDERR but usage with an empty 1st line on STDOUT. > I've seen this leading > to long sessions of debugging. > > I would propose to rephrase that part to sth like the following: > > "The -? option should print out a short usage statement on STDOUT. > Character width should > be 80 and less and no more that 23 lines should be printed (it > should display cleanly on a > dumb terminal in a server room). > Any unparsable or unusable set of options should return exitcode 3 > (unknown) and _one > line_ on STDOUT indicating the plugin was called with and > unparsable or unusable set of > options, and the usage statement on STDERR." I think it is fair that this is open to review again. Better error messages that get propagated back to Nagios is a good aim. Your suggestion makes sense as a -? (intentional) is quite different from an unintentional bad option. My only change would be that the 1st line on STDOUT be a "bad option specified" message, with the rest of STDOUT being the (optional) usage statement. I don't see a need to separate STDOUT and STDERR output. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Mon May 15 06:39:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon May 15 06:39:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1373819 ] check_disk_snmp.pl support for SNMP v1/2 and Windows Message-ID: Patches item #1373819, was opened at 2005-12-05 20:18 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1373819&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Alex Burger (alex_b) >Assigned to: Ton Voon (tonvoon) Summary: check_disk_snmp.pl support for SNMP v1/2 and Windows Initial Comment: The attached patch is for check_disk_snmp.pl from nagios-plugins-1.4. The patch adds: -Support for SNMP version 1 and 2 -Support for checking free bytes instead of only usage ratio -Support for selecting a device by specifying a substring of the device description such as c:, d: etc. -Support for hostname:port This version can be used to check disk space on both Unix and Windows hosts. The command line is compatible with the old version (defaults to usage). Examples from the updated help page: SNMP V3 example using ratio for device number 2: ./check_disk_snmp.pl -u nobody -l authPriv -a MD5 -A nopass -x DES -m server1 -d 2 -w 70 -c 85 SNMP V1 example using ratio for device number 2: ./check_disk_snmp.pl -v 1 -u public -m server1 -d 2 -w 70 -c 85 SNMP V1 example using bytes for device number 2 ./check_disk_snmp.pl -v 1 -u public -m server1 -d 2 -w 10Gb -c 900Mb -t bytes SNMP V1 example using bytes free for device description that contains 'c:' ./check_disk_snmp.pl -v 1 -u public -m server1 -d 'c:' -w 10Gb -c 900Mb -t bytes ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-15 14:23 Message: Logged In: YES user_id=664364 Alex, Thanks for raising this. However, this plugin is being maintained outside of this project. Please find the current author and maintainer at http:// nagiosexchange.org Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1373819&group_id=29880 From cmr at financial.com Tue May 16 05:53:29 2006 From: cmr at financial.com (Christoph Maser) Date: Tue May 16 05:53:29 2006 Subject: [Nagiosplug-devel] devolper guidelines In-Reply-To: <24A6C430-44CD-44FE-A08F-ED60ADE98784@altinity.com> References: <4467332A.1070807@financial.com> <24A6C430-44CD-44FE-A08F-ED60ADE98784@altinity.com> Message-ID: <4469CA8A.4080203@financial.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Better error messages that get propagated back to Nagios is a good aim. > Your suggestion makes sense as a -? (intentional) is quite different > from an unintentional bad option. My only change would be that the 1st > line on STDOUT be a "bad option specified" message, with the rest of > STDOUT being the (optional) usage statement. I don't see a need to > separate STDOUT and STDERR output. > I do. Once Nagios will support multiline-output. If you decide to print usage on usage errors it will clutter the frontend (wichever that will be) with information it was not asked for and makes it harder to see this one single important line. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEacqKsLjW0HYht7URApdXAKCsZ9cxK0pesnvQ02gkAsUNCMMGUACfXcRv IhBR8D9LMZeMBDPcBqphI1o= =e8LM -----END PGP SIGNATURE----- From baron at bundesbrandschatzamt.de Tue May 16 06:15:56 2006 From: baron at bundesbrandschatzamt.de (Andreas Gerler) Date: Tue May 16 06:15:56 2006 Subject: [Nagiosplug-devel] check_mysql bug slavecheck Message-ID: Hi, first of all thanks a lot for this great toolset. Ive tried to use check_mysql for slavecheck. Im running it via nrpe on the mysql-slave with: command[check_mysql_slave]=/usr/local/nagios/libexec/check_mysql -H 127.0.0.1 -u root -S But even though master/slave is running fine I get an error_code of 2 and output is: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) Any suggestions? Thanks... Baron http://www.bundesbrandschatzamt.de/~baron mailto:baron at bundesbrandschatzamt.de From noreply at sourceforge.net Tue May 16 08:08:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 16 08:08:09 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1150826 ] Performance data added to check_mysql Message-ID: Patches item #1150826, was opened at 2005-02-24 08:11 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1150826&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: Perf data Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Clewett (benclewett) >Assigned to: Ton Voon (tonvoon) Summary: Performance data added to check_mysql Initial Comment: Performance data added to check_mysql by inteperating data returned by MySQL. If this format remains the same, should always work. Tested MySQL v 4.0.11 -> 4.1.9 Ben. -- bclewett at perfparse.org ---------------------------------------------------------------------- Comment By: Ben Clewett (benclewett) Date: 2005-02-28 15:16 Message: Logged In: YES user_id=157178 Thanks for finding the patch, I know a lot of users will be interested in this. Regards, Ben ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2005-02-28 15:11 Message: Logged In: YES user_id=983566 Yeah I took it from your email. Will look at applying this week when I have some time. ---------------------------------------------------------------------- Comment By: Ben Clewett (benclewett) Date: 2005-02-28 08:30 Message: Logged In: YES user_id=157178 Did I forget? I can see it attached. Or did you copy this fromn my email? So is this ok now? ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2005-02-25 19:39 Message: Logged In: YES user_id=983566 Another tiny patch for replication data to apply ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2005-02-25 19:38 Message: Logged In: YES user_id=983566 Think you forgot the file :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1150826&group_id=29880 From seanius at seanius.net Tue May 16 08:23:04 2006 From: seanius at seanius.net (sean finney) Date: Tue May 16 08:23:04 2006 Subject: [Nagiosplug-devel] RPM/Debian packaging In-Reply-To: References: Message-ID: <20060516152221.GA1499@seanius.net> hi subhendu, On Sun, May 14, 2006 at 10:23:14PM -0400, Subhendu Ghosh wrote: > I would like to see what we can do to resolve them. Can package > maintainers provide some comments and feedback on the direction we should > be heading? i think one of the larger issues i've had packaging the plugins in debian is the compile-time dependencies for creating all of the plugins. for exmaple, needing to have ntpdate/ntpq installed at compile time to generate check_ntp[1]. another issue is hard-coding certain things at compile time compile time, like the ping syntax etc. the final issue is more of a logistical one that is left for us (the packagers) to decide ourselves: binary package dependencies. in debian <= sarge, we had a single binary "nagios-plugins" package which had all the plugins and a quite impressive dependency list as a result. since then, we've been splitting things up a bit, so now there's a "nagios-plugins-basic", "-standard", and "-extra" (or something like that, i forget at the moment). the first is a set of plugins with minimal and/or no external dependencies, the second is the set of plugins in which one would mostly likely want on a default installation, and the final package is all the odds and ends that perhaps only certain people would be interested in. another route would be to generate a single-package per plugin, but within the debian team we decided that was overkill and polluted the package namespace too much. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Tue May 16 09:10:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 16 09:10:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1489664 ] check_log bugfix for logrotation Message-ID: Patches item #1489664, was opened at 2006-05-16 16:09 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=1489664&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 Submitted By: Philipp (philipp80) Assigned to: Nobody/Anonymous (nobody) Summary: check_log bugfix for logrotation Initial Comment: When a logfile gets truncated (i.e., via logrotate), check_log finds the already reported matches in the tempfile and reports them again. This patch fixes this bug by grepping only in the real logfile, not in the tempfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1489664&group_id=29880 From mtiernan at draper.com Tue May 16 21:54:05 2006 From: mtiernan at draper.com (Tiernan, Michael C.) Date: Tue May 16 21:54:05 2006 Subject: [Nagiosplug-devel] Bug report: check_ldap Revision: 1.30 Message-ID: I don't know if anyone's reported it already but if not, consider it done. If so, please accept my apologies. check_ldap V1.3 is not coded to support the "-v"|"--verbose" flag. From noreply at sourceforge.net Thu May 18 01:00:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 01:00:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-938212 ] check_sensors w/ performance data Message-ID: New Plugins item #938212, was opened at 2004-04-19 23:09 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938212&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Matthew Kent (mattkent) Assigned to: Matthew Kent (mattkent) Summary: check_sensors w/ performance data Initial Comment: This is a plugin for contribs to lm_sensors output and return performance data. The purpose of this plugin is to provide an alternative to the current contrib plugin which relies on the ALARM field in the sensors output for problem notification. After reading the chip documentation for our particular boards, the way ALARM is set by the driver wouldn't have been reliable enough to use in production. I also wanted performance data for post processing and a check that could run through nrpe so I wouldn't have to edit sensors.conf on every server for a threshold change. As I'm working on an addon package for nagios 2.0 which will use this check (and my other mysqld submission), I would appreciate it being considered for addition. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:59 Message: Logged In: YES user_id=664364 Closed for Matthew to review offline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938212&group_id=29880 From noreply at sourceforge.net Thu May 18 01:00:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 01:00:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-938208 ] check_mysqld w/ performance data Message-ID: New Plugins item #938208, was opened at 2004-04-19 23:03 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938208&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perl plugin Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Matthew Kent (mattkent) Assigned to: Matthew Kent (mattkent) Summary: check_mysqld w/ performance data Initial Comment: This is a plugin for contribs to check a mysql server and return performance data. The idea being that you could run the stock check_mysql.c plugin from the clients to check connectivity to their corresponding mysql server. Then run this plugin from the nagios server to check the database servers themselves and return data for performance data post processing. As I'm working on an addon package for nagios 2.0 which will use this check (and my other lm_sensors submission), I would appreciate it being considered for addition. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:59 Message: Logged In: YES user_id=664364 Closed for Matthew to review offline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938208&group_id=29880 From noreply at sourceforge.net Thu May 18 02:08:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 02:08:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1490762 ] check_disk / not found on Solaris Message-ID: Bugs item #1490762, was opened at 2006-05-18 09:07 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=1490762&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: Open Resolution: None Priority: 5 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk / not found on Solaris Initial Comment: Solaris 2.6, 8 and 9, seen on more than one server $ ./check_disk -e -w 10% -c 5% -p /opt/oracle -p /opt -p / DISK CRITICAL - free space: [/ not found]| /=781MB;846;893;91;940 /opt=427MB;846;893;99;940 /opt/oracle=1165MB;3630;3832;94;4034 Change the order of the partitions $ ./check_disk -e -w 10% -c 5% -p / -p /opt/oracle -p /opt DISK OK - free space:| /=781MB;846;893;91;940 /opt=427MB;846;893;99;940 /opt/oracle=1165MB;3630;3832;94;4034 This is the minimum case - other partitions can be defined (and reported upon correctly) and only / reports an error. Seems to be due to mount point being under a root directory, i.e. /opt /opt/app /opt /opt/oracle both "lose" / when its the last parameter checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1490762&group_id=29880 From noreply at sourceforge.net Thu May 18 02:29:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 02:29:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 Message generated for change (Comment added) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Tobias Mucke (mucke) Date: 2006-05-18 11:28 Message: Logged In: YES user_id=481892 Hi everybody, checked out newest snapshot 20060517 but same problem. Tobias ---------------------------------------------------------------------- Comment By: Ralph R????ner (ralph_roessner) Date: 2006-05-08 20:08 Message: Logged In: YES user_id=1515003 Hi everybody! I have a similar problem on Solaris, only I get bitten by validate_arguments(), which complains that "C_IDFP (67065044...467904.000000) should be less than W_IDFP (0.0)". It appears that the minimum free inode percentage was not correctly initialized. This only appears when file systems are selected with "-p". The reason I suspect is that the c_idfp and w_idfp members of the path list structure are never initialized in this case, at least not at the point where c_dfp and w_dfp are (check_disk.c lines 457ff). So random malloc()ed memory is passed to validate_arguments(), and the results vary according to architecture and phase of the moon. I created a patch that treats the [cw]_idfp like [cw]_dfp at the point where the "-p" argument is parsed. This makes the problem go away for me. If there are other places where the path list is added to then there is a good chance that the same oversight happened there too. Since I don't find a way to attach a file to a thread I did not open, I will include the patch here: --8><----------------------------------- *** nagios-plugins-1.4.3/plugins/check_disk.c.orig Mon May 8 19:50:33 2006 --- nagios-plugins-1.4.3/plugins/check_disk.c Mon May 8 19:49:48 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; --8><----------------------------------- Hope this helps, Ralph R????ner ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-05 16:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 10:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Thu May 18 02:34:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 02:34:00 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481019 ] Parsing problem within check_ntp Message-ID: Bugs item #1481019, was opened at 2006-05-03 13:35 Message generated for change (Comment added) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481019&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: Open Resolution: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Nobody/Anonymous (nobody) Summary: Parsing problem within check_ntp Initial Comment: Hallo everybody, I have a little problem with check_ntp. I can work around it by redirecting Stderrout to /dev/null but since this problem exists also in the newest Plugin release 1.4.3 I want to submit this request. Here is what I get when calling check_ntp. Lines are numbered by me! Line 1: Argument "(not parsed)" isn't numeric in abs at /opt/nagios/plugins/check_ntp line 408. Line 2: NTP OK: Offset 0.003125 secs, jitter (not parsed) msec, peer is stratum 1|offset=0.003125, jitter=0,peer_stratum=1 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Tobias Mucke (mucke) Date: 2006-05-18 11:33 Message: Logged In: YES user_id=481892 Hi everybody, tried out newest snapshot release 20060517. Bug seems to be fixed. Closing this request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481019&group_id=29880 From noreply at sourceforge.net Thu May 18 03:06:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 03:06:20 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481019 ] Parsing problem within check_ntp Message-ID: Bugs item #1481019, was opened at 2006-05-03 13:35 Message generated for change (Settings changed) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481019&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: None Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Nobody/Anonymous (nobody) Summary: Parsing problem within check_ntp Initial Comment: Hallo everybody, I have a little problem with check_ntp. I can work around it by redirecting Stderrout to /dev/null but since this problem exists also in the newest Plugin release 1.4.3 I want to submit this request. Here is what I get when calling check_ntp. Lines are numbered by me! Line 1: Argument "(not parsed)" isn't numeric in abs at /opt/nagios/plugins/check_ntp line 408. Line 2: NTP OK: Offset 0.003125 secs, jitter (not parsed) msec, peer is stratum 1|offset=0.003125, jitter=0,peer_stratum=1 Thanks in advance. Tobias ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-18 11:33 Message: Logged In: YES user_id=481892 Hi everybody, tried out newest snapshot release 20060517. Bug seems to be fixed. Closing this request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481019&group_id=29880 From Gerhard.Lausser at consol.de Thu May 18 05:37:07 2006 From: Gerhard.Lausser at consol.de (Gerhard Lausser) Date: Thu May 18 05:37:07 2006 Subject: [Nagiosplug-devel] what checks check_ntp? Message-ID: <026901c67a77$ae715e40$a601000a@int.consol.de> Hi, i am a bit confused on what check_ntp actually checks. You give it a timeserver with the -H parameter and it determines the offset between local time and the timeserver's time with the ntpdate command. That's ok so far. In a second step ntpq -np is called which gives you the timeserver's daemon and peer status. The jitter we see here comes from the communication between the timeserver and it's peers. Is this really relevant for the time quality of our local host? Wouldn't calling ntpq -np 127.0.0.1 give us the jitter information we're really interested in? In my opinion it would be better to first call ntpq -np 127.0.0.1 which returns information for both offset and jitter (for the current sys.peer or candidates, not for the statically configured timeserver) and if that doesn't work, use ntpdate -q as a fallback. Greetings from Munich, Gerhard From noreply at sourceforge.net Thu May 18 05:40:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 05:40:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 18:52 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) >Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 13:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 22:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 19:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Thu May 18 05:40:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 05:40:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1485683 ] check_disk addition to exclude all mountpoints within a path Message-ID: Feature Requests item #1485683, was opened at 2006-05-10 16:19 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1485683&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: maemigh (maemigh) >Assigned to: Ton Voon (tonvoon) Summary: check_disk addition to exclude all mountpoints within a path Initial Comment: check_disk currently allows mount points to be excluded via the -x /mount/point command; however, this is causing some issues with Solaris and its cdrom. It would be nice to have the -x command updated to allow a wildcard to be used to exclude all mountpoints within a path. ie -x /cdrom/* I've included some output to illustrate why I believe this to be necessary. Here is a snippet of output from the check_disk command: /cdrom/sol_9_905_sparc/s2=0MB;0;0;0;0 /cdrom/sol_9_905_sparc/s1=494MB;444;469;0;494 /cdrom/sol_9_905_sparc/s0=2349MB;2114;2231;0;2349 df -h: /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s5 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s5 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s4 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s4 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s3 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s3 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s2 31K 2K 26K 8% /cdrom/sol_9_905_sparc/s2 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s1 495M 468M 0K 100% /cdrom/sol_9_905_sparc/s1 /vol/dev/dsk/c0t0d0/sol_9_905_sparc/s0 2.3G 2.3G 0K 100% /cdrom/sol_9_905_sparc/s0 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 13:39 Message: Logged In: YES user_id=664364 maemigh, Couldn't you use -X cdfs? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1485683&group_id=29880 From noreply at sourceforge.net Thu May 18 06:26:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 06:26:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1476451 ] pst3 does not exist Message-ID: Bugs item #1476451, was opened at 2006-04-25 23:54 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476451&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending Resolution: Fixed Priority: 5 Submitted By: Jason Kau (bubbafat) Assigned to: Ton Voon (tonvoon) Summary: pst3 does not exist Initial Comment: On Solaris, check_procs on nagios-plugins-1.4.3 is trying to use pst3 instead of a 'ps'. There is no pst3.c in the 1.4.3, 1.4.2, 1.4.2 tarballs and it's not in HEAD-200604251152 either but it's in CVS. What is the deal with this file? darlene:/home/gtri/nagios/nagios-plugins-1.4.2> grep PS_COMMAND config.h #define PS_COMMAND "/usr/bin/ps -Ao 's uid pid ppid vsz rss pcpu comm args'" darlene:/home/gtri/nagios/nagios-plugins-1.4.3> grep PS_COMMAND config.h #define PS_COMMAND "/usr/local/nagios/libexec/pst3" ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 14:25 Message: Logged In: YES user_id=664364 Hi Jason, -lkvm has been added to the Makefiles. Please try the snapshot again. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 06:42 Message: Logged In: YES user_id=1495257 Note quite: gcc -g -O2 -o pst3 pst3.o -L/home/gtri/nagios/nagios plugins-HEAD-200605081152/plugins- root ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib Undefined first referenced symbol in file kvm_getproc pst3.o kvm_getu pst3.o kvm_close pst3.o kvm_getcmd pst3.o kvm_open pst3.o ld: fatal: Symbol referencing errors. No output written to pst3 collect2: ld returned 1 exit status make[2]: *** [pst3] Error 1 make[2]: Leaving directory `/home/gtri/nagios/nagios- plugins-HEAD-200605081152/plugins-root' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gtri/nagios/nagios- plugins-HEAD-200605081152' make: *** [all] Error 2 It would appear that a -lkvm is missing. I added it to the LIBS= line in the Makefile and viola: /bin/bash ../libtool --mode=link gcc -g -O2 -L. - R/usr/local/lib -o pst3 pst3.o ../intl/libintl.a -liconv - lgen -lsocket -lssl -lcrypto -lkvm gcc -g -O2 -o pst3 pst3.o -L/home/gtri/nagios/nagios- plugins-HEAD-200605081152/plugins- root ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto -lkvm - R/usr/local/lib -R/usr/local/lib darlene:/home/gtri/nagios/nagios-plugins-HEAD- 200605081152/plugins-root> ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-04-28 09:46 Message: Logged In: YES user_id=664364 Jason, Thanks for the report. Just applied a fix to CVS. Please try the snapshot and let us know: http://nagiosplug.sf.net/snapshot. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1476451&group_id=29880 From ton.voon at altinity.com Thu May 18 06:33:10 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu May 18 06:33:10 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints Message-ID: Hi! Wanted an opinion on check_disk. maemigh raised a tracker where check_disk was unexpectedly excluding the root filesystem: http:// sourceforge.net/tracker/index.php? func=detail&aid=1485816&group_id=29880&atid=397597 It seems to me that the problem is in the walk_name_list function, where it is trying to be clever about which filesystems actually needs to be checked. This is to support "check_disk -p /etc" so that this returns data for /. Given that check_disk is a sysadmin tool and not a user tool, I think "check_disk -p /non/existent/filesystem" should only match exact filesystem names. However, this may break current usage of check_disk. Any opinions? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Thu May 18 06:55:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 06:55:08 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487609 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487609, was opened at 2006-05-12 20:11 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487609&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: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) >Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 14:54 Message: Logged In: YES user_id=664364 Closing as this is a duplicate of 1487560 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487609&group_id=29880 From noreply at sourceforge.net Thu May 18 06:57:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 06:57:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487560 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487560, was opened at 2006-05-12 18:22 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487560&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: Open Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) >Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-18 14:55 Message: Logged In: YES user_id=664364 Bill, Which version of the plugins are you using? df output hasn't been used since 1.4 was released. Please try the snapshot at http://nagiosplug.sf.net/snapshot. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487560&group_id=29880 From noreply at sourceforge.net Thu May 18 08:40:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 18 08:40:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-18 11:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From rouilj at cs.umb.edu Thu May 18 08:43:02 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Thu May 18 08:43:02 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: Your message of "Thu, 18 May 2006 14:32:07 BST." Message-ID: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> In message , Ton Voon writes: >Wanted an opinion on check_disk. maemigh raised a tracker where >check_disk was unexpectedly excluding the root filesystem: http:// >sourceforge.net/tracker/index.php? >func=detail&aid=1485816&group_id=29880&atid=397597 > >It seems to me that the problem is in the walk_name_list function, >where it is trying to be clever about which filesystems actually >needs to be checked. This is to support "check_disk -p /etc" so that >this returns data for /. I claim this is wrong. I also think it worked differently in 1.4.2. I have it checking for a mount point /backup where our backups are done to a disk. We have a couple of USB disks we swap around for use, so the device name may not be constant, but the mount point is. check_disk /backup returned ok even though the disk wasn't mounted. Needless to say backups kind of died. I am almost positive that errored with the 1.4.2 plugins because we had a couple of reboot's where the test failed because the disk didn't mount. >Given that check_disk is a sysadmin tool and not a user tool, I think >"check_disk -p /non/existent/filesystem" should only match exact >filesystem names. However, this may break current usage of check_disk. I claim the breakage was in 1.4.3. Two ways to handle it: 1) Make the default force the directories to be mount points and exit critical if they aren't. Add a flag to allow the current behavior. (My preferred option) 2) Make the current operation the default and add a flag that forces the specified directory to me a mount point and exit critical if it isn't. Having been bit by this (I was going to post it once I figured out if it really was a regression from 1.42) I would like to see it fixed. Right now I have to use the device name and will have to change the test when we swap disks. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From seanius at seanius.net Thu May 18 09:04:02 2006 From: seanius at seanius.net (sean finney) Date: Thu May 18 09:04:02 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> References: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> Message-ID: <20060518160303.GA7245@seanius.net> hi ton, john, On Thu, May 18, 2006 at 11:42:16AM -0400, John P. Rouillard wrote: > >It seems to me that the problem is in the walk_name_list function, > >where it is trying to be clever about which filesystems actually > >needs to be checked. This is to support "check_disk -p /etc" so that > >this returns data for /. > > I claim this is wrong. I also think it worked differently in 1.4.2. I > have it checking for a mount point /backup where our backups are done > to a disk. We have a couple of USB disks we swap around for use, so the > device name may not be constant, but the mount point is. iirc, the original functionality was to walk up to a mountpoint. i think this memory is strongly backed by the fact that check_disk used to solely rely on df, which also has this behaviour. i think what happened was at some point (1.4.2 maybe?), this behaviour disappeared. i recieved a couple bugs about it in the debian BTS, so i added a patch that the restores the functionality, if my memory servers me correctly. > 1) Make the default force the directories to be mount points and > exit critical if they aren't. Add a flag to allow the current > behavior. (My preferred option) > > 2) Make the current operation the default and add a flag that forces > the specified directory to me a mount point and exit critical if it > isn't. i think either of these would be a good solution to the problem. i'm more partial to (2) because it's more in line with how i remember check_disk historically working. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From reed at reedmedia.net Thu May 18 13:16:02 2006 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu May 18 13:16:02 2006 Subject: [Nagiosplug-devel] configure broken with old mysql Message-ID: With nagios-plugins-1.4.3, using configure with: --with-mysql=/usr/local/mysql \ --with-mysql-lib=/usr/local/mysql/lib \ --with-mysql-inc=/usr/local/mysql/include configure errors with: config.status: creating intl/Makefile sed: file ./confstatzL3272/subs-3.sed line 35: Unterminated `s' command config.status: creating po/Makefile.in sed: file ./confstatzL3272/subs-3.sed line 35: Unterminated `s' command .... But configure does not fail. An empty Makefile is generated. Line 35 of the sed script is: s, at MYSQLINCLUDE@,Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I'/usr/local/mysql/include/mysql'] --libs [-L'/usr/local/mysql/lib/mysql' -lmysqlclient -lz -lcrypt -lnsl -lm] --socket [/tmp/mysql.sock] --port [3306] --version [3.23.58],;t t My workaround was to comment out the following line in configure: MYSQLINCLUDE=`$MYSQLCONFIG --include` If you like me to report this somewhere else, please let me know. Please carbon-copy me on replies. I am not on this list. Jeremy C. Reed From tonvoon at mac.com Thu May 18 15:11:03 2006 From: tonvoon at mac.com (Ton Voon) Date: Thu May 18 15:11:03 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: <20060518160303.GA7245@seanius.net> References: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> <20060518160303.GA7245@seanius.net> Message-ID: <7126EF02-E249-408F-918D-05135BE639E7@mac.com> On 18 May 2006, at 17:03, sean finney wrote: > i think what happened was at some point (1.4.2 maybe?), this behaviour > disappeared. i recieved a couple bugs about it in the debian BTS, so > i added a patch that the restores the functionality, if my memory > servers me correctly. John has come down on "this behaviour is wrong" with a good example of why, which I am swaying towards. Sean, is there a good counter- example for when this behaviour is desirable? >> 1) Make the default force the directories to be mount points and >> exit critical if they aren't. Add a flag to allow the current >> behavior. (My preferred option) >> >> 2) Make the current operation the default and add a flag that >> forces >> the specified directory to me a mount point and exit critical >> if it >> isn't. > > i think either of these would be a good solution to the problem. i'm > more partial to (2) because it's more in line with how i remember > check_disk historically working. I'm more inclined to go with (1) because of John's failure case, but I'd rather get rid of the walk filesystem altogether :) Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From rouilj at cs.umb.edu Thu May 18 15:20:03 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Thu May 18 15:20:03 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: Your message of "Thu, 18 May 2006 23:09:49 BST." <7126EF02-E249-408F-918D-05135BE639E7@mac.com> Message-ID: <200605182218.k4IMIx7q011729@mx1.cs.umb.edu> In message <7126EF02-E249-408F-918D-05135BE639E7 at mac.com>, Ton Voon writes: >On 18 May 2006, at 17:03, sean finney wrote: > >> i think what happened was at some point (1.4.2 maybe?), this behaviour >> disappeared. i recieved a couple bugs about it in the debian BTS, so >> i added a patch that the restores the functionality, if my memory >> servers me correctly. > >John has come down on "this behaviour is wrong" with a good example >of why, which I am swaying towards. Sean, is there a good counter- >example for when this behaviour is desirable? Since Sean had a couple of bug reports he has a couple of use cases in the opposite direction. I can see it being useful if you have systems that mix directory/mount points. E.G. on some systems /tmp is a mount point and on other's it sits on the root filesystem. Still valid to make sure you have at least 100G free space in either case. I handle that by a masochistic set of hostgroups and set algebra so I have different checks on the two system types. Others may not want to. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From seanius at seanius.net Thu May 18 22:30:01 2006 From: seanius at seanius.net (sean finney) Date: Thu May 18 22:30:01 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: <200605182218.k4IMIx7q011729@mx1.cs.umb.edu> References: <7126EF02-E249-408F-918D-05135BE639E7@mac.com> <200605182218.k4IMIx7q011729@mx1.cs.umb.edu> Message-ID: <20060519052912.GA8699@seanius.net> On Thu, May 18, 2006 at 06:18:59PM -0400, John P. Rouillard wrote: > Since Sean had a couple of bug reports he has a couple of use cases in > the opposite direction. I can see it being useful if you have systems > that mix directory/mount points. E.G. on some systems /tmp is a mount > point and on other's it sits on the root filesystem. Still valid to > make sure you have at least 100G free space in either case. yes, this was the idea. in the case i could find in the BTS, they were monitoring /var/log as you describe. if it is to become non-default behaviour, it's not the end of the world (i can put command definitions for both in the default configs to make all debian users happy), but i'd be against removing it entirely. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ae at op5.se Fri May 19 01:16:05 2006 From: ae at op5.se (Andreas Ericsson) Date: Fri May 19 01:16:05 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: <7126EF02-E249-408F-918D-05135BE639E7@mac.com> References: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> <20060518160303.GA7245@seanius.net> <7126EF02-E249-408F-918D-05135BE639E7@mac.com> Message-ID: <446D7EB5.9000805@op5.se> Ton Voon wrote: > > On 18 May 2006, at 17:03, sean finney wrote: > >> i think what happened was at some point (1.4.2 maybe?), this behaviour >> disappeared. i recieved a couple bugs about it in the debian BTS, so >> i added a patch that the restores the functionality, if my memory >> servers me correctly. > > > John has come down on "this behaviour is wrong" with a good example of > why, which I am swaying towards. Sean, is there a good counter- example > for when this behaviour is desirable? > > >>> 1) Make the default force the directories to be mount points and >>> exit critical if they aren't. Add a flag to allow the current >>> behavior. (My preferred option) >>> >>> 2) Make the current operation the default and add a flag that forces >>> the specified directory to me a mount point and exit critical >>> if it >>> isn't. >> >> >> i think either of these would be a good solution to the problem. i'm >> more partial to (2) because it's more in line with how i remember >> check_disk historically working. > > > I'm more inclined to go with (1) because of John's failure case, but > I'd rather get rid of the walk filesystem altogether :) > I vote 2 as well. There's no sane reason to name a file or directory that's inside a mount-point rather than actually naming the mount-point itself, and mount-points can reside on other mounted filesystems which just begs to break if we find multiple mount-points while walking to it from the root (which is also a mount-point, btw). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From Gerhard.Lausser at consol.de Fri May 19 04:36:06 2006 From: Gerhard.Lausser at consol.de (Gerhard Lausser) Date: Fri May 19 04:36:06 2006 Subject: [Nagiosplug-devel] compile error for check_snmp.c Message-ID: <000101c67b38$404d7180$a601000a@int.consol.de> Hi, for those of you, who see the following error message when compiling the plugins check_snmp.c: In function `main': check_snmp.c:343: parse error before `char' check_snmp.c:344: `str' undeclared (first use in this function) check_snmp.c:344: (Each undeclared identifier is reported only once check_snmp.c:344: for each function it appears in.) i made a small patch, which you can download from http://people.consol.de/~lausser/nagios/patches.html I am not sure, but i think the error occurs when using a gcc < 3.x Greetings from Munich, Gerhard From Thomas at zango.com Fri May 19 07:20:02 2006 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri May 19 07:20:02 2006 Subject: [Nagiosplug-devel] Check_ping with source address Message-ID: Hi, I wrote a patch for check_ping that allow to specify a source address. The idea is to attach a Nagios box on a trunk and ping from different VLANs. This patch works wherever ping accept the -I argument (the ping it was tested against is from iputils). To do this correctly the "ping -I x.x.x.x" behavior should be checked by configure with some code enclosed in ifdef's, and I have no idea how to modify autoconf for that. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.3.ping_source_address.patch Type: application/octet-stream Size: 3187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3022 bytes Desc: not available URL: From Thomas at zango.com Fri May 19 08:26:06 2006 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri May 19 08:26:06 2006 Subject: [Nagiosplug-devel] RE: Check_ping with source address Message-ID: Forgot to free() my variable in the loop, here's an updated version. I however noted a bug where asprintf segfaults if the -s argument is exactly 10 characters long, I don't get what's wrong. Any idea? Thomas > -----Original Message----- > From: Thomas Guyot-Sionnest > Sent: May 19, 2006 10:18 > To: 'nagiosplug-devel at lists.sourceforge.net' > Subject: Check_ping with source address > > Hi, > > I wrote a patch for check_ping that allow to specify a source > address. The > idea is to attach a Nagios box on a trunk and ping from > different VLANs. > > This patch works wherever ping accept the -I argument (the > ping it was tested > against is from iputils). To do this correctly the "ping -I > x.x.x.x" behavior > should be checked by configure with some code enclosed in > ifdef's, and I have > no idea how to modify autoconf for that. > > > Thomas > -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.3.ping_source_address.patch Type: application/octet-stream Size: 3514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3022 bytes Desc: not available URL: From Thomas at zango.com Fri May 19 09:01:06 2006 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri May 19 09:01:06 2006 Subject: [Nagiosplug-devel] RE: Check_ping with source address Message-ID: Well, sorry for spamming... I misread the man page for strlen and used it as if it counted the last \0. This 3rd patch works well, It only need some autoconf mods as I outlined in my first post. Thomas > -----Original Message----- > From: Thomas Guyot-Sionnest > Sent: May 19, 2006 11:25 > To: 'nagiosplug-devel at lists.sourceforge.net' > Subject: RE: Check_ping with source address > > Forgot to free() my variable in the loop, here's an updated version. > > I however noted a bug where asprintf segfaults if the -s > argument is exactly > 10 characters long, I don't get what's wrong. Any idea? > > Thomas > > > -----Original Message----- > > From: Thomas Guyot-Sionnest > > Sent: May 19, 2006 10:18 > > To: 'nagiosplug-devel at lists.sourceforge.net' > > Subject: Check_ping with source address > > > > Hi, > > > > I wrote a patch for check_ping that allow to specify a source > > address. The > > idea is to attach a Nagios box on a trunk and ping from > > different VLANs. > > > > This patch works wherever ping accept the -I argument (the > > ping it was tested > > against is from iputils). To do this correctly the "ping -I > > x.x.x.x" behavior > > should be checked by configure with some code enclosed in > > ifdef's, and I have > > no idea how to modify autoconf for that. > > > > > > Thomas > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: nagios-plugins-1.4.3.ping_source_address.patch Type: application/octet-stream Size: 3494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3022 bytes Desc: not available URL: From noreply at sourceforge.net Fri May 19 17:56:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 19 17:56:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1491936 ] configure problem. Message-ID: Bugs item #1491936, was opened at 2006-05-19 20:55 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=1491936&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael C Tiernan (mtiernan) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem. Initial Comment: I ran into this today and thought I'd collect everything together and report it. I'm attempting to build the 1.4.3 plugins on: Red Hat Desktop release 3 (Taroon Update 6) and was surprised to see a 'sed' error occur. I got the latest snapshot and did the build and it duplicated the error. I fudged things by setting the debug flag in the configure program and kept the left overs which I've packaged up in a tarball attached to this. I hope this helps. Email me if more info is needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 From rouilj at cs.umb.edu Fri May 19 19:21:05 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri May 19 19:21:05 2006 Subject: [Nagiosplug-devel] Does check_by_ssh in passive mode work? Message-ID: <200605200220.k4K2K7s4009633@mx1.cs.umb.edu> Hi all: I am trying to use check_by_ssh in passive mode from plugins 1.4.3. I can't seem to get it to work. I am invoking it with: /usr/lib/nagios/plugins/check_by_ssh -v -H localhost \ -s A:B:C -O /tmp/out -n foo \ -C "/usr/lib/nagios/plugins/check_disk /" \ -C "/usr/lib/nagios/plugins/check_disk /" \ -C "/usr/lib/nagios/plugins/check_disk /" The verbose output looks ok. /usr/bin/ssh localhost '/usr/lib/nagios/plugins/check_disk /; echo STATUS CODE: $?;/usr/lib/nagios/plugins/check_disk /usr; echo STATUS CODE: $?;/usr/lib/nagios/plugins/check_disk /var; echo STATUS CODE: $?;' but it emits the output from the first command: DISK OK - free space: / 5399 MB (91% inode=99%);| /=554MB;5953;5953;98;5953 on standard out, and creates a 0 length /tmp/out file. I was expecting passive service commands for A, B and C for host "foo" in the /tmp/out file. (Note the same thing occurs without the -v flag.) Does anybody have this working? Or have a better description of what it should be doing? It seems to have a split passive/active output mode that appears a bit weird. I guess it sort of makes sense since the plugin would be run by a service that expects an output string from the plugin. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From reto.schubnell at tg.ch Fri May 19 21:03:07 2006 From: reto.schubnell at tg.ch (Reto Schubnell) Date: Fri May 19 21:03:07 2006 Subject: [Nagiosplug-devel] bug in nagios 1.4.3 perl modules Message-ID: Hi I compiled the nagios plugins 1.4.3 on AIX. I found a missconfiguration in every perl based nagios-plugin. The Libary declaration is not correct: Compiled: use lib "/opt/AFInagios-plugins/libexec" /libexec Correct: use lib "/opt/AFInagios-plugins/libexec /libexec"; Kind regards reto From noreply at sourceforge.net Sat May 20 00:13:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat May 20 00:13:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-20 03:12 Message: Logged In: YES user_id=1520524 I didn't test the last upload enough, so I removed it. I've added lots of additional code to check_disk and I've tested it with every scenario I could think of (including the one you mentioned earlier). It all seems to work properly now. I have added several new features as well: -x will exclude a mount point that matches exactly -s will exclude a path and any mount points within -U outputs the percentages in terms of used space/inodes -H formats the output in HTML (makes it really easy to read on the status page) I think I'm going to continue working on it as I might want the ability to specify different warn/crit percentages for different mount points; any suggestions on how to go about doing that would be nice :) I've attached the file, versioned 1.65.1 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-18 11:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Sat May 20 00:15:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat May 20 00:15:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-20 03:14 Message: Logged In: YES user_id=1520524 Forgot to mention: -p should be working the same way it has been in the past. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 03:12 Message: Logged In: YES user_id=1520524 I didn't test the last upload enough, so I removed it. I've added lots of additional code to check_disk and I've tested it with every scenario I could think of (including the one you mentioned earlier). It all seems to work properly now. I have added several new features as well: -x will exclude a mount point that matches exactly -s will exclude a path and any mount points within -U outputs the percentages in terms of used space/inodes -H formats the output in HTML (makes it really easy to read on the status page) I think I'm going to continue working on it as I might want the ability to specify different warn/crit percentages for different mount points; any suggestions on how to go about doing that would be nice :) I've attached the file, versioned 1.65.1 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-18 11:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Sat May 20 18:47:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat May 20 18:47:59 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-20 21:47 Message: Logged In: YES user_id=1520524 Uploading version 1.65.3m. This one adds slightly better HTML formatted text (places *s around the partition that triggered the alarm) and adds an -a option. The -a option tells check_disk to display all partitions even if -p is also specified: Example check_disk -w 10% -c 5% -a -C -w 5% -c 3% -p / Checks / at 5% and 3% and every other mount at 10% and 5% ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 03:14 Message: Logged In: YES user_id=1520524 Forgot to mention: -p should be working the same way it has been in the past. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 03:12 Message: Logged In: YES user_id=1520524 I didn't test the last upload enough, so I removed it. I've added lots of additional code to check_disk and I've tested it with every scenario I could think of (including the one you mentioned earlier). It all seems to work properly now. I have added several new features as well: -x will exclude a mount point that matches exactly -s will exclude a path and any mount points within -U outputs the percentages in terms of used space/inodes -H formats the output in HTML (makes it really easy to read on the status page) I think I'm going to continue working on it as I might want the ability to specify different warn/crit percentages for different mount points; any suggestions on how to go about doing that would be nice :) I've attached the file, versioned 1.65.1 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-18 11:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Sun May 21 07:01:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 21 07:01:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1492491 ] check_dhcp network iface name too small (cf. bug #1286235) Message-ID: Patches item #1492491, was opened at 2006-05-21 16:00 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=1492491&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 Submitted By: Vincent Zanotti (amidebx) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp network iface name too small (cf. bug #1286235) Initial Comment: Network interface name is only of 7 real chars (8 including final \0). VLAN interfaces need longer names ("eth1.1230" is 10 characters long). Normal Linux systems allow interface names of up to 16 characters (cf , constant IFNAMSIZ). check_dhcp uses this constant IFNAMESIZ a few time. My patch changes char network_interface_name[8]="eth0"; into #if IFNAMSIZ > 8 char network_interface_name[IFNAMSIZ]="eth0"; #else char network_interface_name[8]="eth0"; #endif so it keeps compatibility with other systems which do not have IFNAMSIZ >= 8 ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 From noreply at sourceforge.net Sun May 21 17:05:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 21 17:05:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 13:52 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&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 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2006-05-21 20:04 Message: Logged In: YES user_id=1520524 Sorry for so many updates. I don't know how I missed a small bug. I set the comment in the file for what I meant to happen, but forgot to change the values after I pasted it. I retested it (now that I'm wide awake) and it seems to be working as expected. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 21:47 Message: Logged In: YES user_id=1520524 Uploading version 1.65.3m. This one adds slightly better HTML formatted text (places *s around the partition that triggered the alarm) and adds an -a option. The -a option tells check_disk to display all partitions even if -p is also specified: Example check_disk -w 10% -c 5% -a -C -w 5% -c 3% -p / Checks / at 5% and 3% and every other mount at 10% and 5% ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 03:14 Message: Logged In: YES user_id=1520524 Forgot to mention: -p should be working the same way it has been in the past. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 03:12 Message: Logged In: YES user_id=1520524 I didn't test the last upload enough, so I removed it. I've added lots of additional code to check_disk and I've tested it with every scenario I could think of (including the one you mentioned earlier). It all seems to work properly now. I have added several new features as well: -x will exclude a mount point that matches exactly -s will exclude a path and any mount points within -U outputs the percentages in terms of used space/inodes -H formats the output in HTML (makes it really easy to read on the status page) I think I'm going to continue working on it as I might want the ability to specify different warn/crit percentages for different mount points; any suggestions on how to go about doing that would be nice :) I've attached the file, versioned 1.65.1 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-18 11:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 08:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 17:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 14:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Tue May 23 13:18:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 23 13:18:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1491936 ] configure problem. Message-ID: Bugs item #1491936, was opened at 2006-05-19 17:55 Message generated for change (Comment added) made by jeremy-c-reed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael C Tiernan (mtiernan) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem. Initial Comment: I ran into this today and thought I'd collect everything together and report it. I'm attempting to build the 1.4.3 plugins on: Red Hat Desktop release 3 (Taroon Update 6) and was surprised to see a 'sed' error occur. I got the latest snapshot and did the build and it duplicated the error. I fudged things by setting the debug flag in the configure program and kept the left overs which I've packaged up in a tarball attached to this. I hope this helps. Email me if more info is needed. ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-23 13:17 Message: Logged In: YES user_id=336943 I also had sed problem and reported to devel list: https://sourceforge.net/mailarchive/forum.php?thread_id=10415797&forum_id=8499 My problem is caused by running mysql_config with option that doesn't exist (in my version of mysql_config). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 From noreply at sourceforge.net Wed May 24 01:40:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 24 01:40:21 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1491936 ] configure problem. Message-ID: Bugs item #1491936, was opened at 2006-05-20 01:55 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael C Tiernan (mtiernan) >Assigned to: Ton Voon (tonvoon) Summary: configure problem. Initial Comment: I ran into this today and thought I'd collect everything together and report it. I'm attempting to build the 1.4.3 plugins on: Red Hat Desktop release 3 (Taroon Update 6) and was surprised to see a 'sed' error occur. I got the latest snapshot and did the build and it duplicated the error. I fudged things by setting the debug flag in the configure program and kept the left overs which I've packaged up in a tarball attached to this. I hope this helps. Email me if more info is needed. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-24 09:39 Message: Logged In: YES user_id=664364 Michael, Jeremy, Thanks for the reports. Which version of mysql are you using? Also, if you run "mysql_config --include" (which is the problem one) and "mysql_config --libs" (a good one) on the command line, what return codes do you get? Ton ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-23 21:17 Message: Logged In: YES user_id=336943 I also had sed problem and reported to devel list: https://sourceforge.net/mailarchive/forum.php?thread_id=10415797&forum_id=8499 My problem is caused by running mysql_config with option that doesn't exist (in my version of mysql_config). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 From ton.voon at altinity.com Wed May 24 02:25:07 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed May 24 02:25:07 2006 Subject: [Nagiosplug-devel] compile error for check_snmp.c In-Reply-To: <000101c67b38$404d7180$a601000a@int.consol.de> References: <000101c67b38$404d7180$a601000a@int.consol.de> Message-ID: <1B7DDC38-303E-4C71-8EE1-B30EE75C28C8@altinity.com> Gerhard, Thanks for the patch. Have applied in CVS. Also added a reminder in the dev guidelines not to use declare variables inline. Ton On 19 May 2006, at 12:34, Gerhard Lausser wrote: > Hi, > > for those of you, who see the following error message when > compiling the > plugins > > check_snmp.c: In function `main': > check_snmp.c:343: parse error before `char' > check_snmp.c:344: `str' undeclared (first use in this function) > check_snmp.c:344: (Each undeclared identifier is reported only once > check_snmp.c:344: for each function it appears in.) > > i made a small patch, which you can download from > http://people.consol.de/~lausser/nagios/patches.html > I am not sure, but i think the error occurs when using a gcc < 3.x > > Greetings from Munich, > Gerhard http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Wed May 24 02:37:03 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed May 24 02:37:03 2006 Subject: [Nagiosplug-devel] RFC: check_disk trying to be clever re: mountpoints In-Reply-To: <446D7EB5.9000805@op5.se> References: <200605181542.k4IFgHLD029810@mx1.cs.umb.edu> <20060518160303.GA7245@seanius.net> <7126EF02-E249-408F-918D-05135BE639E7@mac.com> <446D7EB5.9000805@op5.se> Message-ID: <840B6288-5031-4B90-A816-0D07813312C6@altinity.com> On 19 May 2006, at 09:15, Andreas Ericsson wrote: > Ton Voon wrote: >> On 18 May 2006, at 17:03, sean finney wrote: >>> i think what happened was at some point (1.4.2 maybe?), this >>> behaviour >>> disappeared. i recieved a couple bugs about it in the debian >>> BTS, so >>> i added a patch that the restores the functionality, if my memory >>> servers me correctly. >> John has come down on "this behaviour is wrong" with a good >> example of why, which I am swaying towards. Sean, is there a good >> counter- example for when this behaviour is desirable? >>>> 1) Make the default force the directories to be mount points and >>>> exit critical if they aren't. Add a flag to allow the current >>>> behavior. (My preferred option) >>>> >>>> 2) Make the current operation the default and add a flag that >>>> forces >>>> the specified directory to me a mount point and exit >>>> critical if it >>>> isn't. >>> >>> >>> i think either of these would be a good solution to the problem. i'm >>> more partial to (2) because it's more in line with how i remember >>> check_disk historically working. >> I'm more inclined to go with (1) because of John's failure case, >> but I'd rather get rid of the walk filesystem altogether :) > > I vote 2 as well. There's no sane reason to name a file or > directory that's inside a mount-point rather than actually naming > the mount-point itself, and mount-points can reside on other > mounted filesystems which just begs to break if we find multiple > mount-points while walking to it from the root (which is also a > mount-point, btw). Summary: General consensus says to keep current behaviour (walk filesystem for best match), but have a flag to specify exact filesystem match only. I hope no-one wants the case of "walk the filesystem for this -p but check for this exact filesystem" - they will have to run two separate check_disks ;) I'm currently trying to sync the plugins with coreutils 2.95 to pull in newer df code (there was a report ages ago about failure to run ./ configure on newer FreeBSD systems). I then plan on moving some of the C functions out of check_disk into an external disk_utils.c file so that I can run libtap unit tests against the functions. I also want to fix problems against reiserfs filesystems. This will take a few weeks, but hopefully we'll have something more rigourous at the end. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Wed May 24 05:26:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 24 05:26:20 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1491936 ] configure problem. Message-ID: Bugs item #1491936, was opened at 2006-05-19 17:55 Message generated for change (Comment added) made by jeremy-c-reed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael C Tiernan (mtiernan) Assigned to: Ton Voon (tonvoon) Summary: configure problem. Initial Comment: I ran into this today and thought I'd collect everything together and report it. I'm attempting to build the 1.4.3 plugins on: Red Hat Desktop release 3 (Taroon Update 6) and was surprised to see a 'sed' error occur. I got the latest snapshot and did the build and it duplicated the error. I fudged things by setting the debug flag in the configure program and kept the left overs which I've packaged up in a tarball attached to this. I hope this helps. Email me if more info is needed. ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-24 05:25 Message: Logged In: YES user_id=336943 mysql Ver 11.18 Distrib 3.23.58, for pc-linux (i686) $ /usr/local/mysql/bin/mysql_config --include Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I'/usr/local/mysql/include/mysql'] --libs [-L'/usr/local/mysql/lib/mysql' -lmysqlclient -lz -lcrypt -lnsl -lm] --socket [/tmp/mysql.sock] --port [3306] --version [3.23.58] $ echo $? 1 $ mysql_config --libs -L'/usr/local/mysql/lib/mysql' -lmysqlclient -lz -lcrypt -lnsl -lm $ echo $? 0 Maybe using --cflags instead of --includes is good enough? - Jeremy ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-24 01:39 Message: Logged In: YES user_id=664364 Michael, Jeremy, Thanks for the reports. Which version of mysql are you using? Also, if you run "mysql_config --include" (which is the problem one) and "mysql_config --libs" (a good one) on the command line, what return codes do you get? Ton ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-23 13:17 Message: Logged In: YES user_id=336943 I also had sed problem and reported to devel list: https://sourceforge.net/mailarchive/forum.php?thread_id=10415797&forum_id=8499 My problem is caused by running mysql_config with option that doesn't exist (in my version of mysql_config). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 From noreply at sourceforge.net Wed May 24 05:50:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 24 05:50:22 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1491936 ] configure problem. Message-ID: Bugs item #1491936, was opened at 2006-05-20 01:55 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Michael C Tiernan (mtiernan) Assigned to: Ton Voon (tonvoon) Summary: configure problem. Initial Comment: I ran into this today and thought I'd collect everything together and report it. I'm attempting to build the 1.4.3 plugins on: Red Hat Desktop release 3 (Taroon Update 6) and was surprised to see a 'sed' error occur. I got the latest snapshot and did the build and it duplicated the error. I fudged things by setting the debug flag in the configure program and kept the left overs which I've packaged up in a tarball attached to this. I hope this helps. Email me if more info is needed. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-24 13:49 Message: Logged In: YES user_id=664364 Jeremy, Thanks. I've applied a fix where we reset MYSQLINCLUDES if the return code is non-zero. Unfortunately, the snapshots don't appear to be working because SF's compile farm shell server is down, but I think this should be a good fix. I've marked the call in pending. Please change if it is still a problem. Ton ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-24 13:25 Message: Logged In: YES user_id=336943 mysql Ver 11.18 Distrib 3.23.58, for pc-linux (i686) $ /usr/local/mysql/bin/mysql_config --include Usage: /usr/local/mysql/bin/mysql_config [OPTIONS] Options: --cflags [-I'/usr/local/mysql/include/mysql'] --libs [-L'/usr/local/mysql/lib/mysql' -lmysqlclient -lz -lcrypt -lnsl -lm] --socket [/tmp/mysql.sock] --port [3306] --version [3.23.58] $ echo $? 1 $ mysql_config --libs -L'/usr/local/mysql/lib/mysql' -lmysqlclient -lz -lcrypt -lnsl -lm $ echo $? 0 Maybe using --cflags instead of --includes is good enough? - Jeremy ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-24 09:39 Message: Logged In: YES user_id=664364 Michael, Jeremy, Thanks for the reports. Which version of mysql are you using? Also, if you run "mysql_config --include" (which is the problem one) and "mysql_config --libs" (a good one) on the command line, what return codes do you get? Ton ---------------------------------------------------------------------- Comment By: Jeremy C. Reed (jeremy-c-reed) Date: 2006-05-23 21:17 Message: Logged In: YES user_id=336943 I also had sed problem and reported to devel list: https://sourceforge.net/mailarchive/forum.php?thread_id=10415797&forum_id=8499 My problem is caused by running mysql_config with option that doesn't exist (in my version of mysql_config). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1491936&group_id=29880 From noreply at sourceforge.net Wed May 24 15:42:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed May 24 15:42:15 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1494629 ] 1.4.3 - check_icmp fails after a time on FreeBSD Message-ID: Bugs item #1494629, was opened at 2006-05-25 06:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&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 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 1.4.3 - check_icmp fails after a time on FreeBSD Initial Comment: Current release (1.4.3) check_icmp on FreeBSD 6.1 works fine for some hours, then reports 100% packet loss. This is due to the plugin not allowing for the fact that PIDs can be greater than 65535 (i.e. more than 16 bits) on systems such as FreeBSD. Further details are given in http://article.gmane.org/gmane.network.nagios.plugins/1945 . A version of check_icmp available from Andreas fixes this issue. This version has an earlier date associated with it than the version distributed in nagios-plugins, but a higher revsion number. Quote: """ If the fix isn't available in a recent package from the official nagiosplug package you should be able to use the one found at http://oss.op5.se/nagios/check_icmp-2005-06-01.tar.gz You can notice if the fix is available from the nagiosplug project by doing $ grep -q 'pid & 0xffff' check_icmp.c && echo "Fix available" """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1494629&group_id=29880 From noreply at sourceforge.net Thu May 25 09:34:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 09:34:11 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1492491 ] check_dhcp network iface name too small (cf. bug #1286235) Message-ID: Patches item #1492491, was opened at 2006-05-21 14:00 Message generated for change (Settings changed) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&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 Submitted By: Vincent Zanotti (amidebx) >Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp network iface name too small (cf. bug #1286235) Initial Comment: Network interface name is only of 7 real chars (8 including final \0). VLAN interfaces need longer names ("eth1.1230" is 10 characters long). Normal Linux systems allow interface names of up to 16 characters (cf , constant IFNAMSIZ). check_dhcp uses this constant IFNAMESIZ a few time. My patch changes char network_interface_name[8]="eth0"; into #if IFNAMSIZ > 8 char network_interface_name[IFNAMSIZ]="eth0"; #else char network_interface_name[8]="eth0"; #endif so it keeps compatibility with other systems which do not have IFNAMSIZ >= 8 ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 From noreply at sourceforge.net Thu May 25 09:35:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 09:35:14 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1288725 ] check_dhcp UNKNOWN set incorrectly, output matches standards Message-ID: Patches item #1288725, was opened at 2005-09-12 13:53 Message generated for change (Settings changed) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&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 Submitted By: Garrett Honeycutt (monkeymanorg) >Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp UNKNOWN set incorrectly, output matches standards Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- Comment By: Garrett Honeycutt (monkeymanorg) Date: 2005-11-18 19:01 Message: Logged In: YES user_id=1277734 updated the patch against the 1.4.2 branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 From noreply at sourceforge.net Thu May 25 10:04:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:04:10 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1492491 ] check_dhcp network iface name too small (cf. bug #1286235) Message-ID: Patches item #1492491, was opened at 2006-05-21 14:00 Message generated for change (Comment added) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Vincent Zanotti (amidebx) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp network iface name too small (cf. bug #1286235) Initial Comment: Network interface name is only of 7 real chars (8 including final \0). VLAN interfaces need longer names ("eth1.1230" is 10 characters long). Normal Linux systems allow interface names of up to 16 characters (cf , constant IFNAMSIZ). check_dhcp uses this constant IFNAMESIZ a few time. My patch changes char network_interface_name[8]="eth0"; into #if IFNAMSIZ > 8 char network_interface_name[IFNAMSIZ]="eth0"; #else char network_interface_name[8]="eth0"; #endif so it keeps compatibility with other systems which do not have IFNAMSIZ >= 8 ... ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:00 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 From noreply at sourceforge.net Thu May 25 10:04:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:04:16 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1286235 ] check_dhcp network interface name too small Message-ID: Bugs item #1286235, was opened at 2005-09-09 18:03 Message generated for change (Settings changed) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1286235&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 Submitted By: jbgorrie (jbgorrie) >Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp network interface name too small Initial Comment: If you have a VLAN configuration under linux, you can have names longer than the permited 7 characters. eg: eth0.312 will fail with stock 1.4.1 line 1261 of stock 1.4.1 has char network_interface_name[8]="eth0"; I have requirements of names that are up to 11 characters. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:01 Message: Logged In: YES user_id=2225 this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1286235&group_id=29880 From noreply at sourceforge.net Thu May 25 10:06:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:06:06 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1288725 ] check_dhcp UNKNOWN set incorrectly, output matches standards Message-ID: Patches item #1288725, was opened at 2005-09-12 13:53 Message generated for change (Comment added) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Garrett Honeycutt (monkeymanorg) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp UNKNOWN set incorrectly, output matches standards Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:00 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Garrett Honeycutt (monkeymanorg) Date: 2005-11-18 19:01 Message: Logged In: YES user_id=1277734 updated the patch against the 1.4.2 branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 From noreply at sourceforge.net Thu May 25 10:07:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:07:06 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1492491 ] check_dhcp network iface name too small (cf. bug #1286235) Message-ID: Patches item #1492491, was opened at 2006-05-21 14:00 Message generated for change (Comment added) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Vincent Zanotti (amidebx) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp network iface name too small (cf. bug #1286235) Initial Comment: Network interface name is only of 7 real chars (8 including final \0). VLAN interfaces need longer names ("eth1.1230" is 10 characters long). Normal Linux systems allow interface names of up to 16 characters (cf , constant IFNAMSIZ). check_dhcp uses this constant IFNAMESIZ a few time. My patch changes char network_interface_name[8]="eth0"; into #if IFNAMSIZ > 8 char network_interface_name[IFNAMSIZ]="eth0"; #else char network_interface_name[8]="eth0"; #endif so it keeps compatibility with other systems which do not have IFNAMSIZ >= 8 ... ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:01 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:00 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1492491&group_id=29880 From noreply at sourceforge.net Thu May 25 10:07:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:07:08 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1288725 ] check_dhcp UNKNOWN set incorrectly, output matches standards Message-ID: Patches item #1288725, was opened at 2005-09-12 13:53 Message generated for change (Comment added) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Garrett Honeycutt (monkeymanorg) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp UNKNOWN set incorrectly, output matches standards Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:02 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:00 Message: Logged In: YES user_id=2225 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Garrett Honeycutt (monkeymanorg) Date: 2005-11-18 19:01 Message: Logged In: YES user_id=1277734 updated the patch against the 1.4.2 branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 From noreply at sourceforge.net Thu May 25 10:09:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:09:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484825 ] check_dhcp fails to link on Solaris 2.6 Message-ID: Bugs item #1484825, was opened at 2006-05-09 16:35 Message generated for change (Settings changed) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&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 Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp fails to link on Solaris 2.6 Initial Comment: /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a -liconv -lgen -lnsl gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/tmp/nagios-plugins-1.4.3/plugins-root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lresolv ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lnsl -R/usr/local/lib -R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 ===== Modifying the Makefile EXTRA_NETOBJS = getaddrinfo.o gethostbyname.o to EXTRA_NETOBJS = ../plugins/getaddrinfo.o ../plugins/gethostbyname.o fixes it ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 05:19 Message: Logged In: YES user_id=1495257 Same thing occurs on Solaris 7 using gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release): source='check_dhcp.c' object='check_dhcp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -c check_dhcp.c /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a - lgen -lnsl -lssl -lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket - lresolv ../intl/libintl.a -lgen -lnsl -lssl -lcrypto - R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 However on Solaris 8 using gcc version 3.3.2 this problem does not occurr: if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -MT check_dhcp.o -MD -MP -MF ".deps/check_dhcp.Tpo" -c - o check_dhcp.o check_dhcp.c; \ then mv -f ".deps/check_dhcp.Tpo" ".deps/check_dhcp.Po"; else rm -f ".deps/check_dhcp.Tpo"; exit 1; fi /bin/bash ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket - lresolv ../intl/libintl.a -liconv -lgen -lsocket -lssl - lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o - L/home/gtri/nagios/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl - lresolv ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 From noreply at sourceforge.net Thu May 25 10:10:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:10:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1284352 ] check_dhcp -s not compatible with helpers/relays Message-ID: Bugs item #1284352, was opened at 2005-09-07 23:19 Message generated for change (Settings changed) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Connor (nekodojo) >Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp -s not compatible with helpers/relays Initial Comment: check_dhcp -s is supposed to verify that a response is received from a certain server (or servers). But, when used with a dhcp relay agent (or an iphelper in Cisco speak) the offer appears to come from the relay, not the actual server which answered. When the plugin is used with $HOSTADDRESS$ to target a particular server, the reply comes from the relay/forwarder and not from the dhcp server, so the status will show an error even if the DHCP server we want to test is up. This can be worked around by testing the relays with -s instead of the ip of the dhcp server. However, if there are multiple servers to be monitored and they are not on the same network as the nagios server. In that case, the plugin will always report at least one answer from each relay and the plugin can't tell if all the dhcp servers are working. The expected behavior is to use the IP from "siaddr" if it is non-zero, which would indicate that the reply was forwarded on behalf of a remote DHCP server. (see diff for a suggested fix) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&group_id=29880 From noreply at sourceforge.net Thu May 25 10:11:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:11:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 20:21 Message generated for change (Settings changed) made by egalstad 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: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 08: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 23: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-07 18: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 10: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 10: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 10: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 10: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 09: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 09: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 08: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 08: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-24 02: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 09: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 10: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 20: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 18: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 noreply at sourceforge.net Thu May 25 10:41:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:41:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1284352 ] check_dhcp -s not compatible with helpers/relays Message-ID: Bugs item #1284352, was opened at 2005-09-07 23:19 Message generated for change (Comment added) made by egalstad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&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 Submitted By: Greg Connor (nekodojo) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp -s not compatible with helpers/relays Initial Comment: check_dhcp -s is supposed to verify that a response is received from a certain server (or servers). But, when used with a dhcp relay agent (or an iphelper in Cisco speak) the offer appears to come from the relay, not the actual server which answered. When the plugin is used with $HOSTADDRESS$ to target a particular server, the reply comes from the relay/forwarder and not from the dhcp server, so the status will show an error even if the DHCP server we want to test is up. This can be worked around by testing the relays with -s instead of the ip of the dhcp server. However, if there are multiple servers to be monitored and they are not on the same network as the nagios server. In that case, the plugin will always report at least one answer from each relay and the plugin can't tell if all the dhcp servers are working. The expected behavior is to use the IP from "siaddr" if it is non-zero, which would indicate that the reply was forwarded on behalf of a remote DHCP server. (see diff for a suggested fix) ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 17:40 Message: Logged In: YES user_id=2225 this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1284352&group_id=29880 From noreply at sourceforge.net Thu May 25 10:58:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 10:58:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 20:21 Message generated for change (Comment added) made by egalstad 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: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: Ethan Galstad (egalstad) Date: 2006-05-25 17: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 08: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 23: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-07 18: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 10: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 10: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 10: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 10: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 09: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 09: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 08: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 08: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-24 02: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 09: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 10: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 20: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 18: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 noreply at sourceforge.net Thu May 25 11:12:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 11:12:03 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 20:21 Message generated for change (Comment added) made by egalstad 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: v1.3.0 beta3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: Ethan Galstad (egalstad) Date: 2006-05-25 18: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 17: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 08: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 23: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-07 18: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 10: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 10: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 10: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 10: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 09: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 09: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 08: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 08: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-24 02: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 09: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 10: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 20: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 18: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 noreply at sourceforge.net Thu May 25 21:34:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 25 21:34:01 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-24 09:21 Message generated for change (Comment added) made by reuben 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: v1.3.0 beta3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: Reuben Farrelly (reuben) Date: 2006-05-26 16: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-26 06: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-26 05: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 21: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-08 12: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 07: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 23: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 23: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 23: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 23: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 22: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 22: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 21: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 21: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-24 15: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 22: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 23: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-03 09: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-03 07: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 noreply at sourceforge.net Fri May 26 07:54:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 26 07:54:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 20:21 Message generated for change (Settings changed) made by egalstad 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: v1.3.0 beta3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: Reuben Farrelly (reuben) Date: 2006-05-26 04: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 18: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 17: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 08: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 23: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-07 18: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 10: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 10: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 10: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 10: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 09: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 09: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 08: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 08: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-24 02: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 09: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 10: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 20: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 18: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 noreply at sourceforge.net Fri May 26 08:47:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 26 08:47:09 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1482840 ] check_radius from 1.4.3 fails to build Message-ID: Bugs item #1482840, was opened at 2006-05-05 22:29 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&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 Submitted By: Holger Weiss (hweiss) Assigned to: Nobody/Anonymous (nobody) Summary: check_radius from 1.4.3 fails to build Initial Comment: check_radius from the 1.4.3 release fails to build on Debian Sarge (the 1.4.2 release works fine): /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -o check_radius check_radius.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lradiusclient -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_radius check_radius.o netutils.o utils.o -L/server/nagios/src/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so -lcrypt -lnsl -lssl -lcrypto gcc: /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so: No such file or directory make[3]: *** [check_radius] Error 1 Manually building check_radius by replacing the broken path to libradiusclient.so with "-lradiusclient" works fine. ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2006-05-26 11:46 Message: Logged In: YES user_id=226838 hey holger, i'm being bitten by this too. afaict this problem has to do with the recently introduced libtool support, but this is a bit outside of my area of understanding. it seems like libtool is introducing a '.libs' directory in between the actual directory and location of the radiusclient library. i can't tell why exactly. i can verify, however, that if you comment out the AC_PROG_LIBTOOL macro in configure.in and rebuild configure, everything compiles successfully, so i thought i'd share that with you :) now, i wonder if anyone else on the list knows what's going on here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&group_id=29880 From seanius at seanius.net Fri May 26 08:50:10 2006 From: seanius at seanius.net (sean finney) Date: Fri May 26 08:50:10 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: References: Message-ID: <20060526154932.GA28595@seanius.net> if anyone who knows more about libtool could comment on this, i'd be appreciative as it's currently blocking any progress with my debian packaging... sean On Fri, May 26, 2006 at 08:46:15AM -0700, SourceForge.net wrote: > 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 > Submitted By: Holger Weiss (hweiss) > Assigned to: Nobody/Anonymous (nobody) > Summary: check_radius from 1.4.3 fails to build > > Initial Comment: > check_radius from the 1.4.3 release fails to build on > Debian Sarge (the 1.4.2 release works fine): > > /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g > -O2 -L. -o check_radius check_radius.o netutils.o > utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a > -lnsl -lresolv -lradiusclient -lssl -lcrypto > gcc -Wall -g -O2 -o .libs/check_radius check_radius.o > netutils.o utils.o > -L/server/nagios/src/nagios-plugins-1.4.3/plugins > ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv > /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so > -lcrypt -lnsl -lssl -lcrypto > gcc: > /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so: > No such file or directory > make[3]: *** [check_radius] Error 1 > > Manually building check_radius by replacing the broken > path to libradiusclient.so with "-lradiusclient" works > fine. > > ---------------------------------------------------------------------- > > >Comment By: M. Sean Finney (seanius) > Date: 2006-05-26 11:46 > > Message: > Logged In: YES > user_id=226838 > > hey holger, > > i'm being bitten by this too. afaict this problem has to do > with the recently introduced libtool support, but this is a > bit outside of my area of understanding. it seems like > libtool is introducing a '.libs' directory in between the > actual directory and location of the radiusclient library. > i can't tell why exactly. > > i can verify, however, that if you comment out the > AC_PROG_LIBTOOL macro in configure.in and rebuild configure, > everything compiles successfully, so i thought i'd share > that with you :) > > now, i wonder if anyone else on the list knows what's going > on here... > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&group_id=29880 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Fri May 26 12:18:03 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri May 26 12:18:03 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: <20060526154932.GA28595@seanius.net> References: <20060526154932.GA28595@seanius.net> Message-ID: I got the same problem on my Debian box. Not sure why libtool is changing -lradiusclient to the .so file. I upgraded libtool to 1.5.22 and ran tools/setup && ./configure && make and it worked, so I guess this is a bug in the older libtool (was on 1.5.6). I'll update docs and build servers next week. I personally think that the GNU toolchain (autoconf, automake, gettext, libtool) is a major pain in the arse, but I think it is like a latrine: very messy and deeply horrible, but if you don't use it, you'll end up cleaning up other people's shit. Ton On 26 May 2006, at 16:49, sean finney wrote: > if anyone who knows more about libtool could comment on this, i'd be > appreciative as it's currently blocking any progress with my debian > packaging... > > sean > > On Fri, May 26, 2006 at 08:46:15AM -0700, SourceForge.net wrote: >> 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 >> Submitted By: Holger Weiss (hweiss) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: check_radius from 1.4.3 fails to build >> >> Initial Comment: >> check_radius from the 1.4.3 release fails to build on >> Debian Sarge (the 1.4.2 release works fine): >> >> /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g >> -O2 -L. -o check_radius check_radius.o netutils.o >> utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a >> -lnsl -lresolv -lradiusclient -lssl -lcrypto >> gcc -Wall -g -O2 -o .libs/check_radius check_radius.o >> netutils.o utils.o >> -L/server/nagios/src/nagios-plugins-1.4.3/plugins >> ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv >> /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so >> -lcrypt -lnsl -lssl -lcrypto >> gcc: >> /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so: >> No such file or directory >> make[3]: *** [check_radius] Error 1 >> >> Manually building check_radius by replacing the broken >> path to libradiusclient.so with "-lradiusclient" works >> fine. >> >> --------------------------------------------------------------------- >> - >> >>> Comment By: M. Sean Finney (seanius) >> Date: 2006-05-26 11:46 >> >> Message: >> Logged In: YES >> user_id=226838 >> >> hey holger, >> >> i'm being bitten by this too. afaict this problem has to do >> with the recently introduced libtool support, but this is a >> bit outside of my area of understanding. it seems like >> libtool is introducing a '.libs' directory in between the >> actual directory and location of the radiusclient library. >> i can't tell why exactly. >> >> i can verify, however, that if you comment out the >> AC_PROG_LIBTOOL macro in configure.in and rebuild configure, >> everything compiles successfully, so i thought i'd share >> that with you :) >> >> now, i wonder if anyone else on the list knows what's going >> on here... >> >> --------------------------------------------------------------------- >> - >> >> You can respond by visiting: >> https://sourceforge.net/tracker/? >> func=detail&atid=397597&aid=1482840&group_id=29880 >> http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri May 26 18:41:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 26 18:41:09 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1495828 ] pst3 failure on solaris 10 x86 Message-ID: Bugs item #1495828, was opened at 2006-05-26 20:40 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=1495828&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: edward dertouzas (ophten) Assigned to: Nobody/Anonymous (nobody) Summary: pst3 failure on solaris 10 x86 Initial Comment: https://sourceforge.net/tracker/index.php?func=detail&aid=1476451&group_id=29880&atid=397597 check_procs fails on Solaris 10 x86: root at infdb4.prodqa.coremetrics.com # ./check_procs -vvv CMD: /usr/local/nagios_new/libexec/pst3 CRITICAL - Plugin timed out after 10 seconds truss shows this just spinning through a read, finding nothing, then eventually trapping a SIGALRM. Onward! root at infdb4.prodqa.coremetrics.com # /usr/local/nagios_new/libexec/pst3 /usr/local/nagios_new/libexec/pst3: /dev/ksyms is not a 32-bit kernel namelist pst3: Failed to open kernel memory: Error 0 It appears we're using a 32-bit version of libkvm. I assume the generic /usr/lib/libkvm.so is a 32-bit version while /usr/lib/amd64/libkvm.so is 64-bit. At least the ELF class for libkvm.so is 64-bit. I can't seem to find the write linking magic to make this work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1495828&group_id=29880 From seanius at seanius.net Sat May 27 03:31:01 2006 From: seanius at seanius.net (sean finney) Date: Sat May 27 03:31:01 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: References: <20060526154932.GA28595@seanius.net> Message-ID: <20060527102951.GA30334@seanius.net> On Fri, May 26, 2006 at 08:17:18PM +0100, Ton Voon wrote: > I got the same problem on my Debian box. Not sure why libtool is > changing -lradiusclient to the .so file. i seems like it has something to do with the .la file found in /usr/lib/libradiusclient.la. looking more closely, i see it has: # Is this an already installed library? installed=no shouldn't that be "yes"? a little heavy handed editing of the file confirms it compiles when set to yes. > I upgraded libtool to 1.5.22 and ran tools/setup && ./configure && > make and it worked, so I guess this is a bug in the older libtool > (was on 1.5.6). well i guess we have that, at least. but this does mean that users who only have older versions of libtool won't be able to follow CVS, at least with radiusclient installed. isn't there something we can do? it would be nice if we could somehow politely tell libtool "no really, i promise this library is already installed"... i'll ask on debian-devel and see if i can get any of the libtool knowledgable folks to comment. > I personally think that the GNU toolchain (autoconf, automake, > gettext, libtool) is a major pain in the arse, but I think it is like > a latrine: very messy and deeply horrible, but if you don't use it, > you'll end up cleaning up other people's shit. true, true... sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Sat May 27 08:32:07 2006 From: ton.voon at altinity.com (Ton Voon) Date: Sat May 27 08:32:07 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: <20060527102951.GA30334@seanius.net> References: <20060526154932.GA28595@seanius.net> <20060527102951.GA30334@seanius.net> Message-ID: On 27 May 2006, at 11:29, sean finney wrote: > On Fri, May 26, 2006 at 08:17:18PM +0100, Ton Voon wrote: >> I upgraded libtool to 1.5.22 and ran tools/setup && ./configure && >> make and it worked, so I guess this is a bug in the older libtool >> (was on 1.5.6). > > well i guess we have that, at least. but this does mean that > users who only have older versions of libtool won't be able > to follow CVS, at least with radiusclient installed. I was thinking, maybe we should add the libtool generated files into CVS. automake and autoconf get regenerated all the time, but libtool should be fairly static. > isn't there something we can do? it would be nice if we could > somehow politely tell libtool "no really, i promise this library > is already installed"... > > i'll ask on debian-devel and see if i can get any of the libtool > knowledgable folks to comment. Good plan. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Sat May 27 09:45:09 2006 From: seanius at seanius.net (sean finney) Date: Sat May 27 09:45:09 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: References: <20060526154932.GA28595@seanius.net> <20060527102951.GA30334@seanius.net> Message-ID: <20060527164429.GA31220@seanius.net> hey ton, On Sat, May 27, 2006 at 04:31:17PM +0100, Ton Voon wrote: > I was thinking, maybe we should add the libtool generated files into > CVS. automake and autoconf get regenerated all the time, but libtool > should be fairly static. i'd say that replacing/updating/maintaining ltmain.sh should be enough, as if i understand correctly it's responsible for creating the other files and doesn't have any external dependencies (unlike configure.in and Makefile.am/Makefile.in, which require specific versions of the autofoo programs). so on that note, as soon as the CVS servers are back up... sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From seanius at seanius.net Sat May 27 11:37:03 2006 From: seanius at seanius.net (sean finney) Date: Sat May 27 11:37:03 2006 Subject: [Nagiosplug-devel] CVS directories in official release Message-ID: <20060527183609.GA31530@seanius.net> just fyi: W: nagios-plugins source: source-contains-CVS-dir plugins-scripts/t/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/mandrake/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/fedora/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/solaris/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/suse/CVS W: nagios-plugins source: source-contains-CVS-dir pkg/redhat/CVS W: nagios-plugins source: source-contains-CVS-dir contrib/tarballs/CVS W: nagios-plugins source: source-contains-CVS-dir contrib/aix/CVS W: nagios-plugins source: source-contains-CVS-dir contrib/CVS W: nagios-plugins source: source-contains-CVS-dir plugins/t/CVS probably want to make sure they're pruned out as well for future releases. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From sghosh at sghosh.org Sat May 27 16:30:03 2006 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sat May 27 16:30:03 2006 Subject: [Nagiosplug-devel] CVS directories in official release In-Reply-To: <20060527183609.GA31530@seanius.net> References: <20060527183609.GA31530@seanius.net> Message-ID: On Sat, 27 May 2006, sean finney wrote: > just fyi: > > W: nagios-plugins source: source-contains-CVS-dir plugins-scripts/t/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/mandrake/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/fedora/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/solaris/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/suse/CVS > W: nagios-plugins source: source-contains-CVS-dir pkg/redhat/CVS > W: nagios-plugins source: source-contains-CVS-dir contrib/tarballs/CVS > W: nagios-plugins source: source-contains-CVS-dir contrib/aix/CVS > W: nagios-plugins source: source-contains-CVS-dir contrib/CVS > W: nagios-plugins source: source-contains-CVS-dir plugins/t/CVS > > > probably want to make sure they're pruned out as well for future > releases. > yes - will take care of that. -- -thanks -sg From noreply at sourceforge.net Sun May 28 06:30:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun May 28 06:30:17 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-24 09:21 Message generated for change (Comment added) made by reuben 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: v1.3.0 beta3 Status: Open Resolution: Fixed Priority: 5 Submitted By: L.C. (Laurentiu C. Badea) (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: Reuben Farrelly (reuben) Date: 2006-05-29 01: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-26 16: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-26 06: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-26 05: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 21: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-08 12: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: L.C. (Laurentiu C. Badea) (wotevah) Date: 2005-02-08 07: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 23: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 23: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 23: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 23: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 22: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 22: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 21: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 21: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-24 15: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 22: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 23: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-03 09: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-03 07: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 noreply at sourceforge.net Mon May 29 17:46:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon May 29 17:46:13 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1497248 ] check_disk does not compile on Solaris 10 because of floorf Message-ID: Bugs item #1497248, was opened at 2006-05-30 10:45 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=1497248&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 Submitted By: Daniel Austin (danaus) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk does not compile on Solaris 10 because of floorf Initial Comment: Nagios Plugis: 1.4.3 Related to previous bug: 1374705 Compilation on Solaris 10 results in error when compiling check_disk.c: error: static declaration of 'floorf' follows non-static declaration On line 32 of check_disk.c common.h is imported. On line 196 of common.h we see: /* Solaris does not have floorf, but floor works. Should probably be in configure */ #if defined(__sun) || defined(__sun__) static inline float floorf (float x) { return floor(x); } #endif Solaris 10 actually *does* have floorf (but not earlier versions it seems). Workaround is to just comment out the line for now but, as original commenter said, prob best to replace this with configure test. Sorry -- lack the skill to do that at the moment, so no patch. :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1497248&group_id=29880 From noreply at sourceforge.net Tue May 30 02:39:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 30 02:39:07 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1482840 ] check_radius from 1.4.3 fails to build Message-ID: Bugs item #1482840, was opened at 2006-05-06 03:29 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Holger Weiss (hweiss) >Assigned to: Ton Voon (tonvoon) Summary: check_radius from 1.4.3 fails to build Initial Comment: check_radius from the 1.4.3 release fails to build on Debian Sarge (the 1.4.2 release works fine): /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g -O2 -L. -o check_radius check_radius.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lradiusclient -lssl -lcrypto gcc -Wall -g -O2 -o .libs/check_radius check_radius.o netutils.o utils.o -L/server/nagios/src/nagios-plugins-1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a -lresolv /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so -lcrypt -lnsl -lssl -lcrypto gcc: /usr/lib/gcc-lib/i486-linux/3.3.5/../../..//.libs/libradiusclient.so: No such file or directory make[3]: *** [check_radius] Error 1 Manually building check_radius by replacing the broken path to libradiusclient.so with "-lradiusclient" works fine. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-05-30 10:38 Message: Logged In: YES user_id=664364 Holger, Thanks for the report. We've updated libtool so this fixes it on my Debian system. Can you try the snapshot please at http://nagiosplug.sf.net/snapshot. I've marked the call into pending - please reopen if it is still a problem. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2006-05-26 16:46 Message: Logged In: YES user_id=226838 hey holger, i'm being bitten by this too. afaict this problem has to do with the recently introduced libtool support, but this is a bit outside of my area of understanding. it seems like libtool is introducing a '.libs' directory in between the actual directory and location of the radiusclient library. i can't tell why exactly. i can verify, however, that if you comment out the AC_PROG_LIBTOOL macro in configure.in and rebuild configure, everything compiles successfully, so i thought i'd share that with you :) now, i wonder if anyone else on the list knows what's going on here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482840&group_id=29880 From ton.voon at altinity.com Tue May 30 02:41:03 2006 From: ton.voon at altinity.com (Ton Voon) Date: Tue May 30 02:41:03 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: <20060527164429.GA31220@seanius.net> References: <20060526154932.GA28595@seanius.net> <20060527102951.GA30334@seanius.net> <20060527164429.GA31220@seanius.net> Message-ID: <2E347969-7228-480A-B83A-46F35461F13F@altinity.com> On 27 May 2006, at 17:44, sean finney wrote: > i'd say that replacing/updating/maintaining ltmain.sh should be > enough, > as if i understand correctly it's responsible for creating the other > files and doesn't have any external dependencies (unlike configure.in > and Makefile.am/Makefile.in, which require specific versions of the > autofoo programs). Sold. Hope you don't mind, I've just updated CVS with the libtool files and closed the tracker item. I've also manually updated the snapshot since SF's compile shell server hasn't been working for over 2 weeks now. The snapshot compiles check_radius cleanly now. > so on that note, as soon as the CVS servers are back up... Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Tue May 30 09:18:03 2006 From: seanius at seanius.net (sean finney) Date: Tue May 30 09:18:03 2006 Subject: [Nagiosplug-devel] check_radius, -lradiusclient, and libtool wierdness In-Reply-To: <2E347969-7228-480A-B83A-46F35461F13F@altinity.com> References: <20060526154932.GA28595@seanius.net> <20060527102951.GA30334@seanius.net> <20060527164429.GA31220@seanius.net> <2E347969-7228-480A-B83A-46F35461F13F@altinity.com> Message-ID: <20060530161729.GA16509@seanius.net> hey ton, On Tue, May 30, 2006 at 10:40:43AM +0100, Ton Voon wrote: > >i'd say that replacing/updating/maintaining ltmain.sh should be > >enough, > >as if i understand correctly it's responsible for creating the other > >files and doesn't have any external dependencies (unlike configure.in > >and Makefile.am/Makefile.in, which require specific versions of the > >autofoo programs). > > Sold. Hope you don't mind, I've just updated CVS with the libtool > files and closed the tracker item. I've also manually updated the > snapshot since SF's compile shell server hasn't been working for over > 2 weeks now. The snapshot compiles check_radius cleanly now. great, thanks. i was under the impression that cvs was down for the past 2 weeks, turns out cvs.sourceforge.net != nagiosplug.cvs.sourceforge.net, go figure. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: