From matthias.flacke at stiegemeyer.de Tue May 1 16:15:04 2007 From: matthias.flacke at stiegemeyer.de (Matthias Flacke) Date: Tue, 1 May 2007 16:15:04 +0200 (MEST) Subject: [Nagiosplug-devel] Patch: check_time returns OK if time is before or equal 1.1.1970 Message-ID: <200705011415.l41EF4mI024989@post.webmailer.de> Hello list, if a machine - perhaps due to a crash - gets a date before 1970 check_time returns a wrong OK result even if the diff_time seems to be reasonable: $ date Thu Jan 1 00:01:01 CET 1970 $ ./check_time -w 5 -c 10 -H ntp1.fau.de TIME OK - 3116935377 second time difference|time=0s;;;0 offset=-1178031919s;5;10;0 The problem lies in the signed var diff_time which can get negative and then for sure is smaller than the positive thresholds warning_diff or critical_diff. A small patch changes time_t diff_time into uint32_t and works fine for me. Best regards, Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: check_time.c.patch Type: application/octet-stream Size: 361 bytes Desc: not available URL: From Thomas at zango.com Tue May 1 16:56:13 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 1 May 2007 07:56:13 -0700 Subject: [Nagiosplug-devel] Patch: check_time returns OK if time is beforeor equal 1.1.1970 In-Reply-To: <200705011415.l41EF4mI024989@post.webmailer.de> References: <200705011415.l41EF4mI024989@post.webmailer.de> Message-ID: <804160344192334BB21922E8082EA6C083D329@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Matthias Flacke > Sent: May 1, 2007 10:15 > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Patch: check_time returns OK if > time is beforeor equal 1.1.1970 > > Hello list, > > if a machine - perhaps due to a crash - gets a date before 1970 > check_time returns a wrong OK result even if the diff_time seems to be > reasonable: > > $ date > Thu Jan 1 00:01:01 CET 1970 > $ ./check_time -w 5 -c 10 -H ntp1.fau.de > TIME OK - 3116935377 second time difference|time=0s;;;0 > offset=-1178031919s;5;10;0 > > The problem lies in the signed var diff_time which can get > negative and > then for sure is smaller than the positive thresholds warning_diff or > critical_diff. > > A small patch changes time_t diff_time into uint32_t and > works fine for > me. Nice one, thanks! Will commit tonight if nobody beat me at it. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From dermoth at aei.ca Wed May 2 07:29:06 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 02 May 2007 01:29:06 -0400 Subject: [Nagiosplug-devel] Patch: check_time returns OK if time is before or equal 1.1.1970 In-Reply-To: <200705011415.l41EF4mI024989@post.webmailer.de> References: <200705011415.l41EF4mI024989@post.webmailer.de> Message-ID: <463821A2.2060406@aei.ca> On 01/05/07 10:15 AM, Matthias Flacke wrote: > Hello list, > > if a machine - perhaps due to a crash - gets a date before 1970 > check_time returns a wrong OK result even if the diff_time seems to be > reasonable: > > $ date > Thu Jan 1 00:01:01 CET 1970 > $ ./check_time -w 5 -c 10 -H ntp1.fau.de > TIME OK - 3116935377 second time difference|time=0s;;;0 offset=-1178031919s;5;10;0 > > The problem lies in the signed var diff_time which can get negative and > then for sure is smaller than the positive thresholds warning_diff or > critical_diff. > > A small patch changes time_t diff_time into uint32_t and works fine for > me. This seems to be very arch-specific; to reproduce it on both my x86_64 and i386 I had to replace time_t by int16_t. I changed a bit your patch to: 1. Have server_time unsigned long as well (server_time comes from ntohl() which return type ulong) 2. Remove unneeded casts The attached patch have been committed to CVS. Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: check_time.unsigned_diff.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From matthias.eble at mailing.kaufland-informationssysteme.com Wed May 2 08:54:59 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Wed, 02 May 2007 08:54:59 +0200 Subject: [Nagiosplug-devel] Segfault in check_ping (need help fixing) In-Reply-To: <462D8750.7040109@aei.ca> References: <462D8750.7040109@aei.ca> Message-ID: <463835C3.6010606@mailing.kaufland-informationssysteme.com> Hi Thomas, I'm no C wizard also, but I'll try to send you my opinions since you've got no reply up to now. > > My two guesses are: > > 1) cmd == NULL. In some plugins I saw things such as > output = strdup (""); > [...] > asprintf (&output, ... > > Is this the RightThing(tm) to do? Could it be the cause? i think it depends on the situation. it should be fine here since From asprintf manpage: The functions asprintf() and vasprintf() are analogues of sprintf() and vsprintf(), except that they allocate a string large enough to hold the output including the terminating null byte, and return a pointer to it via the first parameter. This pointer should be passed to free(3) to release the allocated storage when it is no longer needed. if asprintf reallocs the space, both should be fine. if there is a malloc, i'd say, the empty string (but \0 terminated) would remain allocated but unused.. > > 2) mallos/realloc's > char **addresses = NULL; > [...] > addresses = malloc (sizeof(char*) * max_addr); > [...] > addresses = realloc (addresses, sizeof(char*) * max_addr); > > I understand the concept of malloc/realloc but when it comes to fancy > sizes I always get lost in pointers. Anyone skilled enough could verify > that these alloc enough memory? the realloc won't be called until multiple -H options are given.. so I thinks this is not the problem passing multiple -H args seems to be an undocumented feature though. If I understood the source right, the second,... hosts will only be pinged if the previous check was state unknown. > Since I cannot reproduce the segfault I can't test it, and the user > reporting this left. hmm.. that's bad. I have only a centos 5 box here at the moment.. hth matthias From ton.voon at altinity.com Wed May 2 09:14:21 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 2 May 2007 08:14:21 +0100 Subject: [Nagiosplug-devel] Prep for 1.4.9 In-Reply-To: <4635DB23.6050208@mailing.kaufland-informationssysteme.com> References: <22bc01c785f4$fb7417a6$249ca9ce@180solutions.com> <804160344192334BB21922E8082EA6C026749E@seaex01.180solutions.com> <4635DB23.6050208@mailing.kaufland-informationssysteme.com> Message-ID: <03619DC8-5CA5-46EA-A9D2-C39E285036FA@altinity.com> On 30 Apr 2007, at 13:03, Matthias Eble wrote: > i commited the test on saturday.. all tinderbox hosts except poseidon > passed 15/15 tests. poseidon shows: > > ./t/check_cluster....dubious > Test returned status 255 (wstat 65280, 0xff00) > > > in the log.. any suggestions? Good work guys. Unfortunately, the snapshot server is down at the moment and I won't be able to get the daily snapshots available until Friday, and with my limited availability, it is probably best to delay a new release until next week. I've also noticed that the gettext stuff doesn't appear to be installing correctly (I think this is the Makefile problem reported on the list), so I'll look at that before cutting. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Fri May 4 11:16:23 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 04 May 2007 11:16:23 +0200 Subject: [Nagiosplug-devel] check_disk -M/--mountpoint Message-ID: <463AF9E7.7020707@mailing.kaufland-informationssysteme.com> hi list, yesterday i spotted a (to me) misbehaviour of check disk when called with -M or --mountpoint help claims: Display the mountpoint instead of the partition but exactly the opposite is done. devices are listed: (!strcmp(me->me_mountdir, "none") || display_mntp) ? me->me_devname : me->me_mountdir so what shall we do now? i think this may be widely used and would break backward compatibility. any suggestions? matthias From kovzol at gmail.com Fri May 4 10:53:02 2007 From: kovzol at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_Kov=E1cs?=) Date: Fri, 4 May 2007 10:53:02 +0200 Subject: [Nagiosplug-devel] check_hpjd swallows non-standard ASCII characters Message-ID: Dear Developers, I started to use Nagios with the check_hpjd plugin in a production environment. Everything works well, I was even able to add some new OIDs to get additional information from the printers. The problem I noticed is that check_hpjd swallows international accented characters. The printers we use are set to Hungarian and we would like to show all messages in Nagios (of course) in Hungarian. The check_hpjd plugin converts e.g. "?" to ".", i.e. all non-standard ASCII characters are converted to a period. I would be very grateful if someone could help me how to fine tune this behaviour to preserve the accented letters in their original form. Thank you in advance, Zoltan Kovacs sysadmin -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.ekman at op5.se Fri May 4 16:45:41 2007 From: carl.ekman at op5.se (Carl Ekman) Date: Fri, 4 May 2007 16:45:41 +0200 Subject: [Nagiosplug-devel] !nrpe Message-ID: <200705041645.42216.carl.ekman@op5.se> Good day, I have encountered numerous clients having problem getting NRPE running on old unices, and don't in particular like having to install a complete build environment on for instance Mac OS X just to perform checks. So, I wrote a plugin that has the following purpose: Log on to the monitored host and perform commands that conform to the single unix specification, receive the data over SSH (or RSH) and parse it locally. I have attached a draft version of the plugin to this email, because I would be happy to receive some feedback on it. So, whomever might be interested in checking it out - please do so. Thanks!! Sincerely, Carl Ekman, op5 -- op5 AB Norgegatan 2 SE-164?32 Kista Tel: +46 733-70 90 21 Fax: +46 8-23 02 31 http://www.op5.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: check_unix Type: application/x-shellscript Size: 3628 bytes Desc: not available URL: From cmr at financial.com Fri May 4 19:12:39 2007 From: cmr at financial.com (Christoph Maser) Date: Fri, 04 May 2007 19:12:39 +0200 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <200705041645.42216.carl.ekman@op5.se> References: <200705041645.42216.carl.ekman@op5.se> Message-ID: <463B6987.6070707@financial.com> Carl its nice to see you did some work an want to share it. But you are reinventing the wheel. Nagios-plugins comes with check_by_ssh which does what you want. You also might also find "ssh framework" (http://neuntoeter.homelinux.org/wiki/index.php/Ssh_framework) helpful Chris Carl Ekman schrieb: > Good day, > > I have encountered numerous clients having problem getting NRPE running on old > unices, and don't in particular like having to install a complete build > environment on for instance Mac OS X just to perform checks. > > So, I wrote a plugin that has the following purpose: > > Log on to the monitored host and perform commands that conform to the single > unix specification, receive the data over SSH (or RSH) and parse it locally. > > I have attached a draft version of the plugin to this email, because I would > be happy to receive some feedback on it. > > So, whomever might be interested in checking it out - please do so. > > Thanks!! > > > Sincerely, > Carl Ekman, > op5 > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null -- financial.com AG Tel. +49 (0) 89 / 31 85 28 - 44 Maria-Probst-Str. 19 Fax. +49 (0) 89 / 31 85 28 - 28 D-80939 M?nchen http://www.financial.com/ From carl.ekman at op5.se Fri May 4 19:36:58 2007 From: carl.ekman at op5.se (Carl Ekman) Date: Fri, 4 May 2007 19:36:58 +0200 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <463B6987.6070707@financial.com> References: <200705041645.42216.carl.ekman@op5.se> <463B6987.6070707@financial.com> Message-ID: <200705041936.58797.carl.ekman@op5.se> Chris, thank you. However, I am aware of check_by_ssh, and it requires plugins to be present on the remote system. My intention is to have near zero client configuration for any unix client. ssh framework seems to be a similar idea, but still a bit more complex. I attach the latest version of my plugin, since I've been fixing a few bugs and added features since my last post. Sincerely, Carl Ekman On Friday 04 May 2007, Christoph Maser wrote: > Carl > > its nice to see you did some work an want to share it. But you are > reinventing the wheel. Nagios-plugins comes with check_by_ssh which does > what you want. You also might also find "ssh framework" > (http://neuntoeter.homelinux.org/wiki/index.php/Ssh_framework) helpful > > Chris > > Carl Ekman schrieb: > > Good day, > > > > I have encountered numerous clients having problem getting NRPE running > > on old unices, and don't in particular like having to install a complete > > build environment on for instance Mac OS X just to perform checks. > > > > So, I wrote a plugin that has the following purpose: > > > > Log on to the monitored host and perform commands that conform to the > > single unix specification, receive the data over SSH (or RSH) and parse > > it locally. > > > > I have attached a draft version of the plugin to this email, because I > > would be happy to receive some feedback on it. > > > > So, whomever might be interested in checking it out - please do so. > > > > Thanks!! > > > > > > Sincerely, > > Carl Ekman, > > op5 > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ------------------------------------------------------------------------ > > > > _______________________________________________________ > > Nagios Plugin Development Mailing List > > Nagiosplug-devel at lists.sourceforge.net Unsubscribe at > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null -- op5 AB Norgegatan 2 SE-164?32 Kista Tel: +46 733-70 90 21 Fax: +46 8-23 02 31 http://www.op5.se/ -------------- next part -------------- A non-text attachment was scrubbed... Name: check_unix Type: application/x-shellscript Size: 5211 bytes Desc: not available URL: From noreply at sourceforge.net Fri May 4 20:11:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 May 2007 11:11:52 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1712985 ] Make check_http post binary data Message-ID: Patches item #1712985, was opened at 2007-05-04 18:11 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=1712985&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: Unstable (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: T. Pascal (t_pascal) Assigned to: Nobody/Anonymous (nobody) Summary: Make check_http post binary data Initial Comment: This is a horrible hack to post binary data (passed as -P "URL-encoded bin data"). It works, but really needs to be fixed up to check the input and use proper libararies. I also need to hack it to allow a binary data search for the -s option (which I haven't done yet). T. Pascal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1712985&group_id=29880 From Thomas at zango.com Fri May 4 20:25:40 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 4 May 2007 11:25:40 -0700 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <200705041936.58797.carl.ekman@op5.se> References: <200705041645.42216.carl.ekman@op5.se><463B6987.6070707@financial.com> <200705041936.58797.carl.ekman@op5.se> Message-ID: <804160344192334BB21922E8082EA6C083DC0A@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Carl Ekman > Sent: May 4, 2007 13:37 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] !nrpe > > Chris, > > thank you. However, I am aware of check_by_ssh, and it > requires plugins to be > present on the remote system. > > My intention is to have near zero client configuration for > any unix client. > > ssh framework seems to be a similar idea, but still a bit > more complex. > > I attach the latest version of my plugin, since I've been > fixing a few bugs > and added features since my last post. What I'd do if I had time to work on that is to pipe PERL code to remote client as checks. You build a library of perl checks (You can get some that are already written or get them from various sources) then all you need is allow ssh to run Perl then pipe the code to the remote host then grab the result. Just my 2 canadian cents... Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From carl.ekman at op5.se Fri May 4 20:36:31 2007 From: carl.ekman at op5.se (Carl Ekman) Date: Fri, 4 May 2007 20:36:31 +0200 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <804160344192334BB21922E8082EA6C083DC0A@seaex01.180solutions.com> References: <200705041645.42216.carl.ekman@op5.se> <200705041936.58797.carl.ekman@op5.se> <804160344192334BB21922E8082EA6C083DC0A@seaex01.180solutions.com> Message-ID: <200705042036.31395.carl.ekman@op5.se> Thanks Thomas, sounds a bit like the fish kioslave for KDE file transfers then... I know from experience that it works very well, but my aim here is to be fairly strict with only requiring single unix specification/unix98/posix or similar for the monitored client... the real target is to work just as well with solaris 8 as with hp/ux, aix, 10 year old linux as with the latest and fanciest... I've run into stuff like how NRPE relies on gcc instead of for instance ANSI C and that messes things up with AIX native compiler... Just an example. Requiring perl would be a similar disadvantage. So, it's not what I want to do, but thank you very much for your input! Cheers, Carl Ekman On Friday 04 May 2007, Thomas Guyot-Sionnest wrote: > > -----Original Message----- > > From: nagiosplug-devel-bounces at lists.sourceforge.net > > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > > Behalf Of Carl Ekman > > Sent: May 4, 2007 13:37 > > To: Nagios Plugin Development Mailing List > > Subject: Re: [Nagiosplug-devel] !nrpe > > > > Chris, > > > > thank you. However, I am aware of check_by_ssh, and it > > requires plugins to be > > present on the remote system. > > > > My intention is to have near zero client configuration for > > any unix client. > > > > ssh framework seems to be a similar idea, but still a bit > > more complex. > > > > I attach the latest version of my plugin, since I've been > > fixing a few bugs > > and added features since my last post. > > What I'd do if I had time to work on that is to pipe PERL code to remote > client as checks. You build a library of perl checks (You can get some that > are already written or get them from various sources) then all you need is > allow ssh to run Perl then pipe the code to the remote host then grab the > result. > > Just my 2 canadian cents... > > Thomas -- op5 AB Norgegatan 2 SE-164?32 Kista Tel: +46 733-70 90 21 Fax: +46 8-23 02 31 http://www.op5.se/ From seanius at seanius.net Fri May 4 23:18:18 2007 From: seanius at seanius.net (sean finney) Date: Fri, 04 May 2007 23:18:18 +0200 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <200705041645.42216.carl.ekman@op5.se> References: <200705041645.42216.carl.ekman@op5.se> Message-ID: <1178313498.23120.14.camel@localhost> On Fri, 2007-05-04 at 16:45 +0200, Carl Ekman wrote: > I have encountered numerous clients having problem getting NRPE running on old > unices, and don't in particular like having to install a complete build > environment on for instance Mac OS X just to perform checks. i guess using a binary package is out of the question? :) > So, I wrote a plugin that has the following purpose: > > Log on to the monitored host and perform commands that conform to the single > unix specification, receive the data over SSH (or RSH) and parse it locally. > > I have attached a draft version of the plugin to this email, because I would > be happy to receive some feedback on it. this is pretty interesting though. i had been talking with some folks just a couple weeks ago about ways of monitoring remote hosts when you might not have the liberty of installing software (i.e. you have login rights but not admin rights and it would be "frowned upon" to go installing a daemon in your home dir). the method i had thought up was to take some of the existing "run this command and check output" commands and redefine the command to be "ssh host command", but that wasn't really generalizable without some serious hacking, and i think this is a better idea. for some feedback: it would be nice to have a list of these commands, and define an "endpoint script" which would take a command name (and maybe options) from stdin, and if it's in the list execute it. this way you could use ssh with a single keypair to execute commands. or maybe this would be more easily/properly done with a restricted bash shell or something. just off the top of my head anyway. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Sat May 5 04:20:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 May 2007 19:20:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1614168 ] 1.4.5 - not compatible w/ OpenSSL 0.9.8d Message-ID: Bugs item #1614168, was opened at 2006-12-12 09:40 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614168&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: alexus (a1exus) Assigned to: Thomas Guyot (dermoth) Summary: 1.4.5 - not compatible w/ OpenSSL 0.9.8d Initial Comment: gmake[2]: Entering directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L. -L/usr/local/ssl/lib -o check_http check_http.o sslutils.o netutils.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto gcc -g -O2 -o check_http check_http.o sslutils.o netutils.o utils.o -L/home/install/nagios/nagios-plugins-1.4.5/plugins -L/usr/local/ssl/lib ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl -lresolv -lssl -lcrypto /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x38): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xa0): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xc9): In function `dlfcn_load': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x13e): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x1f5): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x241): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2d5): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x321): In function `dlfcn_bind_func': : undefined reference to `dlerror' collect2: ld returned 1 exit status gmake[2]: *** [check_http] Error 1 gmake[2]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5/plugins' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/install/nagios/nagios-plugins-1.4.5' gmake: *** [all] Error 2 [root at localhost nagios-plugins-1.4.5]# ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-04 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-04-20 12:21 Message: Logged In: YES user_id=375623 Originator: NO I just realized my prod servers are all using openssl-0.9.8d and I I never had any trouble compiling OpenSSL (I compiled 1.4.6 to .8 on them and possibly 1.4.5 as well) Also: $ strings /usr/lib/libcrypto.a|grep dlopen dlopen I'm setting this bug to pending. Unless you can reproduce it on the latest release and provide me with more details on your distribution and where your ssl libraries came from this bug report will be closed. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1614168&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Sat May 5 18:24:31 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sat, 05 May 2007 18:24:31 +0200 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: References: Message-ID: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> Hi all, > If N::P is installed in the perl system libraries, no paths need > changing. If N::P is installed elsewhere, the perl plugins need to know > where to find N::P. I think Ton's proposal using FindBin is the only way to meet this need. I like it. > I think it comes down to two choices: > > 1. Expect N::P to be installed from an external mechanism, either > manually installed via CPAN, or using a OS specific package. We'd have > to make sure the Nagios Plugins requires these packages (amend various > spec files, update REQUIREMENTS file, etc) > > 2. Install N::P (and other dependent perl modules) in a (./configure > chosen) location. > > (1) is easier, though it pushes responsibility onto packagers. As N::P > and the perl scripts in Nagios Plugins are updated, there is a > dependency on packagers to make the newer version available for us to > require on. > > (2) is harder, though we would have control over what versions are > recommended. > > Ideally we need to support both, so that packagers can include only the > minimum software required for Nagios Plugins, but a "direct install" > case will still work for most users. > To me there is one reason to install N::P locally: CPAN setup. I don't want to download N::P+dependant modules to every host using cpan. We distribute the the plugins with rsync into a seperate directory (/opt/nagiosplug) Syncing stuff to /usr/lib/perl5 is not clean enough to me since it could overwrite a locally installed module, and as ton already said. > My proposal is this: > > ./configure has two new options: --enable-local-perl-modules, > --disable-local-perl-modules. The default is to search for N::P and > enable if not found or disable if found. > > --disable-local-perl-modules does nothing beyond current > > --enable-local-perl-modules will install N::P from a new top level > subdirectory I'm calling "nanocpan". In this directory is the tar file > from CPAN for N::P plus all the dependent perl modules. At make time, a > "perl Makefile.PL PREFIX=$prefix" (and some other options that I'm not > too sure of right now) and "make" will be run to compile all the > required perl modules - this will be recursive, so other dependent perl > modules will be included. At make install time, those perl modules will > be installed into, say, $prefix/lib. I'd prefer to call the flag "bundled-perl-modules" for clarity reasons. I'm not so familar with perl modules, so excuse the (maybe) dumb questions :) Is it really needed to build the perl modules during installation? And is it possible, that a module doesn't interpret the PREFIX flag "polluting" /usr/lib/perl5? Are there any dependencies caused by N::P up to now? matthias From kovzol at gmail.com Sun May 6 21:33:00 2007 From: kovzol at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_Kov=E1cs?=) Date: Sun, 6 May 2007 21:33:00 +0200 Subject: [Nagiosplug-devel] check_hpjd swallows non-standard ASCII characters In-Reply-To: References: Message-ID: Hi, I re-send this mail as a subscribed user. 2007/5/4, Zolt?n Kov?cs : > > Dear Developers, > > I started to use Nagios with the check_hpjd plugin in a production > environment. Everything works well, I was even able to add some new OIDs to > get additional information from the printers. > > The problem I noticed is that check_hpjd swallows international accented > characters. The printers we use are set to Hungarian and we would like to > show all messages in Nagios (of course) in Hungarian. The check_hpjd plugin > converts e.g. "?" to ".", i.e. all non-standard ASCII characters are > converted to a period. > > I would be very grateful if someone could help me how to fine tune this > behaviour to preserve the accented letters in their original form. > > Thank you in advance, > > Zoltan Kovacs > sysadmin > > -- matek.hu --- mert matekb?l ?retts?gizni mindenkinek kell... -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Sun May 6 21:39:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 12:39:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1564880 ] check_ping does not work! Message-ID: Bugs item #1564880, was opened at 2006-09-25 09:22 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: GriS (gristchyuk) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping does not work! Initial Comment: In version 1.4.3 check_ping does not work on RHEL 4 AS and RH 9.0. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-06 21:39 Message: Logged In: YES user_id=1694341 Originator: NO I guess this one should be set to pending.. ---------------------------------------------------------------------- Comment By: Alex Burger (alex_b) Date: 2006-10-09 15:10 Message: Logged In: YES user_id=85836 What exactly doesn't work? What is the output of check_ping on the command line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 From noreply at sourceforge.net Sun May 6 23:11:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 14:11:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1564880 ] check_ping does not work! Message-ID: Bugs item #1564880, was opened at 2006-09-25 03:22 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: GriS (gristchyuk) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping does not work! Initial Comment: In version 1.4.3 check_ping does not work on RHEL 4 AS and RH 9.0. ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-05-06 17:11 Message: Logged In: YES user_id=375623 Originator: NO This bug sat unanswered way too long - closing it! ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-06 15:39 Message: Logged In: YES user_id=1694341 Originator: NO I guess this one should be set to pending.. ---------------------------------------------------------------------- Comment By: Alex Burger (alex_b) Date: 2006-10-09 09:10 Message: Logged In: YES user_id=85836 What exactly doesn't work? What is the output of check_ping on the command line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 From noreply at sourceforge.net Mon May 7 08:17:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 23:17:36 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1564880 ] check_ping does not work! Message-ID: Bugs item #1564880, was opened at 2006-09-25 10:22 Message generated for change (Comment added) made by gristchyuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: GriS (gristchyuk) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping does not work! Initial Comment: In version 1.4.3 check_ping does not work on RHEL 4 AS and RH 9.0. ---------------------------------------------------------------------- >Comment By: GriS (gristchyuk) Date: 2007-05-07 09:17 Message: Logged In: YES user_id=1605903 Originator: YES In nagios-plugins-1.4.6 everything is ok. Thanks. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-05-07 00:11 Message: Logged In: YES user_id=375623 Originator: NO This bug sat unanswered way too long - closing it! ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-06 22:39 Message: Logged In: YES user_id=1694341 Originator: NO I guess this one should be set to pending.. ---------------------------------------------------------------------- Comment By: Alex Burger (alex_b) Date: 2006-10-09 16:10 Message: Logged In: YES user_id=85836 What exactly doesn't work? What is the output of check_ping on the command line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1564880&group_id=29880 From carl.ekman at op5.se Mon May 7 15:55:43 2007 From: carl.ekman at op5.se (Carl Ekman) Date: Mon, 7 May 2007 15:55:43 +0200 Subject: [Nagiosplug-devel] !nrpe In-Reply-To: <1178313498.23120.14.camel@localhost> References: <200705041645.42216.carl.ekman@op5.se> <1178313498.23120.14.camel@localhost> Message-ID: <200705071555.43363.carl.ekman@op5.se> Sean, > i guess using a binary package is out of the question? :) :) Hehe. Yes.... Maintaining a binary package for some every unix out there just is beyond the scope of this... > for some feedback: it would be nice to have a list of these commands, > and define an "endpoint script" which would take a command name (and > maybe options) from stdin, and if it's in the list execute it. this way > you could use ssh with a single keypair to execute commands. or maybe > this would be more easily/properly done with a restricted bash shell or > something. just off the top of my head anyway. Thanks! I'll look into that. I did run into some trouble when I found out that BSD ps really doesn't conform to anything but BSD ps, which I will have to sort out first though. Attached is the latest version. Sincerely, Carl Ekman -- op5 AB Norgegatan 2 SE-164?32 Kista Tel: +46 733-70 90 21 Fax: +46 8-23 02 31 http://www.op5.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: check_unix Type: application/x-shellscript Size: 8607 bytes Desc: not available URL: From noreply at sourceforge.net Tue May 8 04:20:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 19:20:17 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1703759 ] Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Message-ID: Bugs item #1703759, was opened at 2007-04-19 09:27 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nico Kadel-Garcia (nkadelgarcia) Assigned to: Ton Voon (tonvoon) Summary: Unnecessary ${SHELL} in INSTALL_STRIP_PROGRAM options Initial Comment: The presence in configure and configure.in of the unnecessary %{SHELL} means that attempts to use /usr/bin/install instead of install-sh fail miserably, and for no valid reason. The patch is below: diff -ur nagios-plugins-1.4.8/aclocal.m4 nagios-plugins-1.4.8.chmod/aclocal.m4 --- nagios-plugins-1.4.8/aclocal.m4 2007-04-11 08:11:58.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/aclocal.m4 2007-04-19 11:07:41.000000000 -0400 @@ -7158,7 +7158,7 @@ if test "$cross_compiling" != no; then AC_CHECK_TOOL([STRIP], [strip], :) fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" AC_SUBST([INSTALL_STRIP_PROGRAM])]) # Check how to create a tarball. -*- Autoconf -*- diff -ur nagios-plugins-1.4.8/configure nagios-plugins-1.4.8.chmod/configure --- nagios-plugins-1.4.8/configure 2007-04-11 08:12:37.000000000 -0400 +++ nagios-plugins-1.4.8.chmod/configure 2007-04-19 11:11:31.000000000 -0400 @@ -2007,7 +2007,7 @@ fi fi -INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s" +INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s" # We need awk for the "check" target. The system "awk" is bad on # some platforms. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-07 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-04-23 12:02 Message: Logged In: YES user_id=664364 Originator: NO Hi Nico, aclocal.m4 is generated by autoconf, and it looks like the section for INSTALL_STRIP_PROGRAM is outside of the control of the Nagios Plugins project. According to the information in aclocal.m4, it says: # Fortunately install-sh will honor a STRIPPROG variable, so we # always use install-sh in `make install-strip', and initialize # STRIPPROG with the value of the STRIP variable (set by the user). So it looks like install-sh is always used, but you can control the strip program by use of the STRIP env var. I've marked this call in PENDING because I don't think there's anything we can do about this. Ton ---------------------------------------------------------------------- Comment By: Nico Kadel-Garcia (nkadel) Date: 2007-04-19 17:50 Message: Logged In: YES user_id=923047 Originator: NO Dang. There are other fascinating little interactions, that interfere at least with installation as non-root users in various other ways. The DAG RPM's get around this by completely ignoring the "make install" option and doing it manually in the .spec files. It's a shame to have to do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1703759&group_id=29880 From noreply at sourceforge.net Tue May 8 11:51:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 02:51:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1714823 ] check_ups - -v parameter not working / needs documentation Message-ID: Bugs item #1714823, was opened at 2007-05-08 09:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1714823&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ask Bjoern Hansen (ask) Assigned to: Nobody/Anonymous (nobody) Summary: check_ups - -v parameter not working / needs documentation Initial Comment: ./check_ups --help says -v is [-v variable] and -v, --verbose Show details for command-line debugging (Nagios may truncate output) The detailed documentation talks about specifying a variable, so I am guessing the first version is correct. The information on what the variables are is missing though. ./check_ups -H localhost -u ups1 -T UPS OK - Status=Online Utility=113.0V Batt=100.0% Load=59.0% Temp=29.0C|voltage=113000mV;;;0 battery=100%;;;0;100 load=59%;;;0;100 temp=29degC;;;0 # ./check_ups -H localhost -u ups1 -T -v Temp check_ups: Unrecognized UPS variable - Temp Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] # ./check_ups -H localhost -u ups1 -T -v Batt check_ups: Unrecognized UPS variable - Batt Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] # ./check_ups -H localhost -u ups1 -T -v load check_ups: Unrecognized UPS variable - load Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1714823&group_id=29880 From ton.voon at altinity.com Tue May 8 14:49:29 2007 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 May 2007 13:49:29 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <20070428122558.GA14578@openfusion.com.au> References: <20070427100604.GA11042@openfusion.com.au> <0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com> <20070428122558.GA14578@openfusion.com.au> Message-ID: <1DF6135C-15DF-4129-84C4-B2D1F08FBF76@altinity.com> On 28 Apr 2007, at 13:25, Gavin Carr wrote: > Why? What's the advantage of not using the standard perl library > locations? > > N::P and every other module you're installing _are_ standard CPAN > modules, that out-of-the-box (perl Makefile.PL; make; make install) > install into the perl lib directories. You're having to jump through > extra hoops for them to _not_ install there, and then jump through > more hoops for your plugins to work because they aren't there. I > don't understand the rational/benefit of all that extra hoopage? > > I guess I'm seeing the benefit of bundling being not having to jump > through setting up the CPAN configuration stuff on every box you > want to use N::P on. It sounds like you're seeing the isolation itself > as being a benefit? I hadn't thought of it like this, but the isolation (or bundling of functionality) is, I think, a benefit because it allows easier installation on remote servers. And we already do "bundling"! The ./configure script, for instance, checks if getopt_log is available in the OS. If not, it statically links in the gnu version. If a target system has gnu upgraded (admitedly, a lot less likely than upgrading N::P), then the plugin will continue to work with the compiled in getopt_long. But the principle is the same - if the functionality is not available (on the build server), use a local copy instead. To me, the main advantage is that a plugin developer knows that certain functionality will always be available to them. A thought experiment: What about libmysqlclient? We could bundle libmysqlclient with Nagios Plugins - I don't think there are technical nor legal reasons that would stop us. This guarantees that check_mysql will compile as the dependencies will be there, thus overcoming the need to check for mysql in ./configure. But I'm pretty sure most people would think that's a silly idea - mysqlclient is (a) too big a piece of code to bundle, and (b) is not central to what the plugins is about. But N::P is on both counts, so I think merits bundling with the distribution. >> I haven't found the search path to be a problem. I guess lower >> versions of perl may pose a problem - I don't have a handle on this >> yet. There may need to be some extra work done there to support those >> lower levels. > > It's just a problem in the sense that the plugins won't work without > some explicit lib path tweaking. I dislike your FindBin/use lib code > on the grounds that it's only required to support a particular > deployment decision - you're polluting the plugins with installation > policy. (It would be much cleaner, for instance, to see if we can just > get PERL5LIB set in the environment if we do go this way). This is a worthwhile point. I see the whole "FindBin/use lib" code is analogous to adding $prefix/bin to the start of PATH. Yes, it is a deployment decision. The alternative of using PERL5LIB means that the setup is outside of the plugins code - maybe setup in NRPE and Nagios startup scripts or as a variable for the nagios user's profile? I guess this is no different to needing to use crle or LD_LIBRARY_PATH for ssl setup on some OSes. > I just think duplication is a bit like denormalising a database > schema - it's generally bad practice, but sometimes the benefits > make it worthwhile. Interesting analogy! However, I don't think there will be duplication - in most cases, I think an implementor would choose to either provide a local copy of the perl modules or install in system directories (I'm guessing that packagers will opt for the latter). From our point of view, we need to be able to support both. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Tue May 8 15:02:26 2007 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 May 2007 14:02:26 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> Message-ID: <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> On 5 May 2007, at 17:24, Matthias Eble wrote: >> My proposal is this: >> >> ./configure has two new options: --enable-local-perl-modules, >> --disable-local-perl-modules. The default is to search for N::P and >> enable if not found or disable if found. >> >> --disable-local-perl-modules does nothing beyond current >> >> --enable-local-perl-modules will install N::P from a new top level >> subdirectory I'm calling "nanocpan". In this directory is the tar >> file >> from CPAN for N::P plus all the dependent perl modules. At make >> time, a >> "perl Makefile.PL PREFIX=$prefix" (and some other options that I'm >> not >> too sure of right now) and "make" will be run to compile all the >> required perl modules - this will be recursive, so other dependent >> perl >> modules will be included. At make install time, those perl modules >> will >> be installed into, say, $prefix/lib. > I'd prefer to call the flag "bundled-perl-modules" for clarity > reasons. I agree that is clearer. > I'm not so familar with perl modules, so excuse the (maybe) dumb > questions :) > Is it really needed to build the perl modules during installation? Perl modules have a "perl Makefile.PL && make && make install" as equivalent to "configure && make && make install". I'm not entirely sure how we'd actually call it from the plugins yet. > And is it possible, that a module doesn't interpret the PREFIX flag > "polluting" /usr/lib/perl5? It is possible, but unlikely, as the perl module author would get flamed :) > Are there any dependencies caused by N::P up to now? It has some requirements to other perl modules (Params::Validate off top of head), but those would be bundled too. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From matthias.eble at mailing.kaufland-informationssysteme.com Tue May 8 15:21:35 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 08 May 2007 15:21:35 +0200 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> Message-ID: <4640795F.1020506@mailing.kaufland-informationssysteme.com> >> And is it possible, that a module doesn't interpret the PREFIX flag >> "polluting" /usr/lib/perl5? > > It is possible, but unlikely, as the perl module author would get > flamed :) ok :) >> Are there any dependencies caused by N::P up to now? > > It has some requirements to other perl modules (Params::Validate off > top of head), but those would be bundled too. Today, I set up N::P for testing purposes. And to me it was really annoying to resolve the dependencies (so my question was outdated a bit ) by hand since I cannot configure cpan to access the internet due to security policy. Without bundling I need to get either all the packages for every OS I'm running (if they even exist) or have to do the triathlon (perl Makefile.pl,make,make install) in addition to usual plugin compiling. So if you ask me, bundling is a must and to allow not bundled versions would be perfect. matthias From noreply at sourceforge.net Wed May 9 11:19:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 02:19:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1714823 ] check_ups - -v parameter not working / needs documentation Message-ID: Bugs item #1714823, was opened at 2007-05-08 11:51 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1714823&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Argument proccessing Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ask Bjoern Hansen (ask) >Assigned to: Matthias Eble (psychotrahe) Summary: check_ups - -v parameter not working / needs documentation Initial Comment: ./check_ups --help says -v is [-v variable] and -v, --verbose Show details for command-line debugging (Nagios may truncate output) The detailed documentation talks about specifying a variable, so I am guessing the first version is correct. The information on what the variables are is missing though. ./check_ups -H localhost -u ups1 -T UPS OK - Status=Online Utility=113.0V Batt=100.0% Load=59.0% Temp=29.0C|voltage=113000mV;;;0 battery=100%;;;0;100 load=59%;;;0;100 temp=29degC;;;0 # ./check_ups -H localhost -u ups1 -T -v Temp check_ups: Unrecognized UPS variable - Temp Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] # ./check_ups -H localhost -u ups1 -T -v Batt check_ups: Unrecognized UPS variable - Batt Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] # ./check_ups -H localhost -u ups1 -T -v load check_ups: Unrecognized UPS variable - load Usage:check_ups -H host -u ups [-p port] [-v variable] [-w warn_value] [-c crit_value] [-to to_sec] [-T] ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 11:19 Message: Logged In: YES user_id=1694341 Originator: NO Hi Ask, you are right, -v/--verbose is not used, so I commented it out in the --help screen. I also added -v/--variable to the --help page in cvs. The solution to your problem is to use one of these values for -v: LINE, TEMP, BATTPCT or LOADPCT. hth Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 11:19 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1714823&group_id=29880 From noreply at sourceforge.net Wed May 9 12:18:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 03:18:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1469472 ] check_ping dns lookup problem Message-ID: Bugs item #1469472, was opened at 2006-04-12 21:42 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping dns lookup problem Initial Comment: This is on 1.4.2. check_ping and maybe other plugins, first set their SIGARLM timeout and then do an unconditional dns lookup on the address provided, even if it is an IP. Besides the dns lookup on the IP address is useless to the best of my knowledge, it can timeout, which the code does not handle. If the dns lookup does time out, fileno(child_process) in popen_timeout_alarm_handler() will segfault. A simple workaround, which is BAD BAD BAD, is attached. The proper solution would be to rewrite this piece of code (and similar ones on other modules) to correctly deal with the dns timeout. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:18 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, i have tried to reproduce this one wich cvs and 1.4.2 version, without success. I'm also not shure what you exactly mean, since no dns request is made by check_ping itself (or at least i couldn't find it; doing so wouldn't make sense to mee). Check_ping is a wrapper for the ping command, which should make the dns requests if needed. It is likely that the ping command does a reverse lookup in your case, although this should not happen since ping should have been called with the -n argument. Does the problem persist? Matthias ---------------------------------------------------------------------- Comment By: Peter Beckman (ooglek) Date: 2006-08-08 20:25 Message: Logged In: YES user_id=68540 I agree, this isn't right, and it breaks all too often. +1 ---------------------------------------------------------------------- Comment By: Mark Hennessy (atxformfactor) Date: 2006-07-12 20:56 Message: Logged In: YES user_id=1554526 Why hasn't anyone picked this one up? I have noticed this issue as well. I get this message when DNS doesn't work due to a name server connection issue on the machine performing the Nagios checks: popen timeout received, but no child process All of my host entries are by IP, I don't see why check_ping should need to look up DNS for IPs at all. Someone should at least add a commandline switch or something. I may just have to write a perl wrapper for my local system's ping if nothing is done by anyone about this. :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 From noreply at sourceforge.net Wed May 9 12:19:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 03:19:22 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1469472 ] check_ping dns lookup problem Message-ID: Bugs item #1469472, was opened at 2006-04-12 21:42 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) >Assigned to: Matthias Eble (psychotrahe) Summary: check_ping dns lookup problem Initial Comment: This is on 1.4.2. check_ping and maybe other plugins, first set their SIGARLM timeout and then do an unconditional dns lookup on the address provided, even if it is an IP. Besides the dns lookup on the IP address is useless to the best of my knowledge, it can timeout, which the code does not handle. If the dns lookup does time out, fileno(child_process) in popen_timeout_alarm_handler() will segfault. A simple workaround, which is BAD BAD BAD, is attached. The proper solution would be to rewrite this piece of code (and similar ones on other modules) to correctly deal with the dns timeout. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:18 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, i have tried to reproduce this one wich cvs and 1.4.2 version, without success. I'm also not shure what you exactly mean, since no dns request is made by check_ping itself (or at least i couldn't find it; doing so wouldn't make sense to mee). Check_ping is a wrapper for the ping command, which should make the dns requests if needed. It is likely that the ping command does a reverse lookup in your case, although this should not happen since ping should have been called with the -n argument. Does the problem persist? Matthias ---------------------------------------------------------------------- Comment By: Peter Beckman (ooglek) Date: 2006-08-08 20:25 Message: Logged In: YES user_id=68540 I agree, this isn't right, and it breaks all too often. +1 ---------------------------------------------------------------------- Comment By: Mark Hennessy (atxformfactor) Date: 2006-07-12 20:56 Message: Logged In: YES user_id=1554526 Why hasn't anyone picked this one up? I have noticed this issue as well. I get this message when DNS doesn't work due to a name server connection issue on the machine performing the Nagios checks: popen timeout received, but no child process All of my host entries are by IP, I don't see why check_ping should need to look up DNS for IPs at all. Someone should at least add a commandline switch or something. I may just have to write a perl wrapper for my local system's ping if nothing is done by anyone about this. :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 From noreply at sourceforge.net Wed May 9 12:51:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 03:51:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1469472 ] check_ping dns lookup problem Message-ID: Bugs item #1469472, was opened at 2006-04-12 21:42 Message generated for change (Comment added) made by nsturm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Matthias Eble (psychotrahe) Summary: check_ping dns lookup problem Initial Comment: This is on 1.4.2. check_ping and maybe other plugins, first set their SIGARLM timeout and then do an unconditional dns lookup on the address provided, even if it is an IP. Besides the dns lookup on the IP address is useless to the best of my knowledge, it can timeout, which the code does not handle. If the dns lookup does time out, fileno(child_process) in popen_timeout_alarm_handler() will segfault. A simple workaround, which is BAD BAD BAD, is attached. The proper solution would be to rewrite this piece of code (and similar ones on other modules) to correctly deal with the dns timeout. ---------------------------------------------------------------------- >Comment By: nsturm (nsturm) Date: 2007-05-09 12:51 Message: Logged In: YES user_id=1323236 Originator: YES It looks as if popen_timeout_alarm_handler() and check_ping.c were rewritten to address these issues. From my point of view, the request can be closed. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:18 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, i have tried to reproduce this one wich cvs and 1.4.2 version, without success. I'm also not shure what you exactly mean, since no dns request is made by check_ping itself (or at least i couldn't find it; doing so wouldn't make sense to mee). Check_ping is a wrapper for the ping command, which should make the dns requests if needed. It is likely that the ping command does a reverse lookup in your case, although this should not happen since ping should have been called with the -n argument. Does the problem persist? Matthias ---------------------------------------------------------------------- Comment By: Peter Beckman (ooglek) Date: 2006-08-08 20:25 Message: Logged In: YES user_id=68540 I agree, this isn't right, and it breaks all too often. +1 ---------------------------------------------------------------------- Comment By: Mark Hennessy (atxformfactor) Date: 2006-07-12 20:56 Message: Logged In: YES user_id=1554526 Why hasn't anyone picked this one up? I have noticed this issue as well. I get this message when DNS doesn't work due to a name server connection issue on the machine performing the Nagios checks: popen timeout received, but no child process All of my host entries are by IP, I don't see why check_ping should need to look up DNS for IPs at all. Someone should at least add a commandline switch or something. I may just have to write a perl wrapper for my local system's ping if nothing is done by anyone about this. :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 From noreply at sourceforge.net Wed May 9 12:53:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 03:53:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1527980 ] check_mem.pl swaps used and free memory Message-ID: Bugs item #1527980, was opened at 2006-07-24 23:14 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1527980&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: Wont Fix Priority: 5 Private: No Submitted By: Dave Blunt (dblunt) >Assigned to: Matthias Eble (psychotrahe) Summary: check_mem.pl swaps used and free memory Initial Comment: The check_mem.pl script incorrectly pulls used and free memory from vmstat. It's reversed. The attached patch file fixes the problem. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:53 Message: Logged In: YES user_id=1694341 Originator: NO Hi Dave, thank you for your report. Unfortunately check_mem.pl is in the contrib directory and therefore not actively maintained by the nagiosplug-devel team. check_mem.pl relies on the position of vmstat output which can change from system to system or from release to release. On my suse 10.1 box, the total was not even calculated correctly. Maybe you want to give the check_mem plugin from nagiosExchange.org a try which relies on the `free` command. Yet I reviewed your note and think changing it would break compatibility for those users that might have been using it for long. Sorry about that Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1527980&group_id=29880 From noreply at sourceforge.net Wed May 9 12:58:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 03:58:15 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1469472 ] check_ping dns lookup problem Message-ID: Bugs item #1469472, was opened at 2006-04-12 21:42 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Matthias Eble (psychotrahe) Summary: check_ping dns lookup problem Initial Comment: This is on 1.4.2. check_ping and maybe other plugins, first set their SIGARLM timeout and then do an unconditional dns lookup on the address provided, even if it is an IP. Besides the dns lookup on the IP address is useless to the best of my knowledge, it can timeout, which the code does not handle. If the dns lookup does time out, fileno(child_process) in popen_timeout_alarm_handler() will segfault. A simple workaround, which is BAD BAD BAD, is attached. The proper solution would be to rewrite this piece of code (and similar ones on other modules) to correctly deal with the dns timeout. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:58 Message: Logged In: YES user_id=1694341 Originator: NO Thanks for the quick reply. closing it.. ---------------------------------------------------------------------- Comment By: nsturm (nsturm) Date: 2007-05-09 12:51 Message: Logged In: YES user_id=1323236 Originator: YES It looks as if popen_timeout_alarm_handler() and check_ping.c were rewritten to address these issues. From my point of view, the request can be closed. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-09 12:18 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, i have tried to reproduce this one wich cvs and 1.4.2 version, without success. I'm also not shure what you exactly mean, since no dns request is made by check_ping itself (or at least i couldn't find it; doing so wouldn't make sense to mee). Check_ping is a wrapper for the ping command, which should make the dns requests if needed. It is likely that the ping command does a reverse lookup in your case, although this should not happen since ping should have been called with the -n argument. Does the problem persist? Matthias ---------------------------------------------------------------------- Comment By: Peter Beckman (ooglek) Date: 2006-08-08 20:25 Message: Logged In: YES user_id=68540 I agree, this isn't right, and it breaks all too often. +1 ---------------------------------------------------------------------- Comment By: Mark Hennessy (atxformfactor) Date: 2006-07-12 20:56 Message: Logged In: YES user_id=1554526 Why hasn't anyone picked this one up? I have noticed this issue as well. I get this message when DNS doesn't work due to a name server connection issue on the machine performing the Nagios checks: popen timeout received, but no child process All of my host entries are by IP, I don't see why check_ping should need to look up DNS for IPs at all. Someone should at least add a commandline switch or something. I may just have to write a perl wrapper for my local system's ping if nothing is done by anyone about this. :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1469472&group_id=29880 From nagios at babar.us Wed May 9 13:01:22 2007 From: nagios at babar.us (Olivier Raginel) Date: Wed, 9 May 2007 13:01:22 +0200 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <4640795F.1020506@mailing.kaufland-informationssysteme.com> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4640795F.1020506@mailing.kaufland-informationssysteme.com> Message-ID: <20070509110121.GA5002@mail.babar.us> On Tue, May 08, 2007 at 03:21:35PM +0200, Matthias Eble wrote: > Today, I set up N::P for testing purposes. And to me it was really > annoying to resolve the dependencies (so my question was outdated a bit > ) by hand since I cannot configure cpan to access the internet due to > security policy. Hum, I agree, but disagree too. Yes, having to resolve dependencies by hand is harsh, but you'll have to do so for every CPAN module. Here, for N::P, when I tried it, I had to add: Test-Simple-0.67.tar.gz Params-Validate-0.88.tar.gz Class-Accessor-0.30.tar.gz So that's 3 packages to download manually. Then you have several ways. One is to install them on all your hosts (thus do something like: for host in YOUR HOST LIST;do for package in *.tar.gz;do scp $package $host: ssh $host "tar zxf $package && cd ${package%.tar.gz} && perl \ Makefile.PL && make make test && && su -c 'make install'" done done Or, if you want to have them only for Nagios, so install locally, you could simply copy the installed version (of course, this means all your hosts are of the same flavor of Unix, and some similar versions of perl. And in fact, looking at the dependencies, they're only .pm, so nothing fancy like C-modules, so they might work anywhere. Yes, I agree it's a bit of a pain, but honestly, it's not that hard to do. Oh and for the FindBin... Yes, it seems nice, but usually (correct me if I'm wrong), @INC contains . as the last entry, so launching your modules from the proper directory solves your PATH resolution. For example, I've installed all N::P and dependencies inside ~/Nagios-Plugin-0.15/lib: drwxr-xr-x 3 nagios nagios 4096 2007-03-13 18:22 Class drwxr-xr-x 3 nagios nagios 4096 2007-03-13 18:22 Nagios drwxr-xr-x 2 nagios nagios 4096 2007-03-13 18:23 Params drwxr-xr-x 5 nagios nagios 4096 2007-03-13 18:23 Test If I launch my plugins from there, doing something like ~/check_tomcat.pl, the perl script finds all my modules. Again, not sure it's the default behavior for perl. According to the documentation I found, "." is not appended if using taint mode: http://perldoc.perl.org/perlvar.html#@INC > Without bundling I need to get either all the packages for every OS I'm > running (if they even exist) or have to do the triathlon (perl > Makefile.pl,make,make install) in addition to usual plugin compiling. > So if you ask me, bundling is a must and to allow not bundled versions > would be perfect. Do you re-compile your plugins on all your hosts? If yes, for me, you ought to have to recompile all dependencies. Providing a lazy way to do it doesn't seem good to me. For now, dependencies are small and easy, but what will happen the day we'll want to add more complex modules, like ones using bites of C-code? I think Gavin and Patrick already expressed all I think on this topic, and as an admin having to install it on several machines too, I do think it's easier and more flexible to install the packages system-wide OR MANUALLY within the nagios plugin directory. What I do to replicate plugins is a simple rsync (in fact, tar cf - .| ssh tar xf -). Thus I can easily add anything I like within, and it will be replicated. Just my 2 cts, Kind regards, -- Olivier 'Babar' Raginel. From noreply at sourceforge.net Wed May 9 14:50:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 05:50:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1715686 ] check_disk_smb: Parameter -I to submit IP-address Message-ID: Patches item #1715686, was opened at 2007-05-09 14:50 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=1715686&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: romeofox (romeofox) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb: Parameter -I to submit IP-address Initial Comment: Sometimes the NETBIOS-Name of a host cannot resolved to a ip-address and therefor smbclient cannot connect to this host. Smbclient provides the option -I to submit a ip-address and this patch provide these option to check_disk_smb too. Even though there was already a patch with the Bug 1370031 I like to submit my own patch. It suits to nagios-plugins-1.4.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1715686&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Thu May 10 09:20:01 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Thu, 10 May 2007 09:20:01 +0200 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into the distribution In-Reply-To: <20070509110121.GA5002@mail.babar.us> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4640795F.1020506@mailing.kaufland-informationssysteme.com> <20070509110121.GA5002@mail.babar.us> Message-ID: <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> Olivier Raginel schrieb: > On Tue, May 08, 2007 at 03:21:35PM +0200, Matthias Eble wrote: >> Today, I set up N::P for testing purposes. And to me it was really >> annoying to resolve the dependencies (so my question was outdated a bit >> ) by hand since I cannot configure cpan to access the internet due to >> security policy. > > Hum, I agree, but disagree too. > Yes, having to resolve dependencies by hand is harsh, but you'll have to > do so for every CPAN module. Here, for N::P, when I tried it, I had to > add: > Test-Simple-0.67.tar.gz > Params-Validate-0.88.tar.gz > Class-Accessor-0.30.tar.gz Yes it were these three, but: Users try to install nagios plugins, not N::P which is a big difference to me. > So that's 3 packages to download manually. Then you have several ways. > One is to install them on all your hosts (thus do something like: > for host in YOUR HOST LIST;do > for package in *.tar.gz;do > scp $package $host: > ssh $host "tar zxf $package && cd ${package%.tar.gz} && perl \ > Makefile.PL && make make test && && su -c 'make install'" > done > done if one likes that, ok. I personally dislike placing files in directories except /opt and /usr/local without os packaging. OK sometimes it is needed, but requires good documentation. > And in fact, looking at the dependencies, they're only .pm, so nothing > fancy like C-modules, so they might work anywhere. Yes. Thats what I thought when I asked why they need to be build on compile time. But i guess this should be an approach capable of handling future requirements, too. And so compiling is the cleanest way to me. > Yes, I agree it's a bit of a pain, but honestly, it's not that hard to > do. I agree, too. > Oh and for the FindBin... Yes, it seems nice, but usually (correct me if > I'm wrong), @INC contains . as the last entry, so launching your modules > from the proper directory solves your PATH resolution. > For example, I've installed all N::P and dependencies inside > ~/Nagios-Plugin-0.15/lib: > drwxr-xr-x 3 nagios nagios 4096 2007-03-13 18:22 Class > drwxr-xr-x 3 nagios nagios 4096 2007-03-13 18:22 Nagios > drwxr-xr-x 2 nagios nagios 4096 2007-03-13 18:23 Params > drwxr-xr-x 5 nagios nagios 4096 2007-03-13 18:23 Test > > If I launch my plugins from there, doing something like > ~/check_tomcat.pl, the perl script finds all my modules. > Again, not sure it's the default behavior for perl. According to the > documentation I found, "." is not appended if using taint mode: > http://perldoc.perl.org/perlvar.html#@INC This will work as long as your working directory is the same. If the plugin is executed by nrpe, you will get problems - which is already the case for utils.pm. > Do you re-compile your plugins on all your hosts? > If yes, for me, you ought to have to recompile all dependencies. > Providing a lazy way to do it doesn't seem good to me. > For now, dependencies are small and easy, but what will happen the day > we'll want to add more complex modules, like ones using bites of C-code? I recompile them for every distro I am using. I'll have to compile all the modules, for these distros, too if bundling will not be implemented. With bundling compiling and distributing is one step. And users need to care whether their installed version of N::P fits together with the np distribution. > I think Gavin and Patrick already expressed all I think on this topic, > and as an admin having to install it on several machines too, I do think > it's easier and more flexible to install the packages system-wide OR > MANUALLY within the nagios plugin directory. Ton's approach of automatically compiling them in the np-prefix directory if N::P is not found in @INC is the best to me since i don't think it is ok to let all the users do these steps (set up cpan/search for binary packages/install by hand) having to care to get this large part of the plugins running. matthias From benoit.mortier at opensides.be Thu May 10 13:21:27 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Thu, 10 May 2007 13:21:27 +0200 Subject: [Nagiosplug-devel] CALL FOR PAPERS : monitoring day a the rmll 2007 Message-ID: <200705101321.33484.benoit.mortier@opensides.be> Hello, I'am the organizer of the monitoring day at the "rencontres mondiales du logiciel libre" who will be organized at Amiens France this year. The website is at http://www.rmll.info/?lang=en. The monitoring day is the 12 july 2007. I'am looking for speakers on free software like Nagios, Cacti and all addons existing. I'am also looking for testimonials of complex and mutliplatform monitoring. If you are interested in sharing your experiences you can write me in private Have a nice day -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From noreply at sourceforge.net Thu May 10 18:52:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 May 2007 09:52:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1523748 ] check_disk should error if warn range is subset of critical Message-ID: Bugs item #1523748, was opened at 2006-07-17 11:37 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) Summary: check_disk should error if warn range is subset of critical Initial Comment: the new se->w_idfp and se->c_idfp in version 1.4.3 are not initialized resulting in the following error (on HP-UX 11.23) check_disk -c 5% -w 10% -p /dev/vg00/lvol1 INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (64768802081573470261722606760322190900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /dev/vg00/lvol1 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] The following patch corrects this *** check_disk.c Mon Jul 17 11:32:26 2006 --- check_disk.c.good Mon Jul 17 11:32:03 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; ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-10 18:52 Message: Logged In: YES user_id=1694341 Originator: NO what do you mean with "consistency check"? matthias ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-07-17 17:46 Message: Logged In: YES user_id=780242 As the changes in CURRENT deleted every reference to w_idfp and c_idfp the error also disappears. Unfortunately the consistency check also dispappeared. Dick ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-17 12:27 Message: Logged In: YES user_id=664364 Dick, Can you try the snapshot at http://nagiosplug.sourceforge.net/snapshot. There have been fixes to check_disk recently. Please update if there is still a problem. I've marked the call in pending so it will autoclose in 7 days. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 From noreply at sourceforge.net Thu May 10 18:59:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 May 2007 09:59:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1652471 ] check_http is missing http Accept: header Message-ID: Feature Requests item #1652471, was opened at 2007-02-05 15:59 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1652471&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 Private: No Submitted By: Andreas Vavra (vavra) Assigned to: Nobody/Anonymous (nobody) Summary: check_http is missing http Accept: header Initial Comment: check_http is not sending an "Accept:" header when connecting to http servers. Please add something like /* Accept Header */ asprintf (&buf, "%sAccept: text/html\r\n",buf); in function check_http() in check_http.c somewhere after /* optionally send the host header info */ if (host_name) asprintf (&buf, "%sHost: %s\r\n", buf, host_name); If you can spend some more time on this plugin, optionally add a command line parameter to let caller set/override this option (i.e. for changing "Accept:" from "text/html" to "text/xml"). Regards Andi ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-10 18:59 Message: Logged In: YES user_id=1694341 Originator: NO Hi Andreas, I'm going to redirect this one to the feature request tracker since Accept isn't a mandatory field in http. You could add the Accept header by using -k. from --help: -k, --header=STRING Any other tags to be sent in http header. Use multiple times for additional headers I havent tried it yet, but it should work. However, to a test if the received document matches a specified mime type could make sense to me. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1652471&group_id=29880 From Thomas at zango.com Thu May 10 23:17:02 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 10 May 2007 14:17:02 -0700 Subject: [Nagiosplug-devel] Integrating Nagios::Plugininto the distribution In-Reply-To: <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4640795F.1020506@mailing.kaufland-informationssysteme.com><20070509110121.GA5002@mail.babar.us> <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> Message-ID: <804160344192334BB21922E8082EA6C08851C7@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Matthias Eble > Sent: May 10, 2007 3:20 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Integrating > Nagios::Plugininto the distribution > > Ton's approach of automatically compiling them in the np-prefix > directory if N::P is not found in @INC is the best to me > since i don't > think it is ok to let all the users do these steps (set up > cpan/search > for binary packages/install by hand) having to care to get this large > part of the plugins running. I'd personally compile it in the prefix directory by default, no matter what's in @INC. That would make a more consistent environment across the np user base which IMHO will help us in the long run. Ton, what's tour take on this? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From ton.voon at altinity.com Fri May 11 10:46:12 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 11 May 2007 09:46:12 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugininto the distribution In-Reply-To: <804160344192334BB21922E8082EA6C08851C7@seaex01.180solutions.com> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4640795F.1020506@mailing.kaufland-informationssysteme.com><20070509110121.GA5002@mail.babar.us> <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C08851C7@seaex01.180solutions.com> Message-ID: On 10 May 2007, at 22:17, Thomas Guyot-Sionnest wrote: > I'd personally compile it in the prefix directory by default, no > matter > what's in @INC. That would make a more consistent environment > across the np > user base which IMHO will help us in the long run. > > Ton, what's tour take on this? Looking back across this thread, I think almost everyone agrees we have to support installing N::P in a nagios dir for simple installation (as Matthias points out), and for sites which do not allow changes to system perl dirs (as John points out). The only dissenting opinion is from Gavin, because of duplication of N::P (local v system dirs) and making a deployment decision within code (by using FindBin). I'm not sure how to overcome the duplication, though a well managed system will have one or the other. If we clearly say a plugin prefers a local dir if it is there, that should make it clear which module is being used. The FindBin objection is hard to overcome too. Using PERL5LIB means more work for the user, setting up in various places (nagios user's profile on all monitored boxes, NRPE and Nagios start up scripts) - I can envisage more support calls coming from this decision. I'm not entirely convinced that using FindBin is that bad either - I think it is equivalent to using LD_RUN_PATH, which some Solaris people use to link to openssl (though admittedly, this is a decision they make at compile time, not always in the code at execution time). I guess we could have an option to strip out the "use lib" lines from the plugins at make time - would that be sufficient? I agree with Thomas that we always install N::P locally, though we provide configure switches to turn off. Is it fair to say we should proceed with the current plan? BTW, I saw a link to http://search.cpan.org/~adamk/Module- Install-0.65/lib/Module/Install/Bundle.pm which looks like it could provide the answer to the nanocpan idea - we create a bundle called Bundle::Nagios::Plugin which contains all the dependencies. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Sun May 13 14:30:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 May 2007 05:30:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1675306 ] [DHCP] Does not add mandatory 'end' option Message-ID: Bugs item #1675306, was opened at 2007-03-06 23:11 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675306&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Enrico Scholz (ensc) >Assigned to: Matthias Eble (psychotrahe) Summary: [DHCP] Does not add mandatory 'end' option Initial Comment: RFC 2131 states in 4.1 "Constructing and sending DHCP messages": | The last option must always be the 'end' option. The check-dhcp plugin does not add such an end (0xff) option. This might be rejected by DHCP servers/forwarders causing false positives. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-13 14:30 Message: Logged In: YES user_id=1694341 Originator: NO Hi Enrico, thanks for your report, it is fixed in cvs, now. Regards Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1675306&group_id=29880 From gavin at openfusion.com.au Mon May 14 06:01:13 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Mon, 14 May 2007 14:01:13 +1000 Subject: [Nagiosplug-devel] Integrating Nagios::Plugininto the distribution In-Reply-To: References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C08851C7@seaex01.180solutions.com> Message-ID: <20070514040113.GA15250@openfusion.com.au> On Fri, May 11, 2007 at 09:46:12AM +0100, Ton Voon wrote: > Looking back across this thread, I think almost everyone agrees we > have to support installing N::P in a nagios dir for simple > installation (as Matthias points out), and for sites which do not > allow changes to system perl dirs (as John points out). > > The only dissenting opinion is from Gavin, because of duplication of > N::P (local v system dirs) and making a deployment decision within > code (by using FindBin). > > I'm not sure how to overcome the duplication, though a well managed > system will have one or the other. If we clearly say a plugin prefers > a local dir if it is there, that should make it clear which module is > being used. > > The FindBin objection is hard to overcome too. Using PERL5LIB means > more work for the user, setting up in various places (nagios user's > profile on all monitored boxes, NRPE and Nagios start up scripts) - I > can envisage more support calls coming from this decision. I'm not > entirely convinced that using FindBin is that bad either - I think it > is equivalent to using LD_RUN_PATH, which some Solaris people use to > link to openssl (though admittedly, this is a decision they make at > compile time, not always in the code at execution time). I guess we > could have an option to strip out the "use lib" lines from the > plugins at make time - would that be sufficient? I guess so. Though adding the code in if you're using local perl modules seems cleaner. Maybe we just have something like this in the plugins: # use lib '/path/to/local/lib'; and uncomment and munge the lib path at install time? Is there benefit from doing a FindBin rather than just setting it lib outright? (Developers can just set PERL5LIB in their environments after all ...) > I agree with Thomas that we always install N::P locally, though we > provide configure switches to turn off. > > Is it fair to say we should proceed with the current plan? Sounds like it. > > BTW, I saw a link to http://search.cpan.org/~adamk/Module- > Install-0.65/lib/Module/Install/Bundle.pm which looks like it could > provide the answer to the nanocpan idea - we create a bundle called > Bundle::Nagios::Plugin which contains all the dependencies. Yes, the Module::Install stuff looks good, assuming we can point the install at a non-standard-lib install location. Cheers, Gavin From hasnainm at redrock.net.au Mon May 14 08:33:54 2007 From: hasnainm at redrock.net.au (Md Hasnain) Date: Mon, 14 May 2007 16:33:54 +1000 Subject: [Nagiosplug-devel] nagios external plugin for mysql Message-ID: Hi guyz, Do you know any plugin which will externally monitor mysql databases and send reports through email and smtpreceiver will receive it and purge it check if there is any problem in the database. Please let me know if you know any. Thanks in advance. Md. A Hasnain -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at elan.net Mon May 14 09:49:04 2007 From: william at elan.net (william(at)elan.net) Date: Mon, 14 May 2007 00:49:04 -0700 (PDT) Subject: [Nagiosplug-devel] nagios external plugin for mysql In-Reply-To: References: Message-ID: On Mon, 14 May 2007, Md Hasnain wrote: > Hi guyz, > > Do you know any plugin which will externally monitor mysql databases and > send reports through email and smtpreceiver will receive it and purge it > check if there is any problem in the database. Please let me know if you > know any. I'm unclear of what you're asking. Nagios already includes plugin for mysql and you should try using that and configure email reports through nagios. Personally I've written my own plugin in perl to check mysql which I use in part because it runs faster inside (with embedded perl) and because it also provides all the data from "SHOW STATUS" and allows to set warnings based on if something is out of balance there. You're welcome to try it, see http://william.leibzon.org/nagios/plugins/check_mysqld.pl (and if you want you maybe able to use it as base for custom perl daemon that checks mysql and emails). Also MySQL AB provides SQLNet as commercial application for those who buy mysql support - this is nagios-like monitoring system but entirely for purposes of checking on sql databases - its very comprehensive but if you have large install that maybe of interest to you, see http://www.mysql.com for more info. -- William Leibzon Elan Networks william at elan.net From hasnainm at redrock.net.au Mon May 14 09:11:43 2007 From: hasnainm at redrock.net.au (Md Hasnain) Date: Mon, 14 May 2007 17:11:43 +1000 Subject: [Nagiosplug-devel] nagios external plugin for mysql References: Message-ID: Hi William, Thank you so much for your reply. I am sorry I couldn't explain it to you properly. We have got some client we are monitoring them through Nagios. Those clients are not accessible through the net(like ping) so what we have done we cron some script into the client site which checks the box status and database issue and trigger an email to us where Nagios picks(our end) those emails and check the status information and alert us if something critical. For mailserver status it sends a email heartbeat(every 5 mins) to Nagios which has a refreshment check period which means if we don't receive any emails for certain mins it triggers a critical alert that heartbeat hasn't received(box down or mailserver down). We want some sort of scripts which will check every critical view of mysql(although I am not a mysql person) and send us email from the client end. From our end we will check the email through a postfix and perl script and submit a status info to Nagios to trigger alert. So I am looking for a script which will sit into external client in mysql server (under vpn) and send us alert accordingly. Thanks, Hasnain -----Original Message----- From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of william(at)elan.net Sent: Monday, 14 May 2007 5:49 PM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] nagios external plugin for mysql On Mon, 14 May 2007, Md Hasnain wrote: > Hi guyz, > > Do you know any plugin which will externally monitor mysql databases and > send reports through email and smtpreceiver will receive it and purge it > check if there is any problem in the database. Please let me know if you > know any. I'm unclear of what you're asking. Nagios already includes plugin for mysql and you should try using that and configure email reports through nagios. Personally I've written my own plugin in perl to check mysql which I use in part because it runs faster inside (with embedded perl) and because it also provides all the data from "SHOW STATUS" and allows to set warnings based on if something is out of balance there. You're welcome to try it, see http://william.leibzon.org/nagios/plugins/check_mysqld.pl (and if you want you maybe able to use it as base for custom perl daemon that checks mysql and emails). Also MySQL AB provides SQLNet as commercial application for those who buy mysql support - this is nagios-like monitoring system but entirely for purposes of checking on sql databases - its very comprehensive but if you have large install that maybe of interest to you, see http://www.mysql.com for more info. -- William Leibzon Elan Networks william at elan.net ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From william at elan.net Mon May 14 10:16:28 2007 From: william at elan.net (william(at)elan.net) Date: Mon, 14 May 2007 01:16:28 -0700 (PDT) Subject: [Nagiosplug-devel] nagios external plugin for mysql In-Reply-To: References: Message-ID: I think you need to look into using Nagios NSCA, see http://www.nagios.org/download/ When properly configured you'd have nagios plugins run on regular intervals (through cron) and use NSCA client to report their status back to nagios. On Mon, 14 May 2007, Md Hasnain wrote: > Hi William, > Thank you so much for your reply. I am sorry I couldn't explain it to > you properly. We have got some client we are monitoring them through > Nagios. Those clients are not accessible through the net(like ping) so > what we have done we cron some script into the client site which checks > the box status and database issue and trigger an email to us where > Nagios picks(our end) those emails and check the status information and > alert us if something critical. For mailserver status it sends a email > heartbeat(every 5 mins) to Nagios which has a refreshment check period > which means if we don't receive any emails for certain mins it triggers > a critical alert that heartbeat hasn't received(box down or mailserver > down). > We want some sort of scripts which will check every critical view of > mysql(although I am not a mysql person) and send us email from the > client end. From our end we will check the email through a postfix and > perl script and submit a status info to Nagios to trigger alert. > So I am looking for a script which will sit into external client in > mysql server (under vpn) and send us alert accordingly. > > Thanks, > Hasnain > > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of > william(at)elan.net > Sent: Monday, 14 May 2007 5:49 PM > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] nagios external plugin for mysql > > On Mon, 14 May 2007, Md Hasnain wrote: > >> Hi guyz, >> >> Do you know any plugin which will externally monitor mysql databases > and >> send reports through email and smtpreceiver will receive it and purge > it >> check if there is any problem in the database. Please let me know if > you >> know any. > > I'm unclear of what you're asking. Nagios already includes plugin > for mysql and you should try using that and configure email reports > through nagios. Personally I've written my own plugin in perl > to check mysql which I use in part because it runs faster inside > (with embedded perl) and because it also provides all the data > from "SHOW STATUS" and allows to set warnings based on if something > is out of balance there. You're welcome to try it, see > http://william.leibzon.org/nagios/plugins/check_mysqld.pl > (and if you want you maybe able to use it as base for custom perl > daemon that checks mysql and emails). Also MySQL AB provides SQLNet > as commercial application for those who buy mysql support - this is > nagios-like monitoring system but entirely for purposes of checking > on sql databases - its very comprehensive but if you have large > install that maybe of interest to you, see http://www.mysql.com > for more info. From hasnainm at redrock.net.au Mon May 14 09:45:33 2007 From: hasnainm at redrock.net.au (Md Hasnain) Date: Mon, 14 May 2007 17:45:33 +1000 Subject: [Nagiosplug-devel] nagios external plugin for mysql References: Message-ID: Thank you so much for that I will review it and I will let you know. Thanks, Hasnain -----Original Message----- From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of william(at)elan.net Sent: Monday, 14 May 2007 6:16 PM To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] nagios external plugin for mysql I think you need to look into using Nagios NSCA, see http://www.nagios.org/download/ When properly configured you'd have nagios plugins run on regular intervals (through cron) and use NSCA client to report their status back to nagios. On Mon, 14 May 2007, Md Hasnain wrote: > Hi William, > Thank you so much for your reply. I am sorry I couldn't explain it to > you properly. We have got some client we are monitoring them through > Nagios. Those clients are not accessible through the net(like ping) so > what we have done we cron some script into the client site which checks > the box status and database issue and trigger an email to us where > Nagios picks(our end) those emails and check the status information and > alert us if something critical. For mailserver status it sends a email > heartbeat(every 5 mins) to Nagios which has a refreshment check period > which means if we don't receive any emails for certain mins it triggers > a critical alert that heartbeat hasn't received(box down or mailserver > down). > We want some sort of scripts which will check every critical view of > mysql(although I am not a mysql person) and send us email from the > client end. From our end we will check the email through a postfix and > perl script and submit a status info to Nagios to trigger alert. > So I am looking for a script which will sit into external client in > mysql server (under vpn) and send us alert accordingly. > > Thanks, > Hasnain > > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On Behalf Of > william(at)elan.net > Sent: Monday, 14 May 2007 5:49 PM > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] nagios external plugin for mysql > > On Mon, 14 May 2007, Md Hasnain wrote: > >> Hi guyz, >> >> Do you know any plugin which will externally monitor mysql databases > and >> send reports through email and smtpreceiver will receive it and purge > it >> check if there is any problem in the database. Please let me know if > you >> know any. > > I'm unclear of what you're asking. Nagios already includes plugin > for mysql and you should try using that and configure email reports > through nagios. Personally I've written my own plugin in perl > to check mysql which I use in part because it runs faster inside > (with embedded perl) and because it also provides all the data > from "SHOW STATUS" and allows to set warnings based on if something > is out of balance there. You're welcome to try it, see > http://william.leibzon.org/nagios/plugins/check_mysqld.pl > (and if you want you maybe able to use it as base for custom perl > daemon that checks mysql and emails). Also MySQL AB provides SQLNet > as commercial application for those who buy mysql support - this is > nagios-like monitoring system but entirely for purposes of checking > on sql databases - its very comprehensive but if you have large > install that maybe of interest to you, see http://www.mysql.com > for more info. ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From ton.voon at altinity.com Mon May 14 10:05:09 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 14 May 2007 09:05:09 +0100 Subject: [Nagiosplug-devel] Integrating Nagios::Plugininto the distribution In-Reply-To: <20070514040113.GA15250@openfusion.com.au> References: <463CAFBF.7070602@mailing.kaufland-informationssysteme.com> <5FD3C940-B58E-4EF4-86F7-F159F0CDD1D8@altinity.com> <4642C7A1.6040804@mailing.kaufland-informationssysteme.com> <804160344192334BB21922E8082EA6C08851C7@seaex01.180solutions.com> <20070514040113.GA15250@openfusion.com.au> Message-ID: <68F4103E-A82A-416C-ABBD-ADB6FBE11257@altinity.com> On 14 May 2007, at 05:01, Gavin Carr wrote: > On Fri, May 11, 2007 at 09:46:12AM +0100, Ton Voon wrote: >> The FindBin objection is hard to overcome too. Using PERL5LIB means >> more work for the user, setting up in various places (nagios user's >> profile on all monitored boxes, NRPE and Nagios start up scripts) - I >> can envisage more support calls coming from this decision. I'm not >> entirely convinced that using FindBin is that bad either - I think it >> is equivalent to using LD_RUN_PATH, which some Solaris people use to >> link to openssl (though admittedly, this is a decision they make at >> compile time, not always in the code at execution time). I guess we >> could have an option to strip out the "use lib" lines from the >> plugins at make time - would that be sufficient? > > I guess so. Though adding the code in if you're using local perl > modules > seems cleaner. Maybe we just have something like this in the plugins: > > # use lib '/path/to/local/lib'; > > and uncomment and munge the lib path at install time? Is there benefit > from doing a FindBin rather than just setting it lib outright? > (Developers can just set PERL5LIB in their environments after all ...) That is starting to look a lot like the current utils.pm, which always seemed to give problems to the plugin scripts searching for this module. The advantage of FindBin is that N::P can be found relative to the script. This helps with cvs because, for instance, I have nagiosplug project checkout into ~/np, so the scripts exist in plugins-script and should be able to locate N::P as relative to this directory. Yes, you could use PERL5LIB, but then if you have to change this variable if you have differing versions of nagiosplug exported (I have a ~/np/ nagiosplug_r1.4 that I use for reference). So from a dev point of view, I think FindBin is better. I think this philosophically makes sense to strip it out at compile time, as we use other tools (autoconf, automake, *.in files) that are easier for developers, but then make changes for compile/install time. The other way of looking at it is that keeping it in doesn't cause problems if you do not install N::P locally, but if you forget to add it in, the perl plugins will fail. >> I agree with Thomas that we always install N::P locally, though we >> provide configure switches to turn off. >> >> Is it fair to say we should proceed with the current plan? > > Sounds like it. Excellent. I'll take a look at Module::Install::Bundle and see if we can create a bundle based on N::P to include in the dist. This will start after the 1.4.9 release. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Wed May 16 20:52:39 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 16 May 2007 19:52:39 +0100 Subject: [Nagiosplug-devel] SF tracker calls Message-ID: <0BEF11BF-ABA8-4218-8548-54293EDCE558@altinity.com> Hi! Just to let everyone know that Matthias has offered to go through the SF tracker items as we have so many that are still outstanding, but are probably not even relevant any more. Usually I ask for assigned items not to be touched without checking with the assigned person, but I think we should probably take the hit in protocol to get the number of items down. So I'll take the flak for any items that get missed. Hopefully we'll get a better picture of what's outstanding that really needs fixing. 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 17 16:24:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 May 2007 07:24:00 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1117643 ] Problems compiling 1.4 on Solaris 8 x86 Message-ID: Bugs item #1117643, was opened at 2005-02-07 03:52 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117643&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jeremy Russell (ellipses) Assigned to: M. Sean Finney (seanius) Summary: Problems compiling 1.4 on Solaris 8 x86 Initial Comment: make errored on compling check_icmp. ---------------------------------------------- gcc -g -O2 -L. -R/usr/local/ssl/lib -L/usr/local/ssl/lib -o check_icmp check_icmp.o ../intl/libintl.a -liconv -lgen - lsocket -I/usr/local/ssl/include Undefined first referenced symbol in file gethostbyname check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) inet_addr check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) inet_ntoa check_icmp.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) ld: fatal: Symbol referencing errors. No output written to check_icmp collect2: ld returned 1 exit status make[2]: *** [check_icmp] Error 1 make[2]: Leaving directory `/usr/local/support/src/monitor/nagios-plugins- 1.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/support/src/monitor/nagios-plugins-1.4' make: *** [all] Error 2 ------------------------------------------ gcc -v Reading specs from /usr/local/lib/gcc-lib/i386-pc- solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) edited plugins/Makefile # diff Makefile Makefile.orig 419c419 < check_icmp_LDADD = -lnsl --- > check_icmp_LDADD = attaching config.log ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-17 16:24 Message: Logged In: YES user_id=1694341 Originator: NO Hi Jeremy, Have you tried the cvs that time? I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:24 Message: Logged In: YES user_id=226838 hi, there exists code in the configure script which should find cases where -lnsl/-lsocket is needed, so i'm wondering why it's not working for you. could you try compiling from the latest cvs? if you still have the problem, could you post your config.log? ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-02-08 00:02 Message: Logged In: YES user_id=395628 Dear Jeremy, I am writing to thank you for opening a tracker about this problem, which appears to be Solaris specific. The developers advice is to add _both_ -lnsl and -lsocket for Solaris compiles. Since all the Makefiles for the plugins are generated by autoconf/automake, there needs to be Solaris specific mods made to configure.in and perhaps plugin/Makefile.am for this to please everyone. In the meantime, others should do as you have and manually add the extra libraries for Solaris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1117643&group_id=29880 From noreply at sourceforge.net Thu May 17 16:37:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 May 2007 07:37:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-822662 ] check_tcp does not return " TCP CRITICAL" Message-ID: Bugs item #822662, was opened at 2003-10-13 13:00 Message generated for change (Comment added) made by psychotrahe 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: Pending Resolution: None Priority: 5 Private: No 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: Matthias Eble (psychotrahe) Date: 2007-05-17 16:37 Message: Logged In: YES user_id=1694341 Originator: NO Hi Hugo, can you confirm that this problem still exists? I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: Chris Funderburg (funderburg) Date: 2005-05-19 14: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 18: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 17: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 17: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 15: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 13: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 Thu May 17 17:19:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 May 2007 08:19:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-853461 ] check_flexlm always reports OK Message-ID: Bugs item #853461, was opened at 2003-12-03 19:15 Message generated for change (Comment added) made by psychotrahe 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: Closed Resolution: None Priority: 5 Private: No 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: Matthias Eble (psychotrahe) Date: 2007-05-17 17:19 Message: Logged In: YES user_id=1694341 Originator: NO Hi Nico, I am going to close this case due to inactivity. If you finalized the patches, feel free to add tham to the "Patches" tracker. Regards Matthias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2004-11-24 01: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 10: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 16: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 16: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 Thu May 17 18:36:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 May 2007 09:36:22 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1144727 ] check_disk fails on Solaris with large available space Message-ID: Bugs item #1144727, was opened at 2005-02-20 11:44 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1144727&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: John-David Childs (diskmuncher) Assigned to: Ton Voon (tonvoon) Summary: check_disk fails on Solaris with large available space Initial Comment: check_disk returns a CRITICAL on Solaris (test 5.7 and 5.9) if a checked_filesystem actually has > 1TB of free space. This does NOT happen on Linux. Verifying functionality on IRIX. controldev [10:21am] plugins 69% df -k Filesystem kbytes used avail capacity Mounted on /proc 0 0 0 0% /proc /dev/dsk/c0t0d0s0 9075677 6666149 2318772 75% / fd 0 0 0 0% /dev/fd /dev/dsk/c0t0d0s4 482455 138924 295286 32% /var swap 1757696 79080 1678616 5% /tmp /dev/dsk/c0t0d0s6 6196234 6161 6128111 1% /ewrt /dev/dsk/c0t1d0s0 20652353 13923398 6522432 69% /bronze /dev/dsk/c0t1d0s1 20652353 4633312 15812518 23% /tools /dev/dsk/c0t1d0s4 29281179 23773695 5214673 83% /home opsnas1:/vol/home 1767421352 653768396 1113652956 37% /mnt controldev [10:23am] plugins 70% ./check_disk -w 10% -c 5% -e DISK CRITICAL - free space: /mnt 9007199254740993 MB (521854746624%);| /=6598MB;7975;8418;0;8862 /var=183MB;423;447;0;471 /tmp=77MB;1544;1630;0;1716 /ewrt=67MB;5445;5748;0;6051 /bronze=13799MB;18151;19159;0;20168 /tools=4727MB;18151;19159;0;20168 /home=23502MB;25734;27164;0;28594 /mnt=2735598MB;1553397;1639697;0;1725997 ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-17 18:36 Message: Logged In: YES user_id=1694341 Originator: NO Hi John-David, have you tried newer versions of the plugins which don't rely on df any more? Please post a comment if the problem persists. I'm setting this case to "pending" which means it will be closed automatically within 14 days if you won't post a reply until then. Best regards Matthias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 01:20 Message: Logged In: YES user_id=664364 John, Can you try this out with the latest snapshot at http://nagiosplug.sf.net/ snapshot please? There have been major changes to check_disk to sync it with coreutils' df command. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-28 04:23 Message: Logged In: YES user_id=226838 hi john, have you had the chance to look into this more? unfortunately i don't have access to a solaris system with > 1TB storage so my powers to debug are a bit diminished. i suspect some number may be truncated somewhere, either in check_disk.c (most likely) or fsusage.c (harder to read, but also less likely the source). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1144727&group_id=29880 From nathan.vonnahme at bannerhealth.com Thu May 17 21:09:43 2007 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 17 May 2007 11:09:43 -0800 Subject: [Nagiosplug-devel] Integrating Nagios::Plugin into thedistribution In-Reply-To: <1DF6135C-15DF-4129-84C4-B2D1F08FBF76@altinity.com> References: <20070427100604.GA11042@openfusion.com.au><0560541C-5BA4-4007-8ECF-36C853B63C1A@altinity.com><20070428122558.GA14578@openfusion.com.au> <1DF6135C-15DF-4129-84C4-B2D1F08FBF76@altinity.com> Message-ID: <077F1B782014ED48A58E7927914D36A0033E9B25@fai01500.bhs.bannerhealth.com> > But I'm pretty sure most people would think that's a silly idea - > mysqlclient is (a) too big a piece of code to bundle, and (b) is not > central to what the plugins is about. But N::P is on both counts, so > I think merits bundling with the distribution. Just to weigh in with my opinion - I think it's an acceptable approach to distribute a known-good bundle of libraries, so you can more effectively support one set of things. I deal with commercial software packages, both at the OS and application level, that even bundle their own Perl distribution so they can have a known, tested set of CPAN modules. For example, the AIX tool 'suma' relies on some CPAN modules, which all get installed in /opt from the AIX install media. One time I completely broke suma by upgrading a bunch of modules from CPAN. Of course IBM doesn't want to support my random modifications to CPAN, and I don't want to be tied to the frozen perl install in /opt, so I took the Perl 'configure' script's recommendation and installed my own perl in /usr/local. As unfortunate as the comparison is, libraries or Perl modules are really similar to DLL files, and packaging known-good DLLs with your application has long been one of the easier ways to avoid DLL hell. Relying on packaging / install / dependency systems like CPAN, RPM or Debian packages is better in a lot of ways, but I guess it depends on your target audience. I bet a lot of people who want to use Nagios plugins aren't Perl experts and don't necessarily want or need to learn how to configure CPAN and install modules just to get the plugins to work. From noreply at sourceforge.net Fri May 18 11:28:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 May 2007 02:28:37 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1070929 ] hpjdres Message-ID: Bugs item #1070929, was opened at 2004-11-22 12:17 Message generated for change (Comment added) made by psychotrahe 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: Closed Resolution: None Priority: 5 Private: No 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: Matthias Eble (psychotrahe) Date: 2007-05-18 11:28 Message: Logged In: YES user_id=1694341 Originator: NO Hi SupaFly, a long time has gone since the last post. Have you tried check_snmp_printer from the contrib directory? I'm going to close this item, since hp_jdres is not maintained by the plugin team and because this doesn't look like a general problem. Regards Matthias ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2004-12-01 07: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 12: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 09: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 13: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 12: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 12: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 04: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 01: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 Fri May 18 12:29:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 May 2007 03:29:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1215064 ] Documentation: Which plugins are available? Message-ID: Bugs item #1215064, was opened at 2005-06-05 09:43 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1215064&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Peer Janssen (peerjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation: Which plugins are available? Initial Comment: I'm trying to find documentation about which plugins are available. I spend some time browsing the web documentation and found much useful information -- wetting my appetite for this seemingly very nice framework --, but there seems to be no info about the available plugins, neither on the nagios site, nor on the nagios plugin site. Of course I could download the plugin package and take a look into whatever I would find in there. But a public list on the website would be nicer in order to make an informed decision ("executive summary" type) and, of course, for propaganda purposes. You may consider this a documentation bug or a wishlist item, whatever you prefer. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 12:29 Message: Logged In: YES user_id=1694341 Originator: NO Hi Peer, thanks for this great suggestion. I've created a faq entry at http://nagiosplugins.org/index.php?option=com_easyfaq&task=view&id=9&Itemid=29 Regards Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-06-05 19:50 Message: Logged In: YES user_id=226838 i don't think there is a single authoritative list of plugins available, but i think it would be a very useful thing to have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1215064&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Fri May 18 12:36:30 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 18 May 2007 12:36:30 +0200 Subject: [Nagiosplug-devel] List of plugins in the distribution Message-ID: <464D81AE.5050405@mailing.kaufland-informationssysteme.com> Hi all, I have created a list with all the plugins included in the distribution. It's in the faqs section of the new website: http://nagiosplugins.org/index.php?option=com_easyfaq&task=view&id=9&Itemid=29 So please, keep this list up to date if you add/remove plugins. Best Regards Matthias From noreply at sourceforge.net Fri May 18 13:14:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 May 2007 04:14:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by psychotrahe 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 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 13:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 15: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 06: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 20: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 19:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 09: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 00:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 19: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 11: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 11: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 11: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 11: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 10: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 10: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 09: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 09: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 03: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 10: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 11: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 21: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 19: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 18 14:08:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 May 2007 05:08:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1094326 ] check-ide-smart does not build Message-ID: Bugs item #1094326, was opened at 2005-01-02 04:53 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&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: Fixed Priority: 5 Private: No Submitted By: Reuben Farrelly (reuben) Assigned to: Benoit Mortier (opensides) Summary: check-ide-smart does not build Initial Comment: The .c file remains unbuilt in the plugins directory, after a build run: -rw-r--r-- 1 root root 11217 Dec 26 22:43 check_ide_smart.c Upon invoking 'make check_ide_smart', I then get a compile failure: [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:452: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:452: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:491: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here check_ide_smart.c: In function `print_usage': check_ide_smart.c:518: error: syntax error before ')' token make: *** [check_ide_smart.o] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 14:08 Message: Logged In: YES user_id=1694341 Originator: NO This plugin still/again does not build properly, beside the sata problem. make check_ide_smart works after some small changes.. will look at this later.. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-05 07:34 Message: Logged In: YES user_id=26209 Compiles clearly now, some other little problems, but this is progress ;-) 1. Does not get installed when running 'make install'. 2. Running without arguments just silently fails, it ought to output something, perhaps the output of ./check_ide_smart -h 3. Seems to be failing when run: [root at tornado plugins]# ./check_ide_smart -d /dev/sda CRITICAL - SMART_ENABLE: Inappropriate ioctl for device CRITICAL - SMART_CMD_ENABLE [root at tornado plugins]# [root at tornado plugins]# ./check_ide_smart -d /dev/sda -n CRITICAL - Couldn't open device: No such file or directory [root at tornado plugins]# I'm using SATA drives. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-04 01:18 Message: Logged In: YES user_id=388184 Hi, i just committed another fix in the cvs please try..and tell me..;-) ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-03 23:47 Message: Logged In: YES user_id=26209 Better, but still not quite there: [root at tornado plugins]# make check_ide_smart gcc -g -O2 -L. -L/usr/lib -o check_ide_smart check_ide_smart.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a -I/usr/include check_ide_smart.o(.text+0x87e): In function `main': /usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:222: undefined reference to `show_help' check_ide_smart.o(.text+0x883):/usr/src/nagios/nagiosplug/plugins/check_ide_smart.c:223: undefined reference to `show_version' collect2: ld returned 1 exit status make: *** [check_ide_smart] Error 1 [root at tornado plugins]# ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-03 02:38 Message: Logged In: YES user_id=388184 hi, i have corrected some more problems ;-) Could you just check this version out of cvs ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 21:29 Message: Logged In: YES user_id=26209 Still fails to build (but looks slightly better now) [root at tornado plugins]# make check_ide_smart if gcc -DLOCALEDIR=\"/usr/share/nagios/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/include -g -O2 -MT check_ide_smart.o -MD -MP -MF ".deps/check_ide_smart.Tpo" -c -o check_ide_smart.o check_ide_smart.c; \ then mv -f ".deps/check_ide_smart.Tpo" ".deps/check_ide_smart.Po"; else rm -f ".deps/check_ide_smart.Tpo"; exit 1; fi check_ide_smart.c:401: error: conflicting types for 'print_values' check_ide_smart.c:257: error: previous implicit declaration of 'print_values' was here check_ide_smart.c:451: error: conflicting types for 'smart_cmd_simple' check_ide_smart.c:451: note: an argument type that has a default promotion can't match an empty parameter name list declaration check_ide_smart.c:229: error: previous implicit declaration of 'smart_cmd_simple' was here check_ide_smart.c:490: error: conflicting types for 'print_help' check_ide_smart.c:203: error: previous implicit declaration of 'print_help' was here make: *** [check_ide_smart.o] Error 1 [root at tornado plugins] I'm using GCC 3.4.3 (Fedora Core 3) FWIW. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 19:37 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 15:04 Message: Logged In: YES user_id=388184 Hi, i have juste fixed the various errors, but i still need to check why it doesn't build with the others plugins.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1094326&group_id=29880 From noreply at sourceforge.net Fri May 18 14:30:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 May 2007 05:30:16 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1280470 ] check_procs cannot detect zombies on AIX Message-ID: Bugs item #1280470, was opened at 2005-09-02 11:35 Message generated for change (Comment added) made by illtiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs cannot detect zombies on AIX Initial Comment: ./check_procs -s Z -v Not parseable: Z 188558 98382 Not parseable: Z 196776 98382 PROCS OK: 0 processes with STATE = Z should return 2 zombies - AIX lists them as >> ps auxwww | egrep "USER|def" USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 188558 Z 0:00 root 196776 Z 0:00 >> ps -efal | egrep "UID|def" F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 50005 Z root 188558 98382 0 60 20 0:00 50005 Z root 196776 98382 0 60 20 0:00 ---------------------------------------------------------------------- Comment By: Felix Frank (illtiz) Date: 2007-05-18 14:30 Message: Logged In: YES user_id=249077 Originator: NO The described patch could also work around a problem I encountered with solars. Check procs would return correct states, but the output would be overwritten by warning messages of the form "Not parseable: Z 107 21841 0 0 - defunct [newline] defunct". I have had no opportunity to give it a try but the phenomenon appears to be quite common. ---------------------------------------------------------------------- Comment By: wszenajch (wszenajch) Date: 2006-10-17 13:34 Message: Logged In: YES user_id=1622130 For nagios-plugins-HEAD-200610152352 I have made the following correction to make this plugin working correctly with processes on AIX 5.2: In file check_procs.c find line: if ( cols == (expected_cols - 1) && strstr(procstat, zombie) ) { and replace it with the following: if ( cols < expected_cols && strstr(procstat, zombie) ) { On AIX 5.2 it works correctly reporting total number of processes (which was wrong before this change) and number of zombie processes when option '-s Z' is used. This change does not seem to affect Linux systems: I made brief tests with OpenSUSE10.1 i386, SuSE 10.0 x86_64 and SLES10 ia64; but other platforms i.e. Solaris should be tested before applying this change for production. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1280470&group_id=29880 From graham.collinson at googlemail.com Fri May 18 18:14:15 2007 From: graham.collinson at googlemail.com (Graham Collinson) Date: Fri, 18 May 2007 17:14:15 +0100 Subject: [Nagiosplug-devel] add returned content-type check to check_http Message-ID: <476ba3320705180914s4d23a639if582326c0272d94b@mail.gmail.com> Hi, I added an extra option to check_http for checking that the returned content-type is a certain value. The header check is based on the existing code for checking the date headers. Perhaps this would be useful to include? Attached are patches against 1.4.8 and latest cvs. I used -U for this option purely because it follows on from the -T used for passing content-type in outgoing headers. Perhaps a better letter can be picked from the few left available for this plugin. cheers, Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http.1.4.8.patch Type: application/octet-stream Size: 4398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http.cvs.patch Type: application/octet-stream Size: 4564 bytes Desc: not available URL: From noreply at sourceforge.net Sat May 19 15:42:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 May 2007 06:42:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-24 07: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 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 23:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 21:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 23: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 14: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 04: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 03:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 19: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 10:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 05: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 21: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 21: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 21: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 21: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 20: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 20: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 19: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 19: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 13: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 20: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 21: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 07: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 05: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 Sat May 19 17:18:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 May 2007 08:18:56 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1721843 ] check_by_ssh -C quoting documentation Message-ID: Patches item #1721843, was opened at 2007-05-19 17:18 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=1721843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Loic Dachary (loic) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh -C quoting documentation Initial Comment: The quoting rules of the -C argument of check_by_ssh are unusual and will mislead every system administrator unless properly documented. The attached patch adds a few lines in the usage help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1721843&group_id=29880 From noreply at sourceforge.net Sun May 20 16:35:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 May 2007 07:35:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: CVS Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-20 16:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I'm setting this one back to Resolution: None, because reuben's problem is reproducable using the cvs version for me. First i didn't get dhcpd to send a reply at all. That was caused by incorrect udp checksums which dhcpd didn't like. So I switched off checksum offloading in the network driver and finally came into reuben's situation. So I did some investigations and have following notes now: - problem encounters if check_dhcp is run from the same system serving dhcp - the select times out according to strace - offers are sent according to tcpdump/ethereal - dhcpcd-test works flawlessly - check_dhcp works on remote system The fact that select times out makes me think that no data actually arrives at the socket. If two servers are online, i get only the response from the remote server. One more thing I noticed is that dhcpcd-test sends discovers with source ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip the client doesn't even know - and cannot bind a socket on. I can't imagine how this works at all. Any hints? Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 15:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 13:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 15: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 06: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 20: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 19:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 09: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 00:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 19: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 11: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 11: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 11: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 11: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 10: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 10: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 09: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 09: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 03: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 10: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 11: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 21: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 19: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 Sun May 20 23:53:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 May 2007 14:53:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by loic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 23:53 Message: Logged In: YES user_id=1537 Originator: NO I experienced the problem today. On debian etch. I'm running check_dhcp and the dhcp server on the same interface. The dhcp server otherwise runs fine. strace /usr/lib/nagios/plugins/check_dhcp -s dhcp.dmz.tld -i eth2 ... read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0 mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c17000 mmap2(0xb7c2a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c2a000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c16000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c15000 mprotect(0xb7d57000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c156c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f04000, 8510) = 0 brk(0) = 0x804f000 brk(0x8070000) = 0x8070000 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth2\0\0\0\0\0\0\0\0\0\0\0\0\17\0\0\0\4\0\0\0\5\0\0\0$"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:13:72:40:39:0a}) = 0 time(NULL) = 1179697853 sendto(3, "\1\1\6\0b\\:\347\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1179697853]) = 1179697853 time([1179697853]) = 1179697853 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1179697855]) = 1179697855 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f06000 write(1, "CRITICAL: No DHCPOFFERs were rec"..., 39CRITICAL: No DHCPOFFERs were received. ) = 39 munmap(0xb7f06000, 4096) = 0 exit_group(2) = ? Process 15586 detached ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-20 16:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I'm setting this one back to Resolution: None, because reuben's problem is reproducable using the cvs version for me. First i didn't get dhcpd to send a reply at all. That was caused by incorrect udp checksums which dhcpd didn't like. So I switched off checksum offloading in the network driver and finally came into reuben's situation. So I did some investigations and have following notes now: - problem encounters if check_dhcp is run from the same system serving dhcp - the select times out according to strace - offers are sent according to tcpdump/ethereal - dhcpcd-test works flawlessly - check_dhcp works on remote system The fact that select times out makes me think that no data actually arrives at the socket. If two servers are online, i get only the response from the remote server. One more thing I noticed is that dhcpcd-test sends discovers with source ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip the client doesn't even know - and cannot bind a socket on. I can't imagine how this works at all. Any hints? Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 15:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 13:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 15: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 06: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 20: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 19:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 09: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 00:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 19: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 11: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 11: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 11: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 11: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 10: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 10: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 09: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 09: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 03: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 10: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 11: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 21: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 19: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 21 05:38:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 May 2007 20:38:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1722411 ] Huge BUG in check_disk Message-ID: Bugs item #1722411, was opened at 2007-05-20 19:38 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=1722411&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: hansm (hansm24) Assigned to: Nobody/Anonymous (nobody) Summary: Huge BUG in check_disk Initial Comment: I updated 59 servers and im not happy i did. i was thinking everything was working good but one disk was full. did forget to start on that server. Filesystem Size Used Avail Use% Mounted on /dev/sda2 32G 26G 4.9G 84% / /dev/sda1 99M 15M 79M 16% /boot none 1004M 0 1004M 0% /dev/shm [root at krusty (May 20 - 11:37pm) - /usr/local/nagios/libexec] ./check_disk -w10% -c5% -p / DISK OK - free space: / 4918 MB (15% inode=97%);| /=25825MB;29150;30769;0;32389 always disk OK and in the meantime its almost full. how can i solve this? THIS IS URGENT!!! And im sure another people agree on that. Disk Status is one of the most urgent things. i hope this can be fixed ASAP!!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&group_id=29880 From noreply at sourceforge.net Mon May 21 05:39:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 May 2007 20:39:03 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1722411 ] Huge BUG in check_disk Message-ID: Bugs item #1722411, was opened at 2007-05-20 19:38 Message generated for change (Settings changed) made by hansm24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&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: 9 Private: No Submitted By: hansm (hansm24) Assigned to: Nobody/Anonymous (nobody) Summary: Huge BUG in check_disk Initial Comment: I updated 59 servers and im not happy i did. i was thinking everything was working good but one disk was full. did forget to start on that server. Filesystem Size Used Avail Use% Mounted on /dev/sda2 32G 26G 4.9G 84% / /dev/sda1 99M 15M 79M 16% /boot none 1004M 0 1004M 0% /dev/shm [root at krusty (May 20 - 11:37pm) - /usr/local/nagios/libexec] ./check_disk -w10% -c5% -p / DISK OK - free space: / 4918 MB (15% inode=97%);| /=25825MB;29150;30769;0;32389 always disk OK and in the meantime its almost full. how can i solve this? THIS IS URGENT!!! And im sure another people agree on that. Disk Status is one of the most urgent things. i hope this can be fixed ASAP!!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&group_id=29880 From noreply at sourceforge.net Mon May 21 07:46:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 May 2007 22:46:22 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1722411 ] Huge BUG in check_disk Message-ID: Bugs item #1722411, was opened at 2007-05-21 05:38 Message generated for change (Comment added) made by hendrikb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&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: 9 Private: No Submitted By: hansm (hansm24) Assigned to: Nobody/Anonymous (nobody) Summary: Huge BUG in check_disk Initial Comment: I updated 59 servers and im not happy i did. i was thinking everything was working good but one disk was full. did forget to start on that server. Filesystem Size Used Avail Use% Mounted on /dev/sda2 32G 26G 4.9G 84% / /dev/sda1 99M 15M 79M 16% /boot none 1004M 0 1004M 0% /dev/shm [root at krusty (May 20 - 11:37pm) - /usr/local/nagios/libexec] ./check_disk -w10% -c5% -p / DISK OK - free space: / 4918 MB (15% inode=97%);| /=25825MB;29150;30769;0;32389 always disk OK and in the meantime its almost full. how can i solve this? THIS IS URGENT!!! And im sure another people agree on that. Disk Status is one of the most urgent things. i hope this can be fixed ASAP!!! ---------------------------------------------------------------------- Comment By: Hendrik B?cker (hendrikb) Date: 2007-05-21 07:46 Message: Logged In: YES user_id=906410 Originator: NO Hey Hans, URGENT or not, IMHO if you tell check_disk that you want to have a warning on 10% free disk space and a critical on 5% of free disk space and if you have 16% of free disk space all is OK. See: check_disk --help for this: -w, --warning=INTEGER Exit with WARNING status if less than INTEGER --units of disk are free -w, --warning=PERCENT% Exit with WARNING status if less than PERCENT of disk space is free -c, --critical=INTEGER Exit with CRITICAL status if less than INTEGER --units of disk are free -c, --critical=PERCENT% Exit with CRITCAL status if less than PERCENT of disk space is free ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&group_id=29880 From jimm at simutronics.com Fri May 18 20:51:51 2007 From: jimm at simutronics.com (James Miller) Date: Fri, 18 May 2007 13:51:51 -0500 Subject: [Nagiosplug-devel] check_tcp does not intercept Unicode responses Message-ID: <038901c7997d$98b5ee10$5dd810d1@e3demo> Hello everyone I have an app I want to watch using the check_tcp plug-in. The issue is the app sends it responses in Unicode and check_tcp doesn't seem to know how to interpret the response. It sees the first I in the response, quits reading the rest of the response after it see the first '\0' and it thinks the service is UP. The command I run is (from the command line: ./check_tcp -v -H -p -s $'ISWORLDUP\t2025\n' -e $'I\0S\0W\0R\0L\0D\0U\0P\0\t\0Y\0E\0S\0\n' Using service TCP Port: 0 flags: 0x2 server_expect_count: 1 0: I received 27 bytes from host #-raw-recv-------# I #-raw-recv-------# looking for [I] anywhere in [I] found it TCP OK - 0.162 second response time on port 49276 [I]|time=0.161719s;0.000000;0.000000;0.000000;10.000000 When a 'world is down' the response is "ISWORLDUP NO" or in Unicode "I\0S\0W\0O\0R\0L\0D\0U\0P\0\t\0N\0O\n" Here's an example from strace if I telnet to the app and check to see if the world is UP: read(0, "ISWORLDUP\t2025\n", 8160) = 15 select(4, [0 3], [3], [3], {0, 0}) = 1 (out [3], left {0, 0}) send(3, "ISWORLDUP\t2025\n", 15, 0) = 15 select(4, [0 3], [], [3], {0, 0}) = 0 (Timeout) select(4, [0 3], [], [3], NULL) = 1 (in [3]) recv(3, "I\0S\0W\0O\0R\0L\0D\0U\0P\0\t\0Y\0E\0S\0\n", 8142, 0) = 27 select(4, [0 3], [1], [3], {0, 0}) = 1 (out [1], left {0, 0}) write(1, "I\0S\0W\0O\0R\0L\0D\0U\0P\0\t\0Y\0E\0S\0\n", 27ISWORLDUP YES ) = 27 select(4, [0 3], [], [3], {0, 0}) = 0 (Timeout) select(4, [0 3], [], [3], NULL I was hoping someone might have some insight to this issue. Thanks, Jim James Miller - MCSE RHCE CISSP Sr Systems & Network Administrator Simutronics Corp. www.play.net 636.946.4263 x113 From spkane at mac.com Fri May 18 20:52:00 2007 From: spkane at mac.com (Sean Kane) Date: Fri, 18 May 2007 11:52:00 -0700 Subject: [Nagiosplug-devel] Added Reverse Lookup to check_dig Message-ID: <92FF7D30-E3F0-4DDC-B5DC-70C90527456E@mac.com> I have had a pretty significant need for being able to do reverse lookup queries via Nagios to ensure that the PTR records are setup correctly. At the command line I would use "dig -x", but was disappointed to find out that check_dig did not support this, so I wrote this quick patch to make the functionality work. There are likely improvements that can be made, but this is working for me. I hope you will consider using it a future release. I am not a member of the list, so please write to me directly if you respond. Thanks, Sean --- check_dig.c 2007-01-28 21:46:40.000000000 +0000 +++ check_dig_reverse.c 2007-05-18 18:40:03.000000000 +0000 @@ -38,8 +38,8 @@ * because on some architectures those strings are in non-writable memory */ const char *progname = "check_dig"; -const char *revision = "$Revision: 1.46 $"; -const char *copyright = "2002-2006"; +const char *revision = "$Revision: 1.461 $"; +const char *copyright = "2002-2007"; const char *email = "nagiosplug-devel at lists.sourceforge.net"; #include "common.h" @@ -57,6 +57,7 @@ char *query_address = NULL; char *record_type = "A"; +char *reverse_query = NULL; char *expected_address = NULL; char *dns_server = NULL; int verbose = FALSE; @@ -89,8 +90,8 @@ usage_va(_("Could not parse arguments")); /* get the command to run */ - asprintf (&command_line, "%s @%s -p %d %s -t %s", - PATH_TO_DIG, dns_server, server_port, query_address, record_type); + asprintf (&command_line, "%s @%s -p %d %s %s -t %s", + PATH_TO_DIG, dns_server, server_port, reverse_query, query_address, record_type); alarm (timeout_interval); gettimeofday (&tv, NULL); @@ -193,6 +194,7 @@ {"critical", required_argument, 0, 'c'}, {"timeout", required_argument, 0, 't'}, {"verbose", no_argument, 0, 'v'}, + {"reverse_query", no_argument, 0, 'x'}, {"version", no_argument, 0, 'V'}, {"help", no_argument, 0, 'h'}, {"record_type", required_argument, 0, 'T'}, @@ -205,7 +207,7 @@ return ERROR; while (1) { - c = getopt_long (argc, argv, "hVvt:l:H:w:c:T:p:a:", longopts, &option); + c = getopt_long (argc, argv, "hVvxt:l:H:w:c:T:p:a:", longopts, &option); if (c == -1 || c == EOF) break; @@ -262,6 +264,10 @@ case 'T': record_type = optarg; break; + case 'x': /* reverse_lookup */ + reverse_query = "-x"; + record_type = "PTR"; + break; case 'a': expected_address = optarg; break; @@ -304,6 +310,7 @@ print_revision (progname, revision); printf ("Copyright (c) 2000 Karl DeBisschop \n"); + printf ("Reverse Lookup Modifications by: Sean P. Kane \n"); printf (COPYRIGHT, copyright, email); printf (_("This plugin test the DNS service on the specified host using dig")); @@ -320,6 +327,8 @@ printf (" %s\n",_("machine name to lookup")); printf (" %s\n","-T, --record_type=STRING"); printf (" %s\n",_("record type to lookup (default: A)")); + printf (" %s\n","-x, --reverse_query"); + printf (" %s\n",_("perform reverse lookup")); printf (" %s\n","-a, --expected_address=STRING"); printf (" %s\n",_("an address expected to be in the answer section.if not set, uses whatever was in -l")); printf (_(UT_WARN_CRIT)); @@ -336,5 +345,5 @@ printf (_("Usage:")); printf ("%s -H host -l lookup [-p ] [-T ]", progname); printf (" [-w ] [-c ] [-t ]"); - printf (" [-a ] [-v]\n"); + printf (" [-a ] [-v] [-x]\n"); } From noreply at sourceforge.net Mon May 21 12:06:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 May 2007 03:06:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1722411 ] Huge BUG in check_disk Message-ID: Bugs item #1722411, was opened at 2007-05-21 05:38 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&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: Invalid >Priority: 1 Private: No Submitted By: hansm (hansm24) Assigned to: Nobody/Anonymous (nobody) Summary: Huge BUG in check_disk Initial Comment: I updated 59 servers and im not happy i did. i was thinking everything was working good but one disk was full. did forget to start on that server. Filesystem Size Used Avail Use% Mounted on /dev/sda2 32G 26G 4.9G 84% / /dev/sda1 99M 15M 79M 16% /boot none 1004M 0 1004M 0% /dev/shm [root at krusty (May 20 - 11:37pm) - /usr/local/nagios/libexec] ./check_disk -w10% -c5% -p / DISK OK - free space: / 4918 MB (15% inode=97%);| /=25825MB;29150;30769;0;32389 always disk OK and in the meantime its almost full. how can i solve this? THIS IS URGENT!!! And im sure another people agree on that. Disk Status is one of the most urgent things. i hope this can be fixed ASAP!!! ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-21 12:06 Message: Logged In: YES user_id=1694341 Originator: NO hi hans, as hendrik already described.. everything is fine - at least if the output is from the problem host. check_disk thresholds are *Free Space* thresholds, so if fhere is more free space than -w/-c everything is fine. Matthias ---------------------------------------------------------------------- Comment By: Hendrik B?cker (hendrikb) Date: 2007-05-21 07:46 Message: Logged In: YES user_id=906410 Originator: NO Hey Hans, URGENT or not, IMHO if you tell check_disk that you want to have a warning on 10% free disk space and a critical on 5% of free disk space and if you have 16% of free disk space all is OK. See: check_disk --help for this: -w, --warning=INTEGER Exit with WARNING status if less than INTEGER --units of disk are free -w, --warning=PERCENT% Exit with WARNING status if less than PERCENT of disk space is free -c, --critical=INTEGER Exit with CRITICAL status if less than INTEGER --units of disk are free -c, --critical=PERCENT% Exit with CRITCAL status if less than PERCENT of disk space is free ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&group_id=29880 From dermoth at aei.ca Wed May 23 09:43:21 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 23 May 2007 03:43:21 -0400 Subject: [Nagiosplug-devel] German translation errors? Message-ID: <4653F099.8040906@aei.ca> I don't speak German at all, but those strings looks obviously wrong: #: plugins/check_smtp.c:398 #, fuzzy msgid "recv() failed after AUTH LOGIN, " msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" #: plugins/check_smtp.c:404 plugins/check_smtp.c:426 plugins/check_smtp.c:447 #, fuzzy, c-format msgid "received %s\n" msgstr "Keine Daten empfangen %s\n" #: plugins/check_smtp.c:408 #, fuzzy msgid "invalid response received after AUTH LOGIN, " msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" #: plugins/check_smtp.c:430 #, fuzzy msgid "invalid response received after authuser, " msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" #: plugins/check_smtp.c:451 #, fuzzy msgid "invalid response received after authpass, " msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" I found that while looking at the translations after changing some strings in check_http... Thomas From andurin at process-zero.de Wed May 23 09:48:43 2007 From: andurin at process-zero.de (Hendrik Baecker) Date: Wed, 23 May 2007 09:48:43 +0200 Subject: [Nagiosplug-devel] German translation errors? In-Reply-To: <4653F099.8040906@aei.ca> References: <4653F099.8040906@aei.ca> Message-ID: <4653F1DB.9080808@process-zero.de> Hi Thomas, yes - miles away from the truth ;) Thomas Guyot-Sionnest schrieb: > I don't speak German at all, but those strings looks obviously wrong: > > #: plugins/check_smtp.c:398 > #, fuzzy > msgid "recv() failed after AUTH LOGIN, " > msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" > "Nach AUTH LOGIN keine Daten erhalten" (Got no data after AUTH LOGIN) > #: plugins/check_smtp.c:404 plugins/check_smtp.c:426 > plugins/check_smtp.c:447 > #, fuzzy, c-format > msgid "received %s\n" > msgstr "Keine Daten empfangen %s\n" > "%s (bytes?) Daten empfangen" > #: plugins/check_smtp.c:408 > #, fuzzy > msgid "invalid response received after AUTH LOGIN, " > msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" > "Ung?ltige Antwort nach AUTH LOGIN" > #: plugins/check_smtp.c:430 > #, fuzzy > msgid "invalid response received after authuser, " > msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" > "Ung?ltige Antwort nach AUTH USER" > #: plugins/check_smtp.c:451 > #, fuzzy > msgid "invalid response received after authpass, " > msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" > "Ung?ltige Antwort nach AUTH PASS" > I found that while looking at the translations after changing some > strings in check_http... > > Thomas > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > From noreply at sourceforge.net Wed May 23 12:27:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 May 2007 03:27:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1724052 ] check_dns: sort address data Message-ID: Patches item #1724052, was opened at 2007-05-23 12:27 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=1724052&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Urlichs (smurf) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns: sort address data Initial Comment: DNs reports multiple addresses in random order. Therefore, sort them (for checking with "-a"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1724052&group_id=29880 From noreply at sourceforge.net Wed May 23 12:29:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 May 2007 03:29:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1724055 ] check_dns: does not sort address data Message-ID: Bugs item #1724055, was opened at 2007-05-23 12: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=1724055&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Urlichs (smurf) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns: does not sort address data Initial Comment: DNS reports adreses in random order. Therefore, the "-a" option to check_dns, which is supposed to verify that the data returned is what's expected, is worse than useless for multi-homed systems. Patch 1724052 has a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1724055&group_id=29880 From stephane.urbanovski at ac-nancy-metz.fr Wed May 23 16:33:47 2007 From: stephane.urbanovski at ac-nancy-metz.fr (=?UTF-8?B?U3TDqXBoYW5lIFVyYmFub3Zza2k=?=) Date: Wed, 23 May 2007 16:33:47 +0200 Subject: [Nagiosplug-devel] German translation errors? In-Reply-To: <4653F099.8040906@aei.ca> References: <4653F099.8040906@aei.ca> Message-ID: <465450CB.4010301@ac-nancy-metz.fr> Thomas Guyot-Sionnest a ?crit : > I don't speak German at all, but those strings looks obviously wrong: > > #: plugins/check_smtp.c:398 > #, fuzzy > msgid "recv() failed after AUTH LOGIN, " > msgstr "Ung?ltige HTTP Antwort von Host empfangen\n" All of those strings are marked "fuzzy". They are not used by gettext. -- St?phane Urbanovski From ae at op5.se Wed May 23 16:46:38 2007 From: ae at op5.se (Andreas Ericsson) Date: Wed, 23 May 2007 16:46:38 +0200 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code Message-ID: <465453CE.3070609@op5.se> This patch lets the user specify how to translate the various return codes from the commands the negate plugin runs, rather than just having the hardcoded option to go with. This is specified as such: --critical=warning (to make critical translate to warning) --warning=ok Also, this patch breaks argument parsing at the last known argument and assumes the rest of the command-line is the command intended to run, and also switches negate from using the legacy spopen interface to the better runcmd stuff. The necessary Makefile modifications are included in this patch. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -------------- next part -------------- A non-text attachment was scrubbed... Name: negate-status-select.patch Type: text/x-patch Size: 11298 bytes Desc: not available URL: From ton.voon at altinity.com Thu May 24 10:56:21 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 24 May 2007 09:56:21 +0100 Subject: [Nagiosplug-devel] [PATCH] negate: Let the user specify what end result of specific return code In-Reply-To: <465453CE.3070609@op5.se> References: <465453CE.3070609@op5.se> Message-ID: <429402DA-08CF-4C5E-96B9-22956B7A9943@altinity.com> Hi Andreas, On 23 May 2007, at 15:46, Andreas Ericsson wrote: > This patch lets the user specify how to translate the various return > codes from the commands the negate plugin runs, rather than just > having > the hardcoded option to go with. > > This is specified as such: > --critical=warning (to make critical translate to warning) > --warning=ok > This looks interesting and I wrote some tests to try this out, but I don't appear to be getting the right results. Could have a look at it? The tests are in plugins/t/negate.pl. To run them you have to run: cd plugins NPTEST_DEBUG=1 perl t/negate.pl Have I misunderstood how your options are meant to be used? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From Thomas at zango.com Fri May 25 00:52:47 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Thu, 24 May 2007 15:52:47 -0700 Subject: [Nagiosplug-devel] check_snmp returning WARNING on snmpget warnings (STDERR) Message-ID: <804160344192334BB21922E8082EA6C0913E06@seaex01.180solutions.com> I know this have been brought up before but I'm not sure if any solution was chosen. I just got hit by this "bug" though; adding a broken MIB caused a few hundreds snmp checks to send WARNING emails, and IMHO this is ridiculous. I'm wondering if anybody has objections to just ignore stderr. The other option I see would be to make it available as an option if anybody wants to check that. I believe that as long as we get the result I don't think there's any problem, and if we don't get the result we'll notify anyways... Any thought? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From seanius at seanius.net Fri May 25 08:25:41 2007 From: seanius at seanius.net (sean finney) Date: Fri, 25 May 2007 08:25:41 +0200 Subject: [Nagiosplug-devel] introducing a check_if_root for setuid plugins Message-ID: <200705250825.45564.seanius@seanius.net> hey folks, just a preliminary poll before i spend any time on the code. in debian, we ship the check_dhcp/check_icmp with the setuid bits disabled by default, in the interest of losing a little functionality for some increased security. we have a documented method for how one overrides the permissions supplied by the package, but the problem is it's in the documentation, and sometimes users have trouble finding their way to the documentation... so i was thinking it might be helpful for each of these plugins to call a check_if_root() function before actually trying to perform their duties, and if it seems that they're not root, have them spit out either a warning or an error message to be a little more informative. what do you think? sean -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andurin at process-zero.de Fri May 25 08:33:09 2007 From: andurin at process-zero.de (Hendrik Baecker) Date: Fri, 25 May 2007 08:33:09 +0200 Subject: [Nagiosplug-devel] introducing a check_if_root for setuid plugins In-Reply-To: <200705250825.45564.seanius@seanius.net> References: <200705250825.45564.seanius@seanius.net> Message-ID: <46568325.4090207@process-zero.de> Hi Sean, sounds good to me. Many users just configure the command nearly blind and are wondering why it doesn't work. A simple "WARNING - This plugin should run with SETUID Bit" is a short but powerful hint what they have to do. Hendrik sean finney schrieb: > hey folks, > > just a preliminary poll before i spend any time on the code. in debian, we > ship the check_dhcp/check_icmp with the setuid bits disabled by default, in > the interest of losing a little functionality for some increased security. > we have a documented method for how one overrides the permissions supplied > by the package, but the problem is it's in the documentation, and sometimes > users have trouble finding their way to the documentation... > > so i was thinking it might be helpful for each of these plugins to call a > check_if_root() function before actually trying to perform their duties, > and if it seems that they're not root, have them spit out either a warning or > an error message to be a little more informative. what do you think? > > > sean > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From matthias.eble at mailing.kaufland-informationssysteme.com Sun May 27 11:35:08 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sun, 27 May 2007 11:35:08 +0200 Subject: [Nagiosplug-devel] introducing a check_if_root for setuid plugins In-Reply-To: <200705250825.45564.seanius@seanius.net> References: <200705250825.45564.seanius@seanius.net> Message-ID: <465950CC.6010709@mailing.kaufland-informationssysteme.com> Hi Sean, > so i was thinking it might be helpful for each of these plugins to call a > check_if_root() function before actually trying to perform their duties, > and if it seems that they're not root, have them spit out either a warning or > an error message to be a little more informative. what do you think? I like the idea because the "you need to be root" hint will only be shown, if the user is definitely not root. Not like in eg check dhcp where the message is put out out if the the socket cannot be bound - which can of course have multiple reasons. Matthias From noreply at sourceforge.net Sun May 27 11:54:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 May 2007 02:54:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 17:27 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) Assigned to: M. Sean Finney (seanius) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Simon, I can only hardly understand your bugreport, too. Why don't you just set a warning and critical threshold? To me they are mandatory if you want to graph the response time. I'm about to set this report to pending since there has been an open question for a long time. This report will get deleted if the submitter will not reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 15:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 09:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 08:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-19 01:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 09:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 00:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 From noreply at sourceforge.net Sun May 27 11:59:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 May 2007 02:59:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1722411 ] Huge BUG in check_disk Message-ID: Bugs item #1722411, was opened at 2007-05-21 05:38 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&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: Invalid Priority: 1 Private: No Submitted By: hansm (hansm24) >Assigned to: Matthias Eble (psychotrahe) Summary: Huge BUG in check_disk Initial Comment: I updated 59 servers and im not happy i did. i was thinking everything was working good but one disk was full. did forget to start on that server. Filesystem Size Used Avail Use% Mounted on /dev/sda2 32G 26G 4.9G 84% / /dev/sda1 99M 15M 79M 16% /boot none 1004M 0 1004M 0% /dev/shm [root at krusty (May 20 - 11:37pm) - /usr/local/nagios/libexec] ./check_disk -w10% -c5% -p / DISK OK - free space: / 4918 MB (15% inode=97%);| /=25825MB;29150;30769;0;32389 always disk OK and in the meantime its almost full. how can i solve this? THIS IS URGENT!!! And im sure another people agree on that. Disk Status is one of the most urgent things. i hope this can be fixed ASAP!!! ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:59 Message: Logged In: YES user_id=1694341 Originator: NO setting this one to deleted - check_disk wouldn't have passed the tests, if there would have been a problem that obvious. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-21 12:06 Message: Logged In: YES user_id=1694341 Originator: NO hi hans, as hendrik already described.. everything is fine - at least if the output is from the problem host. check_disk thresholds are *Free Space* thresholds, so if fhere is more free space than -w/-c everything is fine. Matthias ---------------------------------------------------------------------- Comment By: Hendrik B?cker (hendrikb) Date: 2007-05-21 07:46 Message: Logged In: YES user_id=906410 Originator: NO Hey Hans, URGENT or not, IMHO if you tell check_disk that you want to have a warning on 10% free disk space and a critical on 5% of free disk space and if you have 16% of free disk space all is OK. See: check_disk --help for this: -w, --warning=INTEGER Exit with WARNING status if less than INTEGER --units of disk are free -w, --warning=PERCENT% Exit with WARNING status if less than PERCENT of disk space is free -c, --critical=INTEGER Exit with CRITICAL status if less than INTEGER --units of disk are free -c, --critical=PERCENT% Exit with CRITCAL status if less than PERCENT of disk space is free ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1722411&group_id=29880 From seanius at seanius.net Sun May 27 15:51:49 2007 From: seanius at seanius.net (sean finney) Date: Sun, 27 May 2007 15:51:49 +0200 Subject: [Nagiosplug-devel] introducing a check_if_root for setuid plugins In-Reply-To: <200705250825.45564.seanius@seanius.net> References: <200705250825.45564.seanius@seanius.net> Message-ID: <200705271551.52381.seanius@seanius.net> i've added a simple check function and a wrapper function which uses the check to decide whether or not to display a warning, and added the functions to check_dhcp and check_icmp. lemme know what you think! sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From noreply at sourceforge.net Sun May 27 16:51:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 May 2007 07:51:38 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1505551 ] check_oracle unnecessary dependency Message-ID: Bugs item #1505551, was opened at 2006-06-13 19:39 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1505551&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jason Martin (jhmartin) Assigned to: Nobody/Anonymous (nobody) Summary: check_oracle unnecessary dependency Initial Comment: check_oracle.sh currently checks that it can find a valid ORACLE_HOME before performing any checks. However, the --db option only performs a ps|grep, which does not require a valid ORACLE HOME. This is handy when the ORACLE_HOME is not accessible to users other than oracle and a --db check is desirable. I suggest that the check for a valid ORACLE_HOME be performed only when the requested action is not --db. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 16:51 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1505551&group_id=29880 From noreply at sourceforge.net Sun May 27 16:52:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 May 2007 07:52:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1505551 ] check_oracle unnecessary dependency Message-ID: Bugs item #1505551, was opened at 2006-06-13 19:39 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1505551&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jason Martin (jhmartin) >Assigned to: Matthias Eble (psychotrahe) Summary: check_oracle unnecessary dependency Initial Comment: check_oracle.sh currently checks that it can find a valid ORACLE_HOME before performing any checks. However, the --db option only performs a ps|grep, which does not require a valid ORACLE HOME. This is handy when the ORACLE_HOME is not accessible to users other than oracle and a --db check is desirable. I suggest that the check for a valid ORACLE_HOME be performed only when the requested action is not --db. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 16:51 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1505551&group_id=29880 From noreply at sourceforge.net Mon May 28 11:55:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 May 2007 02:55:02 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 11:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From noreply at sourceforge.net Mon May 28 20:05:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 May 2007 11:05:45 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 03:36 Message generated for change (Comment added) made by sghosh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2007-05-28 14:05 Message: Logged In: YES user_id=46572 Originator: NO It looks like 192.168.0.221 is a relay. You actual dhcp server thinks (or is configured) as 192.168.0.237. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 05:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From noreply at sourceforge.net Tue May 29 08:44:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 May 2007 23:44:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 17:27 Message generated for change (Comment added) made by sb-netman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) Assigned to: M. Sean Finney (seanius) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- >Comment By: Simon Bellwood (sb-netman) Date: 2007-05-29 08:44 Message: Logged In: YES user_id=1156501 Originator: YES The problem is that check_tcp returns "0" and "0" for its warning and critical values, even though they are undefined. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Simon, I can only hardly understand your bugreport, too. Why don't you just set a warning and critical threshold? To me they are mandatory if you want to graph the response time. I'm about to set this report to pending since there has been an open question for a long time. This report will get deleted if the submitter will not reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 15:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 09:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 08:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-19 01:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 09:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 00:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 From noreply at sourceforge.net Tue May 29 09:28:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 00:28:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 17:27 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) >Assigned to: Matthias Eble (psychotrahe) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 09:28 Message: Logged In: YES user_id=1694341 Originator: NO after looking at the developer guidelines, it seems that the 0 is wrong indeed: 6. warn, crit, min or max may be null (for example, if the threshold is not defined or min and max do not apply). Trailing unfilled semicolons can be dropped imo FLAG_TIME_WARN and FLAG_TIME_CRIT need to be recognized when fperfdata is called. Will look at this in the next days.. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2007-05-29 08:44 Message: Logged In: YES user_id=1156501 Originator: YES The problem is that check_tcp returns "0" and "0" for its warning and critical values, even though they are undefined. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Simon, I can only hardly understand your bugreport, too. Why don't you just set a warning and critical threshold? To me they are mandatory if you want to graph the response time. I'm about to set this report to pending since there has been an open question for a long time. This report will get deleted if the submitter will not reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 15:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 09:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 08:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-19 01:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 09:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 00:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 From noreply at sourceforge.net Tue May 29 12:07:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 03:07:07 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Comment added) made by fhackenbmt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 12:07 Message: Logged In: YES user_id=1706299 Originator: YES this problem is reproducible with the current release. it do not occur on check_dhcp from nagios-plugins version 1.4 fyio: I have to dhcp servers, one is master, the other ist slave. the config is similar to: http://www.lithodyne.net/docs/dhcp/dhcp-4.html ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2007-05-28 20:05 Message: Logged In: YES user_id=46572 Originator: NO It looks like 192.168.0.221 is a relay. You actual dhcp server thinks (or is configured) as 192.168.0.237. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 11:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From noreply at sourceforge.net Tue May 29 15:00:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 06:00:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1727485 ] NTP limit number of hosts Message-ID: Patches item #1727485, was opened at 2007-05-29 14: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=1727485&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: alain williams (addw) Assigned to: Nobody/Anonymous (nobody) Summary: NTP limit number of hosts Initial Comment: check_ntp is used to check the time on a remote host. I want to use it to check the time on a local host against the NTP servers, eg 0.uk.pool.ntp.org. However: 0.uk.pool.ntp.org expands to 12 addresses, I don't want (or need) to check against that many; checking against a list of 3 would be enough. I need more than 1 just in case one of the remote reference servers is down. I want to use an address like 0.uk.pool.ntp.org because I don't want the maintenance hassle of tracking changes to the list of reference time servers in the UK. The patch adds an option: -m, --maxhosts=INTEGER Max hosts to check - for where host expands to multiple addresses The patch is upwards compatible with the existing plugin, ie it should not break existing use of the plugin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1727485&group_id=29880 From noreply at sourceforge.net Tue May 29 16:29:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 07:29:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Duplicate Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) >Assigned to: Holger Weiss (hweiss) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-05-29 16:29 Message: Logged In: YES user_id=759506 Originator: NO fhackenbmt: The reason for this problem is (most probably) explained in tracker ID #1667488 and fixed in CVS. Could you try the current snapshot from http://nagiosplug.sourceforge.net/snapshot/ and report back? I'll set the status to "pending", feel free to re-open it if you continue to encounter problems. Thanks a lot, Holger PS, psychotrahe: check_dhcp.c has been moved from plugins/ to plugins_root/, thus the revision number confusion. Yes, this is a drawback of CVS ;-) ---------------------------------------------------------------------- Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 12:07 Message: Logged In: YES user_id=1706299 Originator: YES this problem is reproducible with the current release. it do not occur on check_dhcp from nagios-plugins version 1.4 fyio: I have to dhcp servers, one is master, the other ist slave. the config is similar to: http://www.lithodyne.net/docs/dhcp/dhcp-4.html ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2007-05-28 20:05 Message: Logged In: YES user_id=46572 Originator: NO It looks like 192.168.0.221 is a relay. You actual dhcp server thinks (or is configured) as 192.168.0.237. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 11:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From Thomas at zango.com Tue May 29 16:31:46 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Tue, 29 May 2007 07:31:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug incheck_tcp In-Reply-To: References: Message-ID: <804160344192334BB21922E8082EA6C0914013@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug- > devel-bounces at lists.sourceforge.net] On Behalf Of SourceForge.net > Sent: May 29, 2007 3:29 > To: noreply at sourceforge.net > Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug > incheck_tcp > > Bugs item #1181554, was opened at 2005-04-12 17:27 > Message generated for change (Comment added) made by psychotrahe > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group > _id=29880 > > Please note that this message will contain a full copy of the comment > thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Simon Bellwood (sb-netman) > >Assigned to: Matthias Eble (psychotrahe) > Summary: 1.4-3: Bug in check_tcp > > Initial Comment: > I'm using check_imap with perfparse, and it's returning > critical for all values. > > It seems the problem is that when no critical or > warning value is passed to it on the command line, it > defaults to use 0.000 and 0.000 respectively. Perfparse > then sees that the check time (say 0.002 seconds) is > above 0 and flags a CRITICAL warning. > > I've had a look at the code, and the return happens at > check_tcp.c:389, where fperfdata is called. > fperfdata is provided by utils.h which sets both types > to a double, so I suspect it's not as simple as > changing check_tcp.c to return nulls if the -w and -c > flags aren't given :/ Hey guys, I believe all we want to change is: printf("|%s", fperfdata ("time", elapsed_time, "s", TRUE, warning_time, TRUE, critical_time, TRUE, 0, TRUE, socket_timeout) To something like this: printf("|%s", fperfdata ("time", elapsed_time, "s", (warning_time > 0 ? TRUE : FALSE), warning_time, (critical_time > 0 ? TRUE : FALSE), critical_time, TRUE, 0, TRUE, socket_timeout) Basically don't tell fperfdata that there is a warn/crit parameter if there's none. This may need some tuning but I hope you get the idea. I don't have time right now... Please assign the bug to me (dermoth) if you like and I'll get it fixed and tested tonight :) At the same time I could review all of them to make sure there's no other plugins with optional thresholds that hard-code the parameter. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Tue May 29 16:47:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 07:47:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Comment added) made by fhackenbmt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Duplicate Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Holger Weiss (hweiss) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 16:47 Message: Logged In: YES user_id=1706299 Originator: YES ok with the current snapshot it works... thanks for your work... ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-05-29 16:29 Message: Logged In: YES user_id=759506 Originator: NO fhackenbmt: The reason for this problem is (most probably) explained in tracker ID #1667488 and fixed in CVS. Could you try the current snapshot from http://nagiosplug.sourceforge.net/snapshot/ and report back? I'll set the status to "pending", feel free to re-open it if you continue to encounter problems. Thanks a lot, Holger PS, psychotrahe: check_dhcp.c has been moved from plugins/ to plugins_root/, thus the revision number confusion. Yes, this is a drawback of CVS ;-) ---------------------------------------------------------------------- Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 12:07 Message: Logged In: YES user_id=1706299 Originator: YES this problem is reproducible with the current release. it do not occur on check_dhcp from nagios-plugins version 1.4 fyio: I have to dhcp servers, one is master, the other ist slave. the config is similar to: http://www.lithodyne.net/docs/dhcp/dhcp-4.html ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2007-05-28 20:05 Message: Logged In: YES user_id=46572 Originator: NO It looks like 192.168.0.221 is a relay. You actual dhcp server thinks (or is configured) as 192.168.0.237. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 11:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From noreply at sourceforge.net Tue May 29 16:50:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 07:50:04 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1648570 ] check_dhcp error by asking 2 dhcp servers Message-ID: Bugs item #1648570, was opened at 2007-01-31 09:36 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: fhackenbmt (fhackenbmt) Assigned to: Holger Weiss (hweiss) Summary: check_dhcp error by asking 2 dhcp servers Initial Comment: nagios-plugins 1.4.5 contains the check_dhcp version 1.6, wich has problems with some dhcp-server setups check_dhcp version 1.7 from nagios-plugins version 1.4 works without problems, so please include the this version or fix included version. so what is the porblem with the check_dhcp 1.6? we have 2 dhpc-servers and if I ask one of them, the check_dhcp plugins says: =======snip======= monitor:~# /usr/lib/nagios/plugins/check_dhcp -v -s 192.168.0.221 Requested server address: 192.168.0.221 DHCP socket: 3 Hardware address: 00163e0f931c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 427952544 (0x198209A0) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.222 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.222 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.97 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.97 recv_result_1: 333 recv_result_2: 333 receive_dhcp_packet() result: 333 receive_dhcp_packet() source: 192.168.0.221 Result=OK DHCPOFFER from IP address 192.168.0.237 via 192.168.0.221 DHCPOFFER XID: 427952544 (0x198209A0) DHCPOFFER chaddr: 00163E0F931C DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 192.168.0.72 DHCPOFFER siaddr: 192.168.0.237 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 54 (0x04) Option: 51 (0x04) Option: 1 (0x04) Option: 3 (0x04) Option: 6 (0x0C) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 3600 seconds Renewal Time: 1800 seconds Rebinding Time: 3150 seconds Added offer from server @ 192.168.0.237 of IP address 192.168.0.72 No (more) data received Result=ERROR Total responses seen on the wire: 2 Valid responses for this machine: 2 CRITICAL: Received 2 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 3600 sec. =======snap======= as yo can see the requested servers (192.168.0.221) have answerd. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-05-29 16:50 Message: Logged In: YES user_id=759506 Originator: NO Thanks for your feedback! "Case closed." ---------------------------------------------------------------------- Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 16:47 Message: Logged In: YES user_id=1706299 Originator: YES ok with the current snapshot it works... thanks for your work... ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-05-29 16:29 Message: Logged In: YES user_id=759506 Originator: NO fhackenbmt: The reason for this problem is (most probably) explained in tracker ID #1667488 and fixed in CVS. Could you try the current snapshot from http://nagiosplug.sourceforge.net/snapshot/ and report back? I'll set the status to "pending", feel free to re-open it if you continue to encounter problems. Thanks a lot, Holger PS, psychotrahe: check_dhcp.c has been moved from plugins/ to plugins_root/, thus the revision number confusion. Yes, this is a drawback of CVS ;-) ---------------------------------------------------------------------- Comment By: fhackenbmt (fhackenbmt) Date: 2007-05-29 12:07 Message: Logged In: YES user_id=1706299 Originator: YES this problem is reproducible with the current release. it do not occur on check_dhcp from nagios-plugins version 1.4 fyio: I have to dhcp servers, one is master, the other ist slave. the config is similar to: http://www.lithodyne.net/docs/dhcp/dhcp-4.html ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2007-05-28 20:05 Message: Logged In: YES user_id=46572 Originator: NO It looks like 192.168.0.221 is a relay. You actual dhcp server thinks (or is configured) as 192.168.0.237. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-28 11:55 Message: Logged In: YES user_id=1694341 Originator: NO hi fhackenbmt, I cannot understand the versioning problem. check_dhcp 1.7 is not tagged and should hence not have been part of any release. Is this problem still reproducible with the current release? Thanks for your Report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1648570&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Tue May 29 21:24:16 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Tue, 29 May 2007 21:24:16 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug incheck_tcp In-Reply-To: <804160344192334BB21922E8082EA6C0914013@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C0914013@seaex01.180solutions.com> Message-ID: <465C7DE0.1000202@mailing.kaufland-informationssysteme.com> > I believe all we want to change is: > > printf("|%s", > fperfdata ("time", elapsed_time, "s", > TRUE, warning_time, > TRUE, critical_time, > TRUE, 0, > TRUE, socket_timeout) > > To something like this: > > printf("|%s", > fperfdata ("time", elapsed_time, "s", > (warning_time > 0 ? TRUE : FALSE), > warning_time, > (critical_time > 0 ? TRUE : FALSE), > critical_time, > TRUE, 0, > TRUE, socket_timeout) > > Basically don't tell fperfdata that there is a warn/crit parameter if > there's none. That was my intention, too, except that i used the flags FLAG_TIME_WARN/CRIT istead of >0. I think that's what the flags are good for (I checked it in a few minutes ago). > At the same time I could review all of them to make sure there's no other > plugins with optional thresholds that hard-code the parameter. > I don't know if this is worth the time, because there were discussions about major changes in the perfdata part - That's the reason why I'm usually ignoring performance data items in the bug tracker at the moment. But I don't wanna stop you, if you like to do it :) Matthias From noreply at sourceforge.net Tue May 29 21:31:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 12:31:50 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 17:27 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&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: Fixed Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 21:31 Message: Logged In: YES user_id=1694341 Originator: NO I fixed this in cvs, now. You can try the latest snapshot. Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 09:28 Message: Logged In: YES user_id=1694341 Originator: NO after looking at the developer guidelines, it seems that the 0 is wrong indeed: 6. warn, crit, min or max may be null (for example, if the threshold is not defined or min and max do not apply). Trailing unfilled semicolons can be dropped imo FLAG_TIME_WARN and FLAG_TIME_CRIT need to be recognized when fperfdata is called. Will look at this in the next days.. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2007-05-29 08:44 Message: Logged In: YES user_id=1156501 Originator: YES The problem is that check_tcp returns "0" and "0" for its warning and critical values, even though they are undefined. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Simon, I can only hardly understand your bugreport, too. Why don't you just set a warning and critical threshold? To me they are mandatory if you want to graph the response time. I'm about to set this report to pending since there has been an open question for a long time. This report will get deleted if the submitter will not reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 15:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 09:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 08:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-19 01:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 09:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 00:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880 From noreply at sourceforge.net Tue May 29 22:11:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 May 2007 13:11:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1475899 ] check_tcp segfaults with mutliple -s or -e args. Message-ID: Bugs item #1475899, was opened at 2006-04-25 03:48 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1475899&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Argument proccessing Group: Release (specify) Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: John Rouillard (rouilj) >Assigned to: Matthias Eble (psychotrahe) Summary: check_tcp segfaults with mutliple -s or -e args. Initial Comment: Plugins 1.4.3 running on FC3 or centos 4.2 redhat linux. The following command coredumps against netcat running as "nc -p 2525 -l": check_tcp -H localhost -p 2525 -s send1 -e receive1 \ -s send2 -e receive2 -v Using service TCP Port: 2525 flags: 0x2 Send string: send2 server_expect_count: 2 0: (null) 1: receive2 received 9 bytes from host #-raw-recv-------# receive2 #-raw-recv-------# looking for [(null)] anywhere in [receive2] Segmentation fault Note that the second send string is sent first. It should work as presented on the command line and send "send1" look for "receive1" then send "send2" and look for 'receive2". -- rouilj ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 22:11 Message: Logged In: YES user_id=1694341 Originator: NO hi all, thanks to ralph for this great analysis. Your explanation describes exactly what happens/ed. I removed the line in cvs and added a notice that -e can be repeated to the --help output. I'll let this item open since to me, there should be a new flag to let check_tcp require ALL instead of ANY of the expect strings. This flag can then be used to split XML expect strings (like in check_jabber), where a single string could cause a false positive, since ordering doesn't matter. ---------------------------------------------------------------------- Comment By: Christoph Maser (cmaser) Date: 2006-10-23 17:41 Message: Logged In: YES user_id=127006 i tried with 1.4.4 and this problem is still there. ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-10-23 17:30 Message: Logged In: YES user_id=1515003 Hi, i've stumbled over the "double -e means SEGV" thing myself. Here is a short analysis that should help fix it. First: these are two unrelated problems. -s is not meant to be specified several times, and only the latest one is effective. Maybe this needs to be clarified in the description, maybe not. For the -e switch things are different. There is a meaning of specifying this argument several time, and it is this: The returned response must match ANY of the -e arguments. So there is no order imposed here, nor must the response match all the arguments you give. Now for the segfault: This is caused by writing a NULL into the structure holding the expected response strings in check_tcp.c line 510. This line is redundant at best (if only one -e argument is given) and desastrous in all other cases. Resolution: Remove line 510. Long version: The EXPECT that is written to is a macro that resolves to server_expect[0]. You will notice two cases: Either the first -e argument is being processed. In that case server_expect itself is overwritten with a pointer to freshly allocated memory. In this case, NULLing its first component string is redundant. Or the second, third, ... -e argument is being processed. In that case, the first argument string is overwritten with the NULL, and the server_expect struct is enlarged (realloc'd) afterwards, keeping the NULL mine in place. Hence the SEGV later. In the hope that this helps, Ralph R??ner ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1475899&group_id=29880 From dermoth at aei.ca Wed May 30 05:45:13 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 29 May 2007 23:45:13 -0400 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug incheck_tcp In-Reply-To: <465C7DE0.1000202@mailing.kaufland-informationssysteme.com> References: <804160344192334BB21922E8082EA6C0914013@seaex01.180solutions.com> <465C7DE0.1000202@mailing.kaufland-informationssysteme.com> Message-ID: <465CF349.3040101@aei.ca> On 29/05/07 03:24 PM, Matthias Eble wrote: > > That was my intention, too, except that i used the flags > FLAG_TIME_WARN/CRIT istead of >0. I think that's what the flags are good > for (I checked it in a few minutes ago). You're right. I just has a very quick look at it and I replied because I thought you didn't understand what was the problem... I looked at your commit and I still have one comment. Where the thresholds are hard-coded (0), I'd either use the real thresholds (actually remove teh if/else) or always set the parameter as FALSE. It's the same thing as the other place; either print a real threshold or print nothing, but we shouldn't always print 0. I believe the original idea was to be able to "know" the state of the service by using the perfdata. This isn't consistent anymore now you test for the flag, and IMHO reverting to the old behavior for match==-2 is a hack; the perfdata isn't proper way to deduct services status*. Many thanks Matthias; your work on the tracker items is greatly appreciated! Thomas * Maybe this could change... like adding a "state=n" parameter... From matthias.eble at mailing.kaufland-informationssysteme.com Wed May 30 08:35:12 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Wed, 30 May 2007 08:35:12 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug incheck_tcp In-Reply-To: <465CF349.3040101@aei.ca> References: <804160344192334BB21922E8082EA6C0914013@seaex01.180solutions.com> <465C7DE0.1000202@mailing.kaufland-informationssysteme.com> <465CF349.3040101@aei.ca> Message-ID: <465D1B20.6020508@mailing.kaufland-informationssysteme.com> > I looked at your commit and I still have one comment. Where the > thresholds are hard-coded (0), I'd either use the real thresholds > (actually remove teh if/else) or always set the parameter as FALSE. It's > the same thing as the other place; either print a real threshold or > print nothing, but we shouldn't always print 0. yes, i stumbled over this, too and set it to my "wanna ask on the mailing list" list. I let it that way because I thought the comment above the code block must somehow have a reason. So I kept the old behavior for backward compatibility and changed only the part I definitely knew about. > I believe the original idea was to be able to "know" the state of the > service by using the perfdata. This isn't consistent anymore now you > test for the flag, and IMHO reverting to the old behavior for match==-2 > is a hack; the perfdata isn't proper way to deduct services status*. If it is like that, fine. Then we can kick out the entire if/else block. > Many thanks Matthias; your work on the tracker items is greatly appreciated! Thank you. I hope we can get it clean some time. To me actively maintaining the tracker is the best way to say thanks to all the people reporting problems. If they don't get responses on their items they might not post their reports in the future. Matthias From noreply at sourceforge.net Thu May 31 18:47:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 09:47:53 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1470013 ] check_tcp complains about double values in parameter Message-ID: Bugs item #1470013, was opened at 2006-04-13 20:50 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1470013&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stefan Welke (swelke) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp complains about double values in parameter Initial Comment: check_tcp conplains about double values when given with parameter. cmdline: # check_tcp -H sourceforge.net -p 80 -c 0.500 or # check_tcp -H sourceforge.net -p 80 -w 0.250 EROOR: check_TCP: Warning threshold muss ein positiver Integer sein ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2007-05-31 18:47 Message: Logged In: YES user_id=1694341 Originator: NO Hi Stefan, this problem has been fixed in the meantime. warning/critical time can be double since Sep 2 20:32:27 2006. Thank you for your report Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1470013&group_id=29880 From noreply at sourceforge.net Thu May 31 18:48:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 09:48:52 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1181554 ] 1.4-3: Bug in check_tcp Message-ID: Bugs item #1181554, was opened at 2005-04-12 17:27 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&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: Fixed Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) Assigned to: Matthias Eble (psychotrahe) Summary: 1.4-3: Bug in check_tcp Initial Comment: I'm using check_imap with perfparse, and it's returning critical for all values. It seems the problem is that when no critical or warning value is passed to it on the command line, it defaults to use 0.000 and 0.000 respectively. Perfparse then sees that the check time (say 0.002 seconds) is above 0 and flags a CRITICAL warning. I've had a look at the code, and the return happens at check_tcp.c:389, where fperfdata is called. fperfdata is provided by utils.h which sets both types to a double, so I suspect it's not as simple as changing check_tcp.c to return nulls if the -w and -c flags aren't given :/ ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 21:31 Message: Logged In: YES user_id=1694341 Originator: NO I fixed this in cvs, now. You can try the latest snapshot. Matthias ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-29 09:28 Message: Logged In: YES user_id=1694341 Originator: NO after looking at the developer guidelines, it seems that the 0 is wrong indeed: 6. warn, crit, min or max may be null (for example, if the threshold is not defined or min and max do not apply). Trailing unfilled semicolons can be dropped imo FLAG_TIME_WARN and FLAG_TIME_CRIT need to be recognized when fperfdata is called. Will look at this in the next days.. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2007-05-29 08:44 Message: Logged In: YES user_id=1156501 Originator: YES The problem is that check_tcp returns "0" and "0" for its warning and critical values, even though they are undefined. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-27 11:54 Message: Logged In: YES user_id=1694341 Originator: NO Hi Simon, I can only hardly understand your bugreport, too. Why don't you just set a warning and critical threshold? To me they are mandatory if you want to graph the response time. I'm about to set this report to pending since there has been an open question for a long time. This report will get deleted if the submitter will not reply in the next 14 days. Matthias ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 16:58 Message: Logged In: YES user_id=226838 hi, are you still interested in resolving this bug? if so, i still need to know what the perfparse system will need to represent and "undefined" number, or whether no perfparse data should be output at all in such a case. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-02 15:07 Message: Logged In: YES user_id=226838 sorry, i should be a little more clear on this: is perfparse capable of parsing an "unknown" or "undefined" value? if so, how should it look? otherwise, would it make sense to just not pass the information to perfparse at all? if so how should that look? you're right that there's no way to pass such values in the current code, but it wouldn't be too hard to add this functionality, as long as i knew what i was doing :) ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-05-02 09:14 Message: Logged In: YES user_id=1156501 > i don't believe arbitrarily setting the warn/critical > values is the appropriate response. But this is what utils.h does (used by check_tcp.c), not perfparse. There seems to be no way of returning an unknown value, so it uses 0.000 instead. perfparse sees the "unknown" warning and critical values as 0.000, so uses them. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-05-01 22:26 Message: Logged In: YES user_id=226838 hi, i'm still not sure what the solution to this should be. i don't believe arbitrarily setting the warn/critical values is the appropriate response. is there an undef value in perfparse? ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-19 08:52 Message: Logged In: YES user_id=1156501 But the plugin returns "0" and "0" for its warning and critical values, even though they are undefined - isn't that a bug? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-19 01:50 Message: Logged In: YES user_id=226838 perhaps there's an "undef" value that could be used in such a case? i really don't know much about the whole perfparse thing since i use a seperate system from nagios for monitoring performance data. otherwise, i think the system is doing exactly what it's supposed to be doing, and would need some convincing why the answer isn't to just pass the warning and critical arguments to check_tcp. ---------------------------------------------------------------------- Comment By: Simon Bellwood (sb-netman) Date: 2005-04-18 09:01 Message: Logged In: YES user_id=1156501 I was hoping that one of the developers would either say: i) Oh no wait, there's an easy fix for this ii) Tell perfparse to treat 0.0 as "no value" Although ii) might be wrong in some cases, i.e. when 0 was considered a good value (perhaps for items where a measure from the normal was taken - can' think of any examples atm) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-04-18 00:14 Message: Logged In: YES user_id=226838 hi, what exactly are you suggesting as a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1181554&group_id=29880