From ae at op5.se Mon Oct 2 11:21:28 2006 From: ae at op5.se (Andreas Ericsson) Date: Mon, 02 Oct 2006 11:21:28 +0200 Subject: [Nagiosplug-devel] feature request -selecting your network interface In-Reply-To: <46329.216.49.181.128.1159566539.squirrel@webmail.netshel.net> References: <46329.216.49.181.128.1159566539.squirrel@webmail.netshel.net> Message-ID: <4520DA18.3070002@op5.se> Ahh, the wonders of opensource. Someone got curious and Good Things Happened. Kudos for introducing the concept in actual code. More below. bobi at netshel.net wrote: > Hi, > > I don't know why I felt like doing this - guess I was curious if you could > bind to a local address for a TCP stream prior to calling connect(2). I > didn't think it would work, because the routing table usually controls > which interface to send a packet out on (and hence, which source IP > address to emebed in the IP header.) But if an address is reachable from > more than one interface, I supposed it could work. > > Anyway, please find attached a tar-ball containing three patch files for: > > 1. netutils.h > 2. netutils.c > 3. check_tcp.c > > If you patch the above three files, and re-make check_tcp, it will allow > you to specify the source IP address. > > The new option is: -I src-ip-address > > I've tested it on my Linux box which has two interfaces (plus loopback,) > and it seems to work well. I watched the packets go out with tcpdump and, > sure enough, the IP headers had the source IP address that I'd specified > in the command line. > > One note, though: If you specify an interface IP address which can't > reach your destination host, the connect(2) call inside netutils.c will > return an EINVAL error. I know this because I tried accessing an external > host through the loopback interface (127.0.0.1) and it returned EINVAL, > which is what you'd expect. > Yup. The only objection I have to this patch is the lack of an error-message when the user has done this exact mistake, or when the user has put a source-ip that's not present on the system as argument to -I. So after the connect(2) call, I'd put something like this: ---%<---%<---%<--- if (result < 0 && src_ip && errno == EINVAL) die("UNKNOWN: Can't send to %s through interface with address %s\n", target, src_ip); ---%<---%<---%<--- and after the bind(2) call, I'd put something like this: ---%<---%<---%<--- /* SVr4 defines EADDRNOTAVAIL. Many systems have it, so check for it */ #ifdef EADDRNOTAVAIL if (result < 0 && errno == EADDRNOTAVAIL) die("UNKNOWN: Can't send from source-ip %s. No interface has that address\n", source_ip); #endif ---%<---%<---%<--- With proper variables, inet_ntoa()'s and die() semantics, ofc (yes, I actually am that lazy ;-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Mon Oct 2 11:32:43 2006 From: ae at op5.se (Andreas Ericsson) Date: Mon, 02 Oct 2006 11:32:43 +0200 Subject: [Nagiosplug-devel] submitting my plugin, check_sip In-Reply-To: <20060929234115.GA13716@aloha.net> References: <20060929234115.GA13716@aloha.net> Message-ID: <4520DCBB.2080304@op5.se> O'Shaughnessy Evans wrote: > Hi, folks. Some time back, I wrote a plugin to test SIP service (Jan > 2005, if my RCS history is accuate). I've been using it for some time > and I figured it was about time that I offered it to the rest of the > Nagios community. I saw on voip-info.org that somebody else also has > a check_sip plugin, but I didn't find it in the nagios-plugins tarball > so I hope I'm not stepping on anybody's toes by offering my own for > inclusion with the nagios-plugins distribution. > Survival of the fittest dictates that competition breeds perfection. Until something is included in the official distribution, I'd say this is a free-fire zone and may the best code be used most. In any case, submitting the code is always to prefer over not doing so, as people can then choose for themselves which one to use. > Before I post it to the list, I'd like to know the preferred method of > doing so. Should I include a README file with it and put them both in > a .tar.gz, then MIME-attach it? Simply attach the script and any other > docs as their own attachments? Post a URL for download and peer review? > How would you prefer to see the code? > Either way works, although Ton Voon, who manages the nagios-plugins, prefers to see contributions in the sourceforge tracker thingie. I personally never use it (no, not ever), so if you want your code to reach the maximum amount of users you should both post it to the tracker and stick it to an email as a plain-text attachment and send it. Making a tar-ball out of it doesn't provide much benefit unless the script and it's docs are big (~20KiB or some such). I personally prefer having two attachments, with the readme as a separate one or included at the top of the plugin as a big block-comment, like most plugins are documented. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Mon Oct 2 13:51:15 2006 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 2 Oct 2006 12:51:15 +0100 Subject: [Nagiosplug-devel] submitting my plugin, check_sip In-Reply-To: <20060929234115.GA13716@aloha.net> References: <20060929234115.GA13716@aloha.net> Message-ID: On 30 Sep 2006, at 00:41, O'Shaughnessy Evans wrote: > Hi, folks. Some time back, I wrote a plugin to test SIP service (Jan > 2005, if my RCS history is accuate). I've been using it for some time > and I figured it was about time that I offered it to the rest of the > Nagios community. I saw on voip-info.org that somebody else also has > a check_sip plugin, but I didn't find it in the nagios-plugins tarball > so I hope I'm not stepping on anybody's toes by offering my own for > inclusion with the nagios-plugins distribution. > > Before I post it to the list, I'd like to know the preferred method of > doing so. Should I include a README file with it and put them both in > a .tar.gz, then MIME-attach it? Simply attach the script and any > other > docs as their own attachments? Post a URL for download and peer > review? > How would you prefer to see the code? Shaug, Thanks for the plugin, and wanting to share it. We're not accepting new plugins at the moment for inclusion into the distribution. Can you post it onto NagiosExchange? http:// nagiosexchange.org. This is the official 3rd party repository, so users will find it there. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Oct 2 21:12:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Oct 2006 12:12:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1569488 ] check_ifoperstatus.pl - -n option doesn't work, with fix Message-ID: Bugs item #1569488, was opened at 2006-10-02 15:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: John Sellens (jsellens) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifoperstatus.pl - -n option doesn't work, with fix Initial Comment: I wanted to use the -n option to check_ifoperstatus, but it wasn't working. The -n / --name option declarations set the $ifName variable, but the test around line 153 checks $name instead of $ifName, so the names are never compared. In the paragraph starting with the "Check to see if ifName match", change $name to $ifName in the 3 places it is used. thanks - cheers! John who's very surprised this has apparently existed this long without anyone noticing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 From noreply at sourceforge.net Mon Oct 2 21:20:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Oct 2006 12:20:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1569488 ] check_ifoperstatus.pl - -n option doesn't work, with fix Message-ID: Bugs item #1569488, was opened at 2006-10-02 15:12 Message generated for change (Comment added) made by jsellens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: John Sellens (jsellens) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifoperstatus.pl - -n option doesn't work, with fix Initial Comment: I wanted to use the -n option to check_ifoperstatus, but it wasn't working. The -n / --name option declarations set the $ifName variable, but the test around line 153 checks $name instead of $ifName, so the names are never compared. In the paragraph starting with the "Check to see if ifName match", change $name to $ifName in the 3 places it is used. thanks - cheers! John who's very surprised this has apparently existed this long without anyone noticing ---------------------------------------------------------------------- >Comment By: John Sellens (jsellens) Date: 2006-10-02 15:20 Message: Logged In: YES user_id=8519 Oops - and also in the "if (defined $name) {" at line 143 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1569488&group_id=29880 From shaug-nagios at wumpus.org Tue Oct 3 00:14:29 2006 From: shaug-nagios at wumpus.org (O'Shaughnessy Evans) Date: Mon, 2 Oct 2006 15:14:29 -0700 Subject: [Nagiosplug-devel] submitting my plugin, check_sip In-Reply-To: References: <20060929234115.GA13716@aloha.net> Message-ID: <20061002221429.GA16110@aloha.net> Ton Voon wrote: > Thanks for the plugin, and wanting to share it. > > We're not accepting new plugins at the moment for inclusion into the > distribution. Can you post it onto NagiosExchange? http://nagiosexchange.org > . This is the official 3rd party repository, so users will find it there. Thanks for the replies. I've added it to nagiosexchange.org. Is there a way to change the category that the plugin is listed under, though? I seem to have created it under Misc, but it should probably be under Networking. Best regards. -- o'shaughnessy evans http://isle.wumpus.org/ From bobi at netshel.net Tue Oct 3 00:48:53 2006 From: bobi at netshel.net (bobi at netshel.net) Date: Mon, 2 Oct 2006 15:48:53 -0700 (PDT) Subject: [Nagiosplug-devel] feature request -selecting your network interface In-Reply-To: <4520DA18.3070002@op5.se> References: <46329.216.49.181.128.1159566539.squirrel@webmail.netshel.net> <4520DA18.3070002@op5.se> Message-ID: <27933.216.49.181.128.1159829333.squirrel@webmail.netshel.net> And the wonders of ultimate geekdom. ;-) Ok, so here are the updated patches, adding your suggested diagnostic messages (only the netutils.c patch changed.) Does this need to be submitted as a patch request on sourceforge? (That is, assuming it merits enough interest from the community-at-large.) May the Source (Address) Be With You, Bob > Ahh, the wonders of opensource. Someone got curious and Good Things > Happened. Kudos for introducing the concept in actual code. > > More below. > > bobi at netshel.net wrote: >> Hi, >> >> I don't know why I felt like doing this - guess I was curious if you >> could >> bind to a local address for a TCP stream prior to calling connect(2). I >> didn't think it would work, because the routing table usually controls >> which interface to send a packet out on (and hence, which source IP >> address to emebed in the IP header.) But if an address is reachable >> from >> more than one interface, I supposed it could work. >> >> Anyway, please find attached a tar-ball containing three patch files >> for: >> >> 1. netutils.h >> 2. netutils.c >> 3. check_tcp.c >> >> If you patch the above three files, and re-make check_tcp, it will allow >> you to specify the source IP address. >> >> The new option is: -I src-ip-address >> >> I've tested it on my Linux box which has two interfaces (plus loopback,) >> and it seems to work well. I watched the packets go out with tcpdump >> and, >> sure enough, the IP headers had the source IP address that I'd specified >> in the command line. >> >> One note, though: If you specify an interface IP address which can't >> reach your destination host, the connect(2) call inside netutils.c will >> return an EINVAL error. I know this because I tried accessing an >> external >> host through the loopback interface (127.0.0.1) and it returned EINVAL, >> which is what you'd expect. >> > > Yup. The only objection I have to this patch is the lack of an > error-message when the user has done this exact mistake, or when the > user has put a source-ip that's not present on the system as argument to > -I. > > So after the connect(2) call, I'd put something like this: > ---%<---%<---%<--- > if (result < 0 && src_ip && errno == EINVAL) > die("UNKNOWN: Can't send to %s through interface with address %s\n", > target, src_ip); > ---%<---%<---%<--- > > > and after the bind(2) call, I'd put something like this: > ---%<---%<---%<--- > /* SVr4 defines EADDRNOTAVAIL. Many systems have it, so check for it */ > #ifdef EADDRNOTAVAIL > if (result < 0 && errno == EADDRNOTAVAIL) > die("UNKNOWN: Can't send from source-ip %s. No interface has that > address\n", source_ip); > #endif > ---%<---%<---%<--- > > With proper variables, inet_ntoa()'s and die() semantics, ofc (yes, I > actually am that lazy ;-) > > -- > Andreas Ericsson andreas.ericsson at op5.se > OP5 AB www.op5.se > Tel: +46 8-230225 Fax: +46 8-230231 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_tcp.c.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: netutils.c.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: netutils.h.diff URL: From ton.voon at altinity.com Wed Oct 4 06:39:00 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 4 Oct 2006 05:39:00 +0100 Subject: [Nagiosplug-devel] submitting my plugin, check_sip In-Reply-To: <20061002221429.GA16110@aloha.net> References: <20060929234115.GA13716@aloha.net> <20061002221429.GA16110@aloha.net> Message-ID: <004F127B-444C-480D-A401-340AF2C8E397@altinity.com> On 2 Oct 2006, at 23:14, O'Shaughnessy Evans wrote: > Ton Voon wrote: >> Thanks for the plugin, and wanting to share it. >> >> We're not accepting new plugins at the moment for inclusion into the >> distribution. Can you post it onto NagiosExchange? http:// >> nagiosexchange.org >> . This is the official 3rd party repository, so users will find it >> there. > > Thanks for the replies. I've added it to nagiosexchange.org. Is > there > a way to change the category that the plugin is listed under, though? > I seem to have created it under Misc, but it should probably be under > Networking. I'd speak to the Netways guys if there's something you cannot do in the interface as they look after that. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Oct 9 12:21:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 03:21:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573638 ] check_swap SEGV's on Solaris 10 Message-ID: Bugs item #1573638, was opened at 2006-10-09 10:21 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=1573638&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap SEGV's on Solaris 10 Initial Comment: $ ./check_swap -w 20% -c 10% swapctl failed: : Bad address Segmentation Fault(coredump) $ uname -a SunOS xxxx 5.10 Generic_118833-18 sun4u sparc SUNW,Sun-Fire-V440 This is from "nagios-plugins-HEAD-200610082352.tar.gz" It seems to compile ok: === if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagios2cl/package/usr/local/nagios2cl/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/sfw//include -I/usr/sfw//include -g -O2 -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo" -c -o check_swap.o check_swap.c; \ then mv -f ".deps/check_swap.Tpo" ".deps/check_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi In file included from check_swap.c:33: common.h:216: warning: static declaration of 'floorf' follows non-static declaration /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/sfw/lib -L. -L/usr/sfw//lib -o check_swap check_swap.o -lm utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lsocket -lssl -lcrypto gcc -g -O2 -o check_swap check_swap.o utils.o popen.o -L/usr/sfw/lib -L/tmp/nagios-plugins-HEAD-200610082352/plugins -L/usr/sfw//lib -lm ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lssl -lcrypto === This appears to be the code at issue ( the SVR4 flag is in effect rather than the BSD one) # ifdef CHECK_SWAP_SWAPCTL_SVR4 /* get the number of active swap devices */ nswaps=swapctl(SC_GETNSWP, NULL); /* initialize swap table + entries */ tbl=(swaptbl_t*)malloc(sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); memset(tbl, 0, sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); tbl->swt_n=nswaps; for(i=0;iswt_ent[i]; ent->ste_path=(char*)malloc(sizeof(char)*MAXPATHLEN); } /* and now, tally 'em up */ swapctl_res=swapctl(SC_LIST, tbl); if(swapctl_res < 0){ perror(_("swapctl failed: ")); result = STATE_WARNING; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573638&group_id=29880 From noreply at sourceforge.net Mon Oct 9 12:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 03:27:41 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1495828 ] pst3 failure on solaris 10 x86 Message-ID: Bugs item #1495828, was opened at 2006-05-27 01:40 Message generated for change (Comment added) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1495828&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: edward dertouzas (ophten) Assigned to: Nobody/Anonymous (nobody) Summary: pst3 failure on solaris 10 x86 Initial Comment: https://sourceforge.net/tracker/index.php?func=detail&aid=1476451&group_id=29880&atid=397597 check_procs fails on Solaris 10 x86: root at infdb4.prodqa.coremetrics.com # ./check_procs -vvv CMD: /usr/local/nagios_new/libexec/pst3 CRITICAL - Plugin timed out after 10 seconds truss shows this just spinning through a read, finding nothing, then eventually trapping a SIGALRM. Onward! root at infdb4.prodqa.coremetrics.com # /usr/local/nagios_new/libexec/pst3 /usr/local/nagios_new/libexec/pst3: /dev/ksyms is not a 32-bit kernel namelist pst3: Failed to open kernel memory: Error 0 It appears we're using a 32-bit version of libkvm. I assume the generic /usr/lib/libkvm.so is a 32-bit version while /usr/lib/amd64/libkvm.so is 64-bit. At least the ELF class for libkvm.so is 64-bit. I can't seem to find the write linking magic to make this work. ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2006-10-09 10:27 Message: Logged In: YES user_id=865292 This problem also occurs on Solaris 10 (06/06) sparc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1495828&group_id=29880 From noreply at sourceforge.net Mon Oct 9 14:34:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 05:34:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573700 ] check_swap on HP-UX incorrect Message-ID: Bugs item #1573700, was opened at 2006-10-09 14:34 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=1573700&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dick van den Burg (vandenburgd) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap on HP-UX incorrect Initial Comment: The command that is generated by configure for checking swap on HP-UX is "swapinfo -dfM," and it should be "swapinfo -dfM" (without trailing comma). check_swap now always returns "SWAP WARNING - 100% free (0 MB out of 0 MB) |swap=0MB;0;0;0;0" because it can not interpret the error message generated by the spurious ',' The error is most likely caused by a spurious "'" at line 1754 of configure.in and is propagated to line 42278 of configure in cersion 1.43 of nagios_plugins. A quik workaround is to manually change the SWAP_COMMAND in config.h after configuration. Dick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573700&group_id=29880 From noreply at sourceforge.net Mon Oct 9 15:08:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 06:08:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1373801 ] check_ping timeout on Mandrake 10.1 Message-ID: Bugs item #1373801, was opened at 2005-12-05 15:01 Message generated for change (Comment added) made by alex_b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1373801&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Burger (alex_b) Assigned to: Ton Voon (tonvoon) Summary: check_ping timeout on Mandrake 10.1 Initial Comment: With Mandrake 10.1 and nagios-plugins-1.4 I had a problem where devices that were down would return a result of 'plugin timed out'. The attached patch fixes the problem by adding 2 seconds to the alarm() call. The problem was that Nagios passed a timeout value of 10 seconds to the plugin. The plugin would then call ping with a timeout of 10 seconds (PING_HAS_TIMEOUT is defined). This would cause the plugin to abort before it got the result from the ping command. Adding 2 seconds to alarm will cause it to abort the plugin after 12 seconds which will give ping enough time to respond. It may be better to reduce the timeout value passed to ping. For example, instead of: # ifdef PING_HAS_TIMEOUT asprintf (&cmd, rawcmd, timeout_interval, max_packets, addresses[i]); # else use: # ifdef PING_HAS_TIMEOUT if (timeout_interval > 2) asprintf (&cmd, rawcmd, timeout_interval-2, max_packets, addresses[i]); else asprintf (&cmd, rawcmd, timeout_interval, max_packets, addresses[i]); # else ---------------------------------------------------------------------- >Comment By: Alex Burger (alex_b) Date: 2006-10-09 09:08 Message: Logged In: YES user_id=85836 I think max(1,(timeout_interval-1))/number of addresses would be a good idea. The help screen could be updated to say: -t, --timeout=INTEGER Seconds before connection times out (default: 10) Note: If multiple host addresses are specified, the ping timeout for each host is timeout / # of hosts. Alex This should be mentioned in the help screen for the plugin so users know that the timeout is split evenly between all the addresses to ping. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-03-23 06:24 Message: Logged In: YES user_id=664364 Alex, Thanks for the report. It seems to me that there are two things going on here: 1. a timeout could be placed on each ping command 2. an overall timeout of the plugin, timeout_interval I'm not keen on your suggestion of just bumping timeout_interval by 2, so I think what we need to do is calculate the timeout for each ping command. This is complicated by the fact that you can specify a number of addresses to ping. I'm guessing each individual ping command should have a timeout of max(1, (timeout_interval-1))/number of addresses. There's also a bit of code which alters the timeout_interval based on the number of packets requested and the critical rta threshold: max_seconds = crta / 1000.0 * max_packets + max_packets; if (max_seconds > timeout_interval) timeout_interval = (int)max_seconds; I'm really not keen on this because I think the timeout_interval should be fixed to whatever has been specified on the command line. I'm not sure what the best way to proceed is. Any other opinions? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1373801&group_id=29880 From noreply at sourceforge.net Mon Oct 9 15:10:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 06:10:42 -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 (Comment added) made by alex_b 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 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: 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 kuhlmeier at riege.com Mon Oct 9 17:18:16 2006 From: kuhlmeier at riege.com (Dennis Kuhlmeier) Date: Mon, 09 Oct 2006 17:18:16 +0200 Subject: [Nagiosplug-devel] Segmentation Fault in check_http Message-ID: <452A6838.5010006@riege.com> Hi there, in check_http from nagios-plugins-1.4.3-1 I receive a segmentation fault if a file does not exist when calling ./check_http -H host -u /dir/file -N -f follow (same without -N) Unluckily this is interpreted as OK by Nagios. Any fixes for that? Tnx! -------------- next part -------------- A non-text attachment was scrubbed... Name: kuhlmeier.vcf Type: text/x-vcard Size: 306 bytes Desc: not available URL: From noreply at sourceforge.net Tue Oct 10 14:06:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Oct 2006 05:06:42 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 Message generated for change (Comment added) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Tobias Mucke (mucke) Date: 2006-10-10 14:06 Message: Logged In: YES user_id=481892 Hi tonvoon, today I checked the actual release 1.4.3. But the problem still persists. Here is what check_disk prints to stdout. The ext2 filesystem /boot is ok. All others are reiserfs. :-( DISK OK - free space:| /=118MB;818;920;-2147483648;1023 /boot=14MB;103;116;99;129 /home=192MB;818;920;-2147483648;1023 /opt=550MB;1637;1842;-2147483648;2047 /srv=57MB;408;459;-2147483648;511 /tmp=144MB;818;920;-2147483648;1023 /usr=731MB;1637;1842;-2147483648;2047 /usr/local=44MB;408;459;-2147483648;511 /var=167MB;818;920;-2147483648;1023 /var/tmp=61MB;818;818;-2147483648;1023 Thanks Tobias ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-08-17 13:31 Message: Logged In: YES user_id=481892 Hi, sorry that I could not test the newest version earlier but yesterday I did. The problem with it is, that we use the performance data output to update rrd files. Besides the actual value we also read the warning and critical threshold, the min and max value. In the new version these are gone. This is the output from the actual version I tested. > ./check_disk (nagios-plugins 1.4.3) 1.75 > ./check_disk -w 10% -c 5% -p /home DISK OK - free space: /home 1720 MB (41% inode=-);| /home=2375MB;;; Maybe you could just check if min is lower than 0 and than set it to zero? Thanks again. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 01:15 Message: Logged In: YES user_id=664364 Tobias, Can you please try the latest snapshot? The min value has been removed (which is one way of fixing your original problem :) ). But the values calculated should now be consistent with df output. The inode value will be printed as "-" which is consistent with df -i. Ton ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-06-19 07:43 Message: Logged In: YES user_id=481892 Hi everybody, sorry, since I am not a C programmer I can't figure out the problem, but it still persists. Tried newest plugin version. ~> /opt/nagios/plugins/check_disk --version check_disk (nagios-plugins 1.4.3) 1.67 ~> /opt/nagios/plugins/check_disk -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;511;511;-2147483648;511 I reopend the call again. Thanks. Tobias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-06-15 09:52 Message: Logged In: YES user_id=664364 Hi all! The patch by Ralph is already applied to CVS in check_disk.c v1.67. Please try the snapshot at http://nagiosplug.sf.net/snapshot. I'm putting this call into pending. Ton ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-06-15 09:12 Message: Logged In: YES user_id=1526665 Hi everybody! I have similar problem on FreeBSD 6.1 with check_disk.c,v 1.64 2006/03/27 08:19:01 Ralph R??ner patch solved this problem. ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-18 11:28 Message: Logged In: YES user_id=481892 Hi everybody, checked out newest snapshot 20060517 but same problem. Tobias ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-05-08 20:08 Message: Logged In: YES user_id=1515003 Hi everybody! I have a similar problem on Solaris, only I get bitten by validate_arguments(), which complains that "C_IDFP (67065044...467904.000000) should be less than W_IDFP (0.0)". It appears that the minimum free inode percentage was not correctly initialized. This only appears when file systems are selected with "-p". The reason I suspect is that the c_idfp and w_idfp members of the path list structure are never initialized in this case, at least not at the point where c_dfp and w_dfp are (check_disk.c lines 457ff). So random malloc()ed memory is passed to validate_arguments(), and the results vary according to architecture and phase of the moon. I created a patch that treats the [cw]_idfp like [cw]_dfp at the point where the "-p" argument is parsed. This makes the problem go away for me. If there are other places where the path list is added to then there is a good chance that the same oversight happened there too. Since I don't find a way to attach a file to a thread I did not open, I will include the patch here: --8><----------------------------------- *** nagios-plugins-1.4.3/plugins/check_disk.c.orig Mon May 8 19:50:33 2006 --- nagios-plugins-1.4.3/plugins/check_disk.c Mon May 8 19:49:48 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; --8><----------------------------------- Hope this helps, Ralph R??ner ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-05 16:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 10:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From tony at tuxick.net Tue Oct 10 14:31:34 2006 From: tony at tuxick.net (Tony den Haan) Date: Tue, 10 Oct 2006 14:31:34 +0200 Subject: [Nagiosplug-devel] Fwd: fixed check_snmp.c:341: parse error before `char' Message-ID: <200610101431.34639.tony@tuxick.net> hi, i've been wondering why compiling nagios-plugins kept throwing "check_snmp.c:341: parse error before `char'". it took me a few minutes to realise this is not c++, simply moving the declaration up to join the rest at beginning of the function fixed this rather confusing parse error. tony From noreply at sourceforge.net Wed Oct 11 00:28:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Oct 2006 15:28:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1574863 ] check_real does not accept the '-v' option Message-ID: Bugs item #1574863, was opened at 2006-10-10 22:28 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=1574863&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: check_real does not accept the '-v' option Initial Comment: The help message for check_real says that '-v' is a valid option, but it is not recognized by the plugin: $ plugins/check_real -h | grep -A 1 -- '-v,' -v, --verbose Show details for command-line debugging (Nagios may truncate output) $ plugins/check_real -v plugins/check_real: invalid option -- v check_real: Unknown argument - (null) Usage:check_real -H host [-e expect] [-p port] [-w warn] [-c crit] [-t timeout] [-v] Attached is a patch against CVS to recognize the '-v' option. Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1574863&group_id=29880 From noreply at sourceforge.net Wed Oct 11 00:29:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Oct 2006 15:29:34 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1574863 ] check_real does not accept the '-v' option Message-ID: Bugs item #1574863, was opened at 2006-10-10 22:28 Message generated for change (Settings changed) made by cgrim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1574863&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None >Priority: 1 Submitted By: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: check_real does not accept the '-v' option Initial Comment: The help message for check_real says that '-v' is a valid option, but it is not recognized by the plugin: $ plugins/check_real -h | grep -A 1 -- '-v,' -v, --verbose Show details for command-line debugging (Nagios may truncate output) $ plugins/check_real -v plugins/check_real: invalid option -- v check_real: Unknown argument - (null) Usage:check_real -H host [-e expect] [-p port] [-w warn] [-c crit] [-t timeout] [-v] Attached is a patch against CVS to recognize the '-v' option. Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1574863&group_id=29880 From ton.voon at altinity.com Thu Oct 12 14:35:09 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 12 Oct 2006 13:35:09 +0100 Subject: [Nagiosplug-devel] Release 1.4.4 Message-ID: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> Hi! I want to get a release a 1.4.4 out because there's lots of good stuff currently in CVS HEAD and I keep referring people to use that, so we might as well release it. I've got to add in perf data back into check_disk, but that is probably the only item that is outstanding on my list. Is there anything else that needs to be done for the next release? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From andi at rz.hvb.sozvers.at Thu Oct 12 15:14:23 2006 From: andi at rz.hvb.sozvers.at (Andreas Behal) Date: Thu, 12 Oct 2006 15:14:23 +0200 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> Message-ID: <452E3FAF.80702@rz.hvb.sozvers.at> Hi, well - if you mention check_disk: As the 'stable' version from check_disk didn't work for me on AIX I decided to compile the HEAD-CVS which was much better, but still had one Bug concerning the -e (only show errors) flag, which never showed any errors. I think this is due to some confusion with disk_result, result and tmp_result: bash#> grep disk_result nagios-plugins-HEAD-200610121152/plugins/check_disk.c > > int disk_result = STATE_UNKNOWN; > if (disk_result==STATE_OK && erronly && !verbose) > if (disk_result!=STATE_OK || verbose>=0) { So, disk_result is set only once and never touched after. I have made a patch that works for me (do not hit me If i get something totally wrong - I'm on this list since yesterday ..) best regards, Andreas --- nagios-plugins-HEAD-200610102352/plugins/check_disk.c 2006-08-14 11:04:16.000000000 +0200 +++ nagios-plugins-HEAD-200610102352/plugins/check_disk.c.new 2006-10-11 11:33:14.000000000 +0200 @@ -206,6 +206,10 @@ /* Process for every path in list */ for (path = path_select_list; path; path=path->name_next) { + + /* reset the disk result */ + disk_result = STATE_UNKNOWN; + me = path->best_match; /* Filters */ @@ -258,23 +262,25 @@ temp_result = get_status(dfree_units, path->freespace_units); if (verbose >=3) printf("Freespace_units result=%d\n", temp_result); - result = max_state( result, temp_result ); + disk_result = max_state( disk_result, temp_result ); temp_result = get_status(dfree_pct, path->freespace_percent); if (verbose >=3) printf("Freespace%% result=%d\n", temp_result); - result = max_state( result, temp_result ); + disk_result = max_state( disk_result, temp_result ); temp_result = get_status(dused_units, path->usedspace_units); if (verbose >=3) printf("Usedspace_units result=%d\n", temp_result); - result = max_state( result, temp_result ); + disk_result = max_state( disk_result, temp_result ); temp_result = get_status(dused_pct, path->usedspace_percent); if (verbose >=3) printf("Usedspace_percent result=%d\n", temp_result); - result = max_state( result, temp_result ); + disk_result = max_state( disk_result, temp_result ); temp_result = get_status(dused_inodes_percent, path->usedinodes_percent); if (verbose >=3) printf("Usedinodes_percent result=%d\n", temp_result); - result = max_state( result, temp_result ); + disk_result = max_state( disk_result, temp_result ); + + result = max_state(result, disk_result); asprintf (&perf, "%s %s", perf, perfdata ((!strcmp(me->me_mountdir, "none") || display_mntp) ? me->me_devname : me->me_mountdir, Ton Voon wrote: > Hi! > > I want to get a release a 1.4.4 out because there's lots of good stuff > currently in CVS HEAD and I keep referring people to use that, so we > might as well release it. > > I've got to add in perf data back into check_disk, but that is > probably the only item that is outstanding on my list. Is there > anything else that needs to be done for the next release? From seanius at seanius.net Thu Oct 12 15:36:21 2006 From: seanius at seanius.net (sean finney) Date: Thu, 12 Oct 2006 15:36:21 +0200 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> Message-ID: <1160660181.30722.5.camel@localhost> hey ton, On Thu, 2006-10-12 at 13:35 +0100, Ton Voon wrote: > I want to get a release a 1.4.4 out because there's lots of good stuff > currently in CVS HEAD and I keep referring people to use that, so we > might as well release it. +1 fyi, debian/etch will be freezing really really soon now, so it'd be nice if we could get that in there too. not a big deal if we don't though, since the latest version is based off of a cvs snapshot from a couple months ago (thus it already has most of the fixes/improvements). > I've got to add in perf data back into check_disk, but that is > probably the only item that is outstanding on my list. Is there > anything else that needs to be done for the next release? iirc, there was a problem with the new check_ntp and the jitter checking, but i haven't had the time to go back and verify it. 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 ton.voon at altinity.com Thu Oct 12 16:15:20 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 12 Oct 2006 15:15:20 +0100 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <452E3FAF.80702@rz.hvb.sozvers.at> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> <452E3FAF.80702@rz.hvb.sozvers.at> Message-ID: Andreas, Thanks for the report and the patch. I've added a test in plugins/t/ check_disk.t so we should catch this in future. The behaviour is, with -e, if everything is OK, only show "DISK OK". Otherwise to only show output on failure. Perf data will always be returned for all disks. Ton On 12 Oct 2006, at 14:14, Andreas Behal wrote: > Hi, > > well - if you mention check_disk: > > As the 'stable' version from check_disk didn't work for me on AIX I > decided to compile the HEAD-CVS which was much better, but still > had one > Bug concerning the -e (only show errors) flag, which never showed any > errors. > > I think this is due to some confusion with disk_result, result and > tmp_result: > > bash#> grep disk_result > nagios-plugins-HEAD-200610121152/plugins/check_disk.c >> >> int disk_result = STATE_UNKNOWN; >> if (disk_result==STATE_OK && erronly && !verbose) >> if (disk_result!=STATE_OK || verbose>=0) { > > So, disk_result is set only once and never touched after. I have > made a > patch that works for me (do not hit me If i get something totally > wrong > - I'm on this list since yesterday ..) > > best regards, > > Andreas > > > --- nagios-plugins-HEAD-200610102352/plugins/check_disk.c > 2006-08-14 11:04:16.000000000 +0200 > +++ nagios-plugins-HEAD-200610102352/plugins/check_disk.c.new > 2006-10-11 11:33:14.000000000 +0200 > @@ -206,6 +206,10 @@ > > /* Process for every path in list */ > for (path = path_select_list; path; path=path->name_next) { > + > + /* reset the disk result */ > + disk_result = STATE_UNKNOWN; > + > me = path->best_match; > > /* Filters */ > @@ -258,23 +262,25 @@ > > temp_result = get_status(dfree_units, path->freespace_units); > if (verbose >=3) printf("Freespace_units result=%d\n", > temp_result); > - result = max_state( result, temp_result ); > + disk_result = max_state( disk_result, temp_result ); > > temp_result = get_status(dfree_pct, path->freespace_percent); > if (verbose >=3) printf("Freespace%% result=%d\n", > temp_result); > - result = max_state( result, temp_result ); > + disk_result = max_state( disk_result, temp_result ); > > temp_result = get_status(dused_units, path->usedspace_units); > if (verbose >=3) printf("Usedspace_units result=%d\n", > temp_result); > - result = max_state( result, temp_result ); > + disk_result = max_state( disk_result, temp_result ); > > temp_result = get_status(dused_pct, path->usedspace_percent); > if (verbose >=3) printf("Usedspace_percent result=%d\n", > temp_result); > - result = max_state( result, temp_result ); > + disk_result = max_state( disk_result, temp_result ); > > temp_result = get_status(dused_inodes_percent, > path->usedinodes_percent); > if (verbose >=3) printf("Usedinodes_percent result=%d\n", > temp_result); > - result = max_state( result, temp_result ); > + disk_result = max_state( disk_result, temp_result ); > + > + result = max_state(result, disk_result); > > asprintf (&perf, "%s %s", perf, > perfdata ((!strcmp(me->me_mountdir, "none") || > display_mntp) ? me->me_devname : me->me_mountdir, > > > > > > Ton Voon wrote: >> Hi! >> >> I want to get a release a 1.4.4 out because there's lots of good >> stuff >> currently in CVS HEAD and I keep referring people to use that, so we >> might as well release it. >> >> I've got to add in perf data back into check_disk, but that is >> probably the only item that is outstanding on my list. Is there >> anything else that needs to be done for the next release? > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________________ > 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 > > > This message has been scanned for viruses by MailController - > www.MailController.altohiway.com http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Thu Oct 12 16:51:01 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 12 Oct 2006 15:51:01 +0100 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <1160660181.30722.5.camel@localhost> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> <1160660181.30722.5.camel@localhost> Message-ID: <5B6F0176-1DA6-4DD6-AC6F-DBD8A7307A23@altinity.com> On 12 Oct 2006, at 14:36, sean finney wrote: >> I've got to add in perf data back into check_disk, but that is >> probably the only item that is outstanding on my list. Is there >> anything else that needs to be done for the next release? > > iirc, there was a problem with the new check_ntp and the jitter > checking, but i haven't had the time to go back and verify it. Sean, I've had a play with check_ntp and fixed one problem where server not responding was not failing correctly. If you could have a play with the jitter, that would be great. I want to publicise the new check_ntp as a feature of this release. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at CIS.FU-Berlin.DE Thu Oct 12 20:26:55 2006 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Thu, 12 Oct 2006 20:26:55 +0200 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> Message-ID: <20061012182655.GZ9493@CIS.FU-Berlin.DE> * Ton Voon [2006-10-12 13:35]: > Is there anything else that needs to be done for the next release? Well, we have a minor issue with check_smtp -- using Exim, checking SMTP AUTH via TLS doesn't work without the patch I attached at: http://sf.net/tracker/?func=detail&aid=1482832&group_id=29880&atid=397597 Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE From noreply at sourceforge.net Thu Oct 12 22:37:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Oct 2006 13:37:16 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1482832 ] check_smtp problem with TLS+AUTH using Exim Message-ID: Bugs item #1482832, was opened at 2006-05-06 02:49 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482832&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Holger Wei? (hweiss) >Assigned to: Ton Voon (tonvoon) Summary: check_smtp problem with TLS+AUTH using Exim Initial Comment: When checking SMTP AUTH via TLS using Exim, you'll get a "503 AUTH command used when not advertised" error if trying to use AUTH without (re)sending EHLO _after_ the TLS negotiation. RFC 3207 (4.2) says: "The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation." The attached patch does just that in order to make the check_smtp plugin work with TLS+AUTH using Exim. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-12 21:37 Message: Logged In: YES user_id=664364 Holger, Thanks for the patch. Added to CVS. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1482832&group_id=29880 From ton.voon at altinity.com Thu Oct 12 22:37:53 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 12 Oct 2006 21:37:53 +0100 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <20061012182655.GZ9493@CIS.FU-Berlin.DE> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> <20061012182655.GZ9493@CIS.FU-Berlin.DE> Message-ID: On 12 Oct 2006, at 19:26, Holger Weiss wrote: > * Ton Voon [2006-10-12 13:35]: >> Is there anything else that needs to be done for the next release? > > Well, we have a minor issue with check_smtp -- using Exim, checking > SMTP > AUTH via TLS doesn't work without the patch I attached at: > > http://sf.net/tracker/? > func=detail&aid=1482832&group_id=29880&atid=397597 > Holger, Thanks for raising this. Looks okay. Added to CVS. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.mortier at opensides.be Thu Oct 12 23:16:26 2006 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Thu, 12 Oct 2006 23:16:26 +0200 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> Message-ID: <200610122316.26972.benoit.mortier@opensides.be> Le Jeudi 12 Octobre 2006 14:35, Ton Voon a ?crit?: > Hi! > > I want to get a release a 1.4.4 out because there's lots of good > stuff currently in CVS HEAD and I keep referring people to use that, > so we might as well release it. Hi, in wich time frame do you want to release it, i have to finish cleaning the localizaion stuff ;-) Plugins in french are popular here ;-) I could work on it this week-end or early next week .. Cheers -- Benoit Mortier CEO www.opensides.be From ton.voon at altinity.com Fri Oct 13 09:52:59 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 13 Oct 2006 08:52:59 +0100 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: <200610122316.26972.benoit.mortier@opensides.be> References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> <200610122316.26972.benoit.mortier@opensides.be> Message-ID: On 12 Oct 2006, at 22:16, Benoit Mortier wrote: > Le Jeudi 12 Octobre 2006 14:35, Ton Voon a ?crit : >> Hi! >> >> I want to get a release a 1.4.4 out because there's lots of good >> stuff currently in CVS HEAD and I keep referring people to use that, >> so we might as well release it. > > Hi, > > in wich time frame do you want to release it, i have to finish > cleaning the > localizaion stuff ;-) > > Plugins in french are popular here ;-) > > I could work on it this week-end or early next week .. > OK. Can I say "Next Thursday"? One thing about the latest CVS: in my quest to make it more like the coreutils code, I notice that coreutils do not ship gettext in their tarball, so I've made the plugins the same. This means that localisation is only on systems that already have gettext installed. That would include all linux distributions, but others may not (configure should pick it out correctly). Is this a problem? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.mortier at opensides.be Sun Oct 15 00:51:50 2006 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Sun, 15 Oct 2006 00:51:50 +0200 Subject: [Nagiosplug-devel] Release 1.4.4 In-Reply-To: References: <87DC7D3E-7951-4778-A81F-8B7B4B45802E@altinity.com> <200610122316.26972.benoit.mortier@opensides.be> Message-ID: <200610150051.50976.benoit.mortier@opensides.be> Le Vendredi 13 Octobre 2006 09:52, Ton Voon a ?crit?: > On 12 Oct 2006, at 22:16, Benoit Mortier wrote: > > Le Jeudi 12 Octobre 2006 14:35, Ton Voon a ?crit : > >> Hi! > >> > >> I want to get a release a 1.4.4 out because there's lots of good > >> stuff currently in CVS HEAD and I keep referring people to use that, > >> so we might as well release it. > > > > Hi, > > > > in wich time frame do you want to release it, i have to finish > > cleaning the > > localizaion stuff ;-) > > > > Plugins in french are popular here ;-) > > > > I could work on it this week-end or early next week .. > > OK. Can I say "Next Thursday"? deal ;-) > One thing about the latest CVS: in my quest to make it more like the > coreutils code, I notice that coreutils do not ship gettext in their > tarball, so I've made the plugins the same. This means that > localisation is only on systems that already have gettext installed. > That would include all linux distributions, but others may not > (configure should pick it out correctly). Is this a problem? Normaily i think not . Cheers -- Benoit Mortier CEO www.opensides.be From gavin at openfusion.com.au Mon Oct 16 13:13:50 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Mon, 16 Oct 2006 21:13:50 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file Message-ID: <20061016111350.GB15099@openfusion.com.au> I've got a perl nagios plugin that performs arbitrary queries against a database and reports status codes based on the number of rows returned i.e. Usage: check_db_query_rowcount [-v] -q -w -c -d -u -p An obvious security problem with this is that the user must pass the database credentials on the command line, which typically means they're exposed to any local users via the process list for however long the plugin executes. This must be a problem for lots of other kinds of plugin too - anywhere you need to pass any kind of secret to a plugin. Is there a good way of dealing with this that I'm not aware of? My suggestion is that we introduce a config file specifically for use by plugins (e.g. /etc/nagios/plugins.cfg or $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we don't want to have to pass at the command line. Perhaps an INI-style format would make sense, with per-plugin sections, or arbitrary section names specified explicitly e.g. [ check_db_query_rowcount ] dsn = db:Pg:database=foo user = fred pass = secret or perhaps if I want to check multiple different databases, or share the credentials across plugins: [ foo_db ] dsn = db:Pg:database=foo user = fred pass = secret Then my plugin could have a usage pattern like this: Usage: check_db_query_rowcount [-v] -q -w -c [--auth=] where auth-section might default to the plugin name if not specified (and the plugin would fail if an appropriate auth section could not be found). Thoughts/comments? Cheers, Gavin -- Gavin Carr Open Fusion - Open Source Business Solutions [ Linux - Perl - Apache ] http://www.openfusion.com.au - Fashion is a variable, but style is a constant - Programming Perl From ae at op5.se Mon Oct 16 13:25:46 2006 From: ae at op5.se (Andreas Ericsson) Date: Mon, 16 Oct 2006 13:25:46 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061016111350.GB15099@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> Message-ID: <45336C3A.5030107@op5.se> Gavin Carr wrote: > I've got a perl nagios plugin that performs arbitrary queries against > a database and reports status codes based on the number of rows > returned i.e. > > Usage: check_db_query_rowcount [-v] -q -w > -c -d -u -p > > An obvious security problem with this is that the user must pass the > database credentials on the command line, which typically means > they're exposed to any local users via the process list for however > long the plugin executes. > > This must be a problem for lots of other kinds of plugin too - > anywhere you need to pass any kind of secret to a plugin. Is there a > good way of dealing with this that I'm not aware of? > > My suggestion is that we introduce a config file specifically for use > by plugins (e.g. /etc/nagios/plugins.cfg or > $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we > don't want to have to pass at the command line. Perhaps an INI-style > format would make sense, with per-plugin sections, or arbitrary > section names specified explicitly e.g. > > [ check_db_query_rowcount ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > or perhaps if I want to check multiple different databases, or share > the credentials across plugins: > > [ foo_db ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > Then my plugin could have a usage pattern like this: > > Usage: check_db_query_rowcount [-v] -q -w > -c [--auth=] > > where auth-section might default to the plugin name if not specified > (and the plugin would fail if an appropriate auth section could not > be found). > > Thoughts/comments? > If an attacker has access to your system in a way that lets them list processes of any arbitrary user, I fail to see how you could protect this configuration file in a sane way. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From benoit.mortier at opensides.be Mon Oct 16 13:26:19 2006 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Mon, 16 Oct 2006 13:26:19 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061016111350.GB15099@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> Message-ID: <200610161326.20533.benoit.mortier@opensides.be> Le Lundi 16 Octobre 2006 13:13, Gavin Carr a ?crit?: > I've got a perl nagios plugin that performs arbitrary queries against > a database and reports status codes based on the number of rows > returned i.e. > > Usage: check_db_query_rowcount [-v] -q -w > -c -d -u -p > > An obvious security problem with this is that the user must pass the > database credentials on the command line, which typically means > they're exposed to any local users via the process list for however > long the plugin executes. > > This must be a problem for lots of other kinds of plugin too - > anywhere you need to pass any kind of secret to a plugin. Is there a > good way of dealing with this that I'm not aware of? Hello, i think it's a great idea I'am all for it .. Cheers -- Benoit Mortier CEO www.opensides.be From william at elan.net Mon Oct 16 15:36:52 2006 From: william at elan.net (william(at)elan.net) Date: Mon, 16 Oct 2006 06:36:52 -0700 (PDT) Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <45336C3A.5030107@op5.se> References: <20061016111350.GB15099@openfusion.com.au> <45336C3A.5030107@op5.se> Message-ID: On Mon, 16 Oct 2006, Andreas Ericsson wrote: > If an attacker has access to your system in a way that lets them list > processes of any arbitrary user, I fail to see how you could protect > this configuration file in a sane way. Common way to deal with this is to have option that reads additional arguments from specified file, i.e. it would be: Usage: check_db_query_rowcount [-v] -q -w -c [--config ] where the file would contain -d -u user> -p Another option is to have environment variables but not actually expand during call, i.e. check_db_query_rowcount -p '$DB_PASS' -u '$DB_USER' ... Be carefull though to only read passed shell variables and not allow reading actual variables used in program. The processing of command-line options in one or both ways above could potentially be done be done by optional plugin library and not something each plugin writer has to worry about - this would in fact make it simple to further expand to common format config file for plugins. -- William Leibzon Elan Networks william at elan.net From ton.voon at altinity.com Mon Oct 16 15:46:09 2006 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 16 Oct 2006 14:46:09 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061016111350.GB15099@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> Message-ID: On 16 Oct 2006, at 12:13, Gavin Carr wrote: > I've got a perl nagios plugin that performs arbitrary queries against > a database and reports status codes based on the number of rows > returned i.e. > > Usage: check_db_query_rowcount [-v] -q -w > -c -d -u -p > > An obvious security problem with this is that the user must pass the > database credentials on the command line, which typically means > they're exposed to any local users via the process list for however > long the plugin executes. > > This must be a problem for lots of other kinds of plugin too - > anywhere you need to pass any kind of secret to a plugin. Is there a > good way of dealing with this that I'm not aware of? If you run mysql (I'm on 4.1.11) with -u user -ppassword, the process table will have the password blanked out. I've done that in C (see check_mysql_query), but I don't know how to do that in perl. Would that be sufficient? > My suggestion is that we introduce a config file specifically for use > by plugins (e.g. /etc/nagios/plugins.cfg or > $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we > don't want to have to pass at the command line. Perhaps an INI-style > format would make sense, with per-plugin sections, or arbitrary > section names specified explicitly e.g. > > [ check_db_query_rowcount ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > or perhaps if I want to check multiple different databases, or share > the credentials across plugins: > > [ foo_db ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > Then my plugin could have a usage pattern like this: > > Usage: check_db_query_rowcount [-v] -q -w > -c [--auth=] > > where auth-section might default to the plugin name if not specified > (and the plugin would fail if an appropriate auth section could not > be found). > > Thoughts/comments? A design principle I've been following, although it is undocumented and I'm all for starting a discussion about it again, is that plugins should run without any knowledge of state (I think the check_log plugin might break this - I haven't worked closely on that one). A config file for passwords doesn't sound necessary. However, I guess this is no different from mysql having a my.cnf file, so I don't think security gets any worse. My angle is that the userid/password used should only have just enough access to do the necessary check and no more. That would be an application issue, not a plugin one. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Mon Oct 16 16:23:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Oct 2006 07:23:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1578214 ] check_procs from crashes on Itanium2 SLES10 Message-ID: Bugs item #1578214, was opened at 2006-10-16 16:23 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=1578214&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: wszenajch (wszenajch) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs from crashes on Itanium2 SLES10 Initial Comment: check_procs from HEAD-20061015 build crashes on Itanium2 SLES10. Line192: procprog = base_name(procprog); of check_procs.c is used incorrectly. With this line as it is compilation gives the following warning on all tested by me platforms: OpenSuSE 10.1 i386, SuSE 10.0 x86_64, SLES10 ia64, AIX 5.2: check_procs.c: In function `main': check_procs.c:192: warning: assignment makes pointer from integer without a cast but crashes only on Itanium2 platform. To fix problem comment out line: procprog = base_name(procprog); or use construction from 1.4.3 plugins (which was probably not active): main ... ... char *temp_string; ... temp_string = strdup(procprog); procprog = basename(temp_string); According to man 3 basename: "Both dirname() and basename() may modify the contents of path, so copies should be passed to these functions. Furthermore, dirname() and basename() may return pointers to statically allocated memory whi ch may be overwritten by subsequent calls." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1578214&group_id=29880 From rouilj at cs.umb.edu Mon Oct 16 18:24:40 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon, 16 Oct 2006 12:24:40 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Mon, 16 Oct 2006 21:13:50 +1000." <20061016111350.GB15099@openfusion.com.au> Message-ID: <200610161624.k9GGOeYI013664@mx1.cs.umb.edu> In message <20061016111350.GB15099 at openfusion.com.au>, Gavin Carr writes: > Usage: check_db_query_rowcount [-v] -q -w > -c -d -u -p > >An obvious security problem with this is that the user must pass the >database credentials on the command line, which typically means >they're exposed to any local users via the process list for however >long the plugin executes. > >This must be a problem for lots of other kinds of plugin too - >anywhere you need to pass any kind of secret to a plugin. Is there a >good way of dealing with this that I'm not aware of? The way I do it is to use a small shell script to parse a password config file and create a temp file. Then I pass the temp file to the plugin. Obviously this works only with my own plugins, but it does allow formatting and other changes. E.G. I can: pass URL's in a file create curl config files create user:passwd authentication formatted entries and the input file tries to reuse plugins's normal authentication mechanism setting the internal variable from a file rather than on the command line. Also I can run the command inside a here document in a shell script and pass password info on stdin to the plugin if it accepts it. wget -i << EOE https://`getpw /password/cache -`@example.com/ EOE which doesn't leave authentication info in the environment or on the command line. >My suggestion is that we introduce a config file specifically for use >by plugins (e.g. /etc/nagios/plugins.cfg or >$NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we >don't want to have to pass at the command line. Perhaps an INI-style >format would make sense, with per-plugin sections, or arbitrary >section names specified explicitly e.g. > > [ check_db_query_rowcount ] > dsn = db:Pg:database=foo > user = fred > pass = secret > >or perhaps if I want to check multiple different databases, or share >the credentials across plugins: > > [ foo_db ] > dsn = db:Pg:database=foo > user = fred > pass = secret > >Then my plugin could have a usage pattern like this: > > Usage: check_db_query_rowcount [-v] -q -w > -c [--auth=] > >where auth-section might default to the plugin name if not specified >(and the plugin would fail if an appropriate auth section could not >be found). Sounds like a good idea and it should be simple enough to code in perl, C, Bourne shell and python for starters. What may be better is for the to be: auth-section:/path/to/auth/file since I can see multiple auth files for different people to maintain (e.g. oracle db's maintain the password for the test users using on their databases). My little getpw script takes: /path/to/file output_file_basename [token] where the credentials (and their output format) are uniquely identified by the file path and the token (where the token is similar to your auth-section). So I can get the updates when the web admins change the manager password on the servers without giving them access to the passwords for other test users in LDAP. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj at cs.umb.edu Mon Oct 16 18:40:29 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon, 16 Oct 2006 12:40:29 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Mon, 16 Oct 2006 06:36:52 PDT." Message-ID: <200610161640.k9GGeTZ7017675@mx1.cs.umb.edu> In message , "william(at)elan.net" writes: > >On Mon, 16 Oct 2006, Andreas Ericsson wrote: > >> If an attacker has access to your system in a way that lets them list >> processes of any arbitrary user, I fail to see how you could protect >> this configuration file in a sane way. > >Common way to deal with this is to have option that reads additional >arguments from specified file, i.e. it would be: > Usage: check_db_query_rowcount [-v] -q -w > -c [--config ] >where the file would contain > -d -u user> -p Yup. Chmod the files mode 400 to the nagios user and delete them afterwards. The stdin trick also works as data in a pipeline/here document isn't readable w/o kernel or process access AFAIK. >Another option is to have environment variables but not actually expand >during call, i.e. > check_db_query_rowcount -p '$DB_PASS' -u '$DB_USER' ... >Be carefull though to only read passed shell variables and not allow >reading actual variables used in program. But if the variables are in the process environment they can still be seen easily. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj at cs.umb.edu Mon Oct 16 19:02:56 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon, 16 Oct 2006 13:02:56 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Mon, 16 Oct 2006 14:46:09 BST." Message-ID: <200610161702.k9GH2ua8023231@mx1.cs.umb.edu> In message , Ton Voon writes: >On 16 Oct 2006, at 12:13, Gavin Carr wrote: > >> I've got a perl nagios plugin that performs arbitrary queries against >> a database and reports status codes based on the number of rows >> returned i.e. >> >> Usage: check_db_query_rowcount [-v] -q -w >> -c -d -u -p >> >> An obvious security problem with this is that the user must pass the >> database credentials on the command line, which typically means >> they're exposed to any local users via the process list for however >> long the plugin executes. >> >> This must be a problem for lots of other kinds of plugin too - >> anywhere you need to pass any kind of secret to a plugin. Is there a >> good way of dealing with this that I'm not aware of? > >If you run mysql (I'm on 4.1.11) with -u user -ppassword, the process >table will have the password blanked out. I've done that in C (see >check_mysql_query), but I don't know how to do that in perl. Would >that be sufficient? The password is available until the application rewrites ARGV, and rewriting ARGV isn't supported on all platforms. So I'd say no. (BTW try writing $ARGV[N] in perl that works IIRC if the platform supports it.) >> My suggestion is that we introduce a config file specifically for use >> by plugins (e.g. /etc/nagios/plugins.cfg or >> $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we >> don't want to have to pass at the command line. > >A design principle I've been following, although it is undocumented >and I'm all for starting a discussion about it again, is that plugins >should run without any knowledge of state (I think the check_log >plugin might break this - I haven't worked closely on that one). A >config file for passwords doesn't sound necessary. Well that depends on what you want to monitor. I wrote tkwatcher specifically to manage prior state to allow testing for things like: * has the value increased/decreased by a certain amount from the previous run? * has the value increased/decreased by a certain percentage from the previous run? * has the value changed or not changed since the last run and I use it to look for things like: did the amount of available space on the disk drop by more than 30%? if 30% of my available disk space just dissapeared in the last 1 minute I need to know about that NOW before I hit the 10% disk threshold because I will run out of disk space (and potentially crash the machine) by the time I respond after the 10% warning. I do have a method for using tkwatcher as a probe for nagios to get the enhanced checking methods available but until my advanced correlation patches for nagios are released I haven't done anything with it. >However, I guess this is no different from mysql having a my.cnf >file, so I don't think security gets any worse. Agreed. >My angle is that the userid/password used should only have just >enough access to do the necessary check and no more. That would be an >application issue, not a plugin one. True, it is an issue with the (monitored) application (or syetm in the case of network load balancer applicanes, remote power control strips etc). Some of the systems/apps I have to authenticate to don't have multiple users or multiple access levels. So I have to have full privs to totally trash the system even though I want to monitor only 10 variables. Also what you want to monitor may not be accessible from the limited access accounts. Even with limited acess accounts the data that is returned may be sensitive and other's shouldn't have access to it. So I always have to have some method of protecting the password in the plugin. Also I still have to use or write a plugin to monitor it which is forked and therefore needs some way to get the protected information. If it has an SSL web interface it would be nice to be able to use check_http -S or other standard plugin. If it has an SNMP interface, would be nice to use check_snmp rather than having to write my own plugin. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From seanius at seanius.net Mon Oct 16 19:06:11 2006 From: seanius at seanius.net (sean finney) Date: Mon, 16 Oct 2006 19:06:11 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061016111350.GB15099@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> Message-ID: <1161018371.30535.8.camel@localhost> hi gavin, On Mon, 2006-10-16 at 21:13 +1000, Gavin Carr wrote: > An obvious security problem with this is that the user must pass the > database credentials on the command line, which typically means > they're exposed to any local users via the process list for however > long the plugin executes. i've brought this up before, actually (though at the time it was regardling snmp auth info, but same problem) > This must be a problem for lots of other kinds of plugin too - > anywhere you need to pass any kind of secret to a plugin. Is there a > good way of dealing with this that I'm not aware of? well, for the db plugin, assuming that it's a mysql program, why not use the built-in functionality for reading in additional mysql ini-format files? it should be possible to say something like check_db_plugin --defaults-file=/etc/mysql/nagiosplugin.cnf where you use getopt to get the defaults-file value, and pass it to the mysql "load_defaults" function with the proper parameters. > My suggestion is that we introduce a config file specifically for use > by plugins (e.g. /etc/nagios/plugins.cfg or > $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we > don't want to have to pass at the command line. Perhaps an INI-style > format would make sense, with per-plugin sections, or arbitrary > section names specified explicitly e.g. i would be rather wary of this, because it's yet another point of configuration/abstraction in an already complicated system. but that's just mho. 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 seanius at seanius.net Mon Oct 16 19:08:02 2006 From: seanius at seanius.net (sean finney) Date: Mon, 16 Oct 2006 19:08:02 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <45336C3A.5030107@op5.se> References: <20061016111350.GB15099@openfusion.com.au> <45336C3A.5030107@op5.se> Message-ID: <1161018482.30535.11.camel@localhost> hey andreas, On Mon, 2006-10-16 at 13:25 +0200, Andreas Ericsson wrote: > If an attacker has access to your system in a way that lets them list > processes of any arbitrary user, I fail to see how you could protect > this configuration file in a sane way. so granted, this is all *mostly* a bunch of theoretical wanking, but the problem is you need a minimal set of permissions to be able to invoke ps to grab environment variables/cmdline options, but without some extra leverage you can't overcome filesystem permissions to read a file chowned to the nagios user. 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 seanius at seanius.net Mon Oct 16 19:13:24 2006 From: seanius at seanius.net (sean finney) Date: Mon, 16 Oct 2006 19:13:24 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: References: <20061016111350.GB15099@openfusion.com.au> <45336C3A.5030107@op5.se> Message-ID: <1161018805.30535.18.camel@localhost> On Mon, 2006-10-16 at 06:36 -0700, william(at)elan.net wrote: > Common way to deal with this is to have option that reads additional > arguments from specified file, i.e. it would be: > Usage: check_db_query_rowcount [-v] -q -w > -c [--config ] > where the file would contain > -d -u user> -p this is a really interesting idea. i especially like it because it's generalizable to any kind of plugin, as long as it implemented that feature. i might suggest "--extra-opts" or similar as an alternative name to "--config" though. > Another option is to have environment variables but not actually expand > during call, i.e. > check_db_query_rowcount -p '$DB_PASS' -u '$DB_USER' ... > Be carefull though to only read passed shell variables and not allow > reading actual variables used in program. unfortunately, no--you can read exported environment variables via ps as well :( > The processing of command-line options in one or both ways above could > potentially be done be done by optional plugin library and not something > each plugin writer has to worry about - this would in fact make it > simple to further expand to common format config file for plugins. yes. though we would have to ensure that calls to process_arguments() and the like were idempotent, or at least combine the two sets of arguments into a single string before calling the function. 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 Thomas at zango.com Mon Oct 16 22:19:21 2006 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 16 Oct 2006 13:19:21 -0700 Subject: [Nagiosplug-devel] [RFC] Plugins config file Message-ID: <804160344192334BB21922E8082EA6C0093BD9@seaex01.180solutions.com> The blank-out workaround does not work on all system as it is usually possible to prevent programs from rewriting their command line. This is a good security feature to prevent rogue programs from renaming themselves to a running daemon (ex a SMTP spambot uploaded in /tmp could rename itself as httpd in a web server). Thomas > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Ton Voon > Sent: October 16, 2006 9:46 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] [RFC] Plugins config file > > > On 16 Oct 2006, at 12:13, Gavin Carr wrote: > > > I've got a perl nagios plugin that performs arbitrary > queries against > a database and reports status codes based on the number of rows > returned i.e. > > Usage: check_db_query_rowcount [-v] -q -w > > -c -d -u -p > > An obvious security problem with this is that the user > must pass the > database credentials on the command line, which typically means > they're exposed to any local users via the process list > for however > long the plugin executes. > > This must be a problem for lots of other kinds of plugin too - > anywhere you need to pass any kind of secret to a > plugin. Is there a > good way of dealing with this that I'm not aware of? > > > If you run mysql (I'm on 4.1.11) with -u user -ppassword, the > process table will have the password blanked out. I've done > that in C (see check_mysql_query), but I don't know how to do > that in perl. Would that be sufficient? > > > My suggestion is that we introduce a config file > specifically for use > by plugins (e.g. /etc/nagios/plugins.cfg or > $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin > parameters we > don't want to have to pass at the command line. Perhaps > an INI-style > format would make sense, with per-plugin sections, or arbitrary > section names specified explicitly e.g. > > [ check_db_query_rowcount ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > or perhaps if I want to check multiple different > databases, or share > the credentials across plugins: > > [ foo_db ] > dsn = db:Pg:database=foo > user = fred > pass = secret > > Then my plugin could have a usage pattern like this: > > Usage: check_db_query_rowcount [-v] -q -w > > -c [--auth=] > > where auth-section might default to the plugin name if > not specified > (and the plugin would fail if an appropriate auth > section could not > be found). > > Thoughts/comments? > > > A design principle I've been following, although it is > undocumented and I'm all for starting a discussion about it > again, is that plugins should run without any knowledge of > state (I think the check_log plugin might break this - I > haven't worked closely on that one). A config file for > passwords doesn't sound necessary. > > However, I guess this is no different from mysql having a > my.cnf file, so I don't think security gets any worse. My > angle is that the userid/password used should only have just > enough access to do the necessary check and no more. That > would be an application issue, not a plugin one. > > Ton > > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From jhmartin at toger.us Tue Oct 17 03:52:41 2006 From: jhmartin at toger.us (Jason Martin) Date: Mon, 16 Oct 2006 18:52:41 -0700 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161018482.30535.11.camel@localhost> References: <20061016111350.GB15099@openfusion.com.au> <45336C3A.5030107@op5.se> <1161018482.30535.11.camel@localhost> Message-ID: <20061017015240.GB3589@mal.members.linode.com> On Mon, Oct 16, 2006 at 07:08:02PM +0200, sean finney wrote: > On Mon, 2006-10-16 at 13:25 +0200, Andreas Ericsson wrote: > > If an attacker has access to your system in a way that lets them list > > processes of any arbitrary user, I fail to see how you could protect > > this configuration file in a sane way. Most OS's allow everyone to do a full ps, but this would prevent legimate users of a given machine from transitively getting permissions to other hosts they shouldn't have through Nagios. -Jason Martin -- Ensign Expendable, step on that rock! - Kirk This message is PGP/MIME signed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From gavin at openfusion.com.au Tue Oct 17 04:56:08 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 17 Oct 2006 12:56:08 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <200610161624.k9GGOeYI013664@mx1.cs.umb.edu> References: <20061016111350.GB15099@openfusion.com.au> <200610161624.k9GGOeYI013664@mx1.cs.umb.edu> Message-ID: <20061017025608.GA17971@openfusion.com.au> On Mon, Oct 16, 2006 at 12:24:40PM -0400, John P. Rouillard wrote: > In message <20061016111350.GB15099 at openfusion.com.au>, > Gavin Carr writes: > >This must be a problem for lots of other kinds of plugin too - > >anywhere you need to pass any kind of secret to a plugin. Is there a > >good way of dealing with this that I'm not aware of? > > The way I do it is to use a small shell script to parse a password > config file and create a temp file. Then I pass the temp file to the > plugin. Obviously this works only with my own plugins, but it does > allow formatting and other changes. E.G. I can: > > pass URL's in a file > create curl config files > create user:passwd authentication formatted entries > > and the input file tries to reuse plugins's normal authentication > mechanism setting the internal variable from a file rather than on the > command line. > > Also I can run the command inside a here document in a shell script and > pass password info on stdin to the plugin if it accepts it. > > wget -i << EOE > https://`getpw /password/cache -`@example.com/ > EOE > > which doesn't leave authentication info in the environment or on the > command line. Nice - that's more flexible, at the price of some additional complexity. > >My suggestion is that we introduce a config file specifically for use > >by plugins (e.g. /etc/nagios/plugins.cfg or > >$NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we > >don't want to have to pass at the command line. Perhaps an INI-style > >format would make sense, with per-plugin sections, or arbitrary > >section names specified explicitly e.g. > > > > [ check_db_query_rowcount ] > > dsn = db:Pg:database=foo > > user = fred > > pass = secret > > > >or perhaps if I want to check multiple different databases, or share > >the credentials across plugins: > > > > [ foo_db ] > > dsn = db:Pg:database=foo > > user = fred > > pass = secret > > > >Then my plugin could have a usage pattern like this: > > > > Usage: check_db_query_rowcount [-v] -q -w > > -c [--auth=] > > > >where auth-section might default to the plugin name if not specified > >(and the plugin would fail if an appropriate auth section could not > >be found). > > Sounds like a good idea and it should be simple enough to code in > perl, C, Bourne shell and python for starters. What may be better is > for the to be: > > auth-section:/path/to/auth/file > > since I can see multiple auth files for different people to > maintain (e.g. oracle db's maintain the password for the test users > using on their databases). I agree. The perl api I've mocked this up in allows you to specify both section and file. Cheers, Gavin From gavin at openfusion.com.au Tue Oct 17 05:08:23 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 17 Oct 2006 13:08:23 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161018371.30535.8.camel@localhost> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> Message-ID: <20061017030823.GB17971@openfusion.com.au> Hi Sean, On Mon, Oct 16, 2006 at 07:06:11PM +0200, sean finney wrote: > On Mon, 2006-10-16 at 21:13 +1000, Gavin Carr wrote: > > An obvious security problem with this is that the user must pass the > > database credentials on the command line, which typically means > > they're exposed to any local users via the process list for however > > long the plugin executes. > > i've brought this up before, actually (though at the time it was > regardling snmp auth info, but same problem) > > > This must be a problem for lots of other kinds of plugin too - > > anywhere you need to pass any kind of secret to a plugin. Is there a > > good way of dealing with this that I'm not aware of? > > well, for the db plugin, assuming that it's a mysql program, why not > use the built-in functionality for reading in additional mysql > ini-format files? it should be possible to say something like > > check_db_plugin --defaults-file=/etc/mysql/nagiosplugin.cnf > > where you use getopt to get the defaults-file value, and pass it to the > mysql "load_defaults" function with the proper parameters. Because: - it's database specific - not every database supports these kinds of defaults, and those that do support it in quite different ways - it's client specific - the above works for the 'mysql' client, but does it work for the php/perl/python/ruby bindings? - it's a more general problem anyway than just databases, as you're snmp auth info example above illustrates > > My suggestion is that we introduce a config file specifically for use > > by plugins (e.g. /etc/nagios/plugins.cfg or > > $NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin parameters we > > don't want to have to pass at the command line. Perhaps an INI-style > > format would make sense, with per-plugin sections, or arbitrary > > section names specified explicitly e.g. > > i would be rather wary of this, because it's yet another point of > configuration/abstraction in an already complicated system. but that's > just mho. I'm wary of the additional complexity too. But I do think we need _some_ mechanism like this for parameters we don't want to pass on the command line, and I can't think of anything simpler that is reasonably general and useful. What did you end up doing in your snmp auth info case? At least two things are evident in the discussion so far: - other people have run across the same problem, and have rolled their own solutions - it's easy for even highly technical people to come up with solutions that have security holes in them I think these two together argue that this would be useful infrastructure we could supply to plugin authors. Cheers, Gavin From seanius at seanius.net Tue Oct 17 10:05:58 2006 From: seanius at seanius.net (sean finney) Date: Tue, 17 Oct 2006 10:05:58 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061017030823.GB17971@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> Message-ID: <1161072358.7063.10.camel@localhost> hi gavin, On Tue, 2006-10-17 at 13:08 +1000, Gavin Carr wrote: > Because: yes, i realized this after i had sent my mail, but thought that i had perhaps flooded the list with too many emails[1] already, so a "to answer my own question" email wasn't appropriate :) > I'm wary of the additional complexity too. But I do think we need _some_ > mechanism like this for parameters we don't want to pass on the command > line, and I can't think of anything simpler that is reasonably general and > useful. What did you end up doing in your snmp auth info case? iirc i just wrote a wrapper script because a consensus couldn't be reached at the time and i had better things to do. > I think these two together argue that this would be useful infrastructure > we could supply to plugin authors. if we were to do this, i would say it should supercede/deprecate use of most stuff we currently have in utils.pm (that is the "settings" in utils.pm would be moved out). *but*... i still have strong reservations about this. could you comment on the other proposal that was brought up about reading extra cmdline arguments are stored in a file? i think that's a lot simpler, is just as general (more, even), and doesn't involve introducing a new point of configuration. sean [1] i'm on temporary hiatus from my preferred MUA, and thus lacking the "tagged group reply" feature. -------------- 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 Tue Oct 17 13:34:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 04:34:34 -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 wszenajch 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 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: 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 gavin at openfusion.com.au Wed Oct 18 03:08:25 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Wed, 18 Oct 2006 11:08:25 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161072358.7063.10.camel@localhost> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> Message-ID: <20061018010825.GA21862@openfusion.com.au> On Tue, Oct 17, 2006 at 10:05:58AM +0200, sean finney wrote: > > I think these two together argue that this would be useful infrastructure > > we could supply to plugin authors. > > if we were to do this, i would say it should supercede/deprecate use of > most stuff we currently have in utils.pm (that is the "settings" in > utils.pm would be moved out). > > *but*... i still have strong reservations about this. could you comment > on the other proposal that was brought up about reading extra cmdline > arguments are stored in a file? i think that's a lot simpler, is just > as general (more, even), and doesn't involve introducing a new point of > configuration. You mean William's comment here? : >> Common way to deal with this is to have option that reads additional >> arguments from specified file, i.e. it would be: >> Usage: check_db_query_rowcount [-v] -q -w >> -c [--config ] >> where the file would contain >> -d -u user> -p It clearly _does_ involve another point of configuration, as you've still got a new file containing configuration data; but as least it's the same kind of configation i.e. just a new place to put arguments - is that what you mean here? I'm not strongly opposed to something like this if people feel it's significantly simpler. There are two main differences between this and what I proposed: - the config file here contains just a single item, where I was suggesting an ini-style config allowing multiple sections. This way I guess you end up with a lot of little config files (arbitrarily named, I guess) containing argument snippets to various plugins; my way you end up with multiple sections in a single well-known config file. You _can_ use multiple files in my proposal if it's motivated by other factors, like John's comment that he'd like to separate them out by permissions, but it's not required. I guess if we go this way we might want to a separate directory (e.g. /etc/nagios/plugins) to prevent these configs cluttering up the main nagios directory - this way uses plugin arguments directly, where I was suggesting using arbitrary name-value pairs that then get mapped back to plugin arguments. Using plugin arguments directly is simpler, but it means that each config is tightly coupled to a particular plugin's argument set - if another plugin also wants to connect to that same database but happens to use -P for password, you need to duplicate your config details, with all the associated maintenance issues. So I think the extra level of indirection is worth it, but it's clearly arguable both ways. Cheers, Gavin From drusu at calstate.edu Wed Oct 18 02:14:06 2006 From: drusu at calstate.edu (Rusu, Dan) Date: Tue, 17 Oct 2006 17:14:06 -0700 Subject: [Nagiosplug-devel] check_dns bug Message-ID: Hello, I hope someone can look at this and tell me what the problem is. I have other DNS servers that I'm monitoring, but this one server (and yes, I've checked the /etc/named and everything else I could think off) exhibits this error, which as you can see blow, I'm unable to reproduce manually: monitor-root:/usr/local/nagios/libexec> ./check_dns -H www.yahoo.com -s 137.145.35.70 DNS CRITICAL - '/usr/sbin/nslookup' output parsing exited with no address monitor-root:/usr/local/nagios/libexec> monitor-root:/usr/local/nagios/libexec> nslookup Default Server: wedns2.csu.net Address: 137.145.46.101 > server 137.145.35.70 Default Server: wasp.csuco Address: 137.145.35.70 > www.yahoo.com Server: wasp.csuco Address: 137.145.35.70 Non-authoritative answer: Name: www.yahoo-ht2.akadns.net Address: 209.131.36.158 Aliases: www.yahoo.com > exit Thank you much! Dan ************************************************************************ ******************* Dan Rusu Unix System Administrator Technology Infrastructure Services California State University - Office of the Chancellor - Wested Tel: (562)346-2257 * Fax: (562)346-2223 Email: drusu at calstate.edu ************************************************************************ ******************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Wed Oct 18 10:43:52 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 18 Oct 2006 09:43:52 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061018010825.GA21862@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> Message-ID: <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> On 18 Oct 2006, at 02:08, Gavin Carr wrote: >>> Common way to deal with this is to have option that reads additional >>> arguments from specified file, i.e. it would be: >>> Usage: check_db_query_rowcount [-v] -q -w >>> -c [--config ] >>> where the file would contain >>> -d -u user> -p > > It clearly _does_ involve another point of configuration, as you've > still > got a new file containing configuration data; but as least it's the > same > kind of configation i.e. just a new place to put arguments - is > that what > you mean here? > > I'm not strongly opposed to something like this if people feel it's > significantly simpler. There are two main differences between this > and what > I proposed: > > - the config file here contains just a single item, where I was > suggesting > an ini-style config allowing multiple sections. This way I guess > you end > up with a lot of little config files (arbitrarily named, I guess) > containing argument snippets to various plugins; my way you end > up with > multiple sections in a single well-known config file. You _can_ use > multiple files in my proposal if it's motivated by other factors, > like > John's comment that he'd like to separate them out by > permissions, but > it's not required. I guess if we go this way we might want to a > separate > directory (e.g. /etc/nagios/plugins) to prevent these configs > cluttering > up the main nagios directory > > - this way uses plugin arguments directly, where I was suggesting > using > arbitrary name-value pairs that then get mapped back to plugin > arguments. > Using plugin arguments directly is simpler, but it means that > each config > is tightly coupled to a particular plugin's argument set - if > another > plugin also wants to connect to that same database but happens to > use > -P for password, you need to duplicate your config details, with > all the > associated maintenance issues. So I think the extra level of > indirection > is worth it, but it's clearly arguable both ways. I'm coming round to the idea of the config file - it has been well argued here. I don't like the idea of having the "extra level of indirection" with another set of "standard" parameters (Where are they defined? Why are the different?). So, I think the ini file should just hold the current options, but in a more secure/readable format. I don't think a file that holds: -u username -p password is sufficient, because if it is generalised to other arguments, shell quoting/expansion may cause a problem (--regex="this string"). Can I make a slight refinement to the current proposal? Plugins that support this new config file parsing of options take the option (as Sean suggested) of --extra-opts=[configfile][:stanzaname] The config file is ini style. You can default configfile to $HOME/ np.conf (or maybe /usr/local/nagios/etc/np.conf). The [:stanzaname] defines a stanza within the config file, otherwise defaults to name of plugin (maybe reserve "main" as a stanza name - this config file has given me some ideas for future stuff). An example stanza: [check_mysql] username=tonvoon password=secret So running "check_mysql -S --extra-opts=" should give the same result as running "check_mysql -S --username=tonvoon --password=secret". If fact, the variable names could just be the short option form: [check_mysql] u=tonvoon p=password But I'm guessing using that long names will be preferred. I think a plugin invocation with -v -v should show the command line options with the extra parameters added in, so a user knows what has been run. In terms of implementation on the C side, I think we could create a new utils function called np_getopt_long which basically calls getopt_long. But if it finds --extra-opts, then it reads the ini file and then returns parameters to the plugin as if they were from the command line, so there shouldn't be many changes required at the plugin level. This allows us to then run tests against this function to prove it works as expected (did I just hawk testing again? Sorry!). Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin at openfusion.com.au Wed Oct 18 13:21:25 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Wed, 18 Oct 2006 21:21:25 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> Message-ID: <20061018112125.GD15099@openfusion.com.au> On Wed, Oct 18, 2006 at 09:43:52AM +0100, Ton Voon wrote: > On 18 Oct 2006, at 02:08, Gavin Carr wrote: > >I'm not strongly opposed to something like this if people feel it's > >significantly simpler. There are two main differences between this > >and what I proposed: > I'm coming round to the idea of the config file - it has been well > argued here. > > I don't like the idea of having the "extra level of indirection" with > another set of "standard" parameters (Where are they defined? Why are > the different?). So, I think the ini file should just hold the > current options, but in a more secure/readable format. I'm fine with this suggestion. For some reason I'd forgotten about long option names, which should usually be fine for disambiguating options. > Plugins that support this new config file parsing of options take the > option (as Sean suggested) of > > --extra-opts=[configfile][:stanzaname] Syntax quibble: how about 'configfile#section', like URL fragments? Colon is already used in host:/path/to/file forms, and in ranges. > The [:stanzaname] > defines a stanza within the config file, otherwise defaults to name > of plugin (maybe reserve "main" as a stanza name - this config file > has given me some ideas for future stuff). > > An example stanza: > > [check_mysql] > username=tonvoon > password=secret > > So running "check_mysql -S --extra-opts=" should give the same result > as running "check_mysql -S --username=tonvoon --password=secret". If > fact, the variable names could just be the short option form: > > [check_mysql] > u=tonvoon > p=password > > But I'm guessing using that long names will be preferred. And just to clarify: you're saying that where an argument has multiple forms (even more than two), any of them would also be acceptable in the config file? Cheers, Gavin From ton.voon at altinity.com Wed Oct 18 13:50:24 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 18 Oct 2006 12:50:24 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061018112125.GD15099@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <20061018112125.GD15099@openfusion.com.au> Message-ID: <6D8E030E-5F74-4995-BA24-FD9900C5B781@altinity.com> On 18 Oct 2006, at 12:21, Gavin Carr wrote: >> Plugins that support this new config file parsing of options take the >> option (as Sean suggested) of >> >> --extra-opts=[configfile][:stanzaname] > > Syntax quibble: how about 'configfile#section', like URL fragments? > Colon is already used in host:/path/to/file forms, and in ranges. I thought that too since it makes more sense. However the shell would think it was a comment unless you escaped or put quotes around it. If that is obvious enough, I'm happy with hash. >> The [:stanzaname] >> defines a stanza within the config file, otherwise defaults to name >> of plugin (maybe reserve "main" as a stanza name - this config file >> has given me some ideas for future stuff). >> >> An example stanza: >> >> [check_mysql] >> username=tonvoon >> password=secret >> >> So running "check_mysql -S --extra-opts=" should give the same result >> as running "check_mysql -S --username=tonvoon --password=secret". If >> fact, the variable names could just be the short option form: >> >> [check_mysql] >> u=tonvoon >> p=password >> >> But I'm guessing using that long names will be preferred. > > And just to clarify: you're saying that where an argument has multiple > forms (even more than two), any of them would also be acceptable in > the config file? Yes, because it should be equivalent to running the expanded command on the command line. If there is a technical reason why u=tonvoon will cause more problems that username=tonvoon, then I'd be happy to drop the single syntax option. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Wed Oct 18 15:18:30 2006 From: seanius at seanius.net (sean finney) Date: Wed, 18 Oct 2006 15:18:30 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061018010825.GA21862@openfusion.com.au> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> Message-ID: <1161177510.7822.13.camel@localhost> apologies in advance for having to reply to each mail individually... On Wed, 2006-10-18 at 11:08 +1000, Gavin Carr wrote: > You mean William's comment here? : yeah, that's the one. > It clearly _does_ involve another point of configuration, as you've still > got a new file containing configuration data; but as least it's the same > kind of configation i.e. just a new place to put arguments - is that what > you mean here? yes. i guess i didn't consider that as "configuration" but it's more or less the same thing without the syntactic sugar, so i'll have to admit that point i suppose :) > - the config file here contains just a single item, where I was suggesting > an ini-style config allowing multiple sections. This way I guess you end > up with a lot of little config files (arbitrarily named, I guess) > containing argument snippets to various plugins; my way you end up with > multiple sections in a single well-known config file. You _can_ use > multiple files in my proposal if it's motivated by other factors, like > John's comment that he'd like to separate them out by permissions, but > it's not required. I guess if we go this way we might want to a separate > directory (e.g. /etc/nagios/plugins) to prevent these configs cluttering > up the main nagios directory i think the later discussions between you and ton put this in a better light as far as i'm concerned. that is, mapping directly to the --long-opts and thus passing the options to getopt as necessary. > - this way uses plugin arguments directly, where I was suggesting using > arbitrary name-value pairs that then get mapped back to plugin arguments. > Using plugin arguments directly is simpler, but it means that each config > is tightly coupled to a particular plugin's argument set - if another > plugin also wants to connect to that same database but happens to use > -P for password, you need to duplicate your config details, with all the > associated maintenance issues. So I think the extra level of indirection > is worth it, but it's clearly arguable both ways. i think this is kind of a red herring argument though. i don't think that we have that many plugins with that many different ways of passing arguments... and if we did i'd say we ought to fix the plugins so they do have the same cmdline interface. 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 seanius at seanius.net Wed Oct 18 15:27:19 2006 From: seanius at seanius.net (sean finney) Date: Wed, 18 Oct 2006 15:27:19 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> Message-ID: <1161178039.7822.23.camel@localhost> On Wed, 2006-10-18 at 09:43 +0100, Ton Voon wrote: > I'm coming round to the idea of the config file - it has been well > argued here. > > > I don't like the idea of having the "extra level of indirection" with > another set of "standard" parameters (Where are they defined? Why are > the different?). So, I think the ini file should just hold the current > options, but in a more secure/readable format. this was one of my biggest concerns. if the most of the configuration sections mapped directly to plugin arguments i don't think i'd have any objection to them. however, if we are going this route, it might be worth discussing if we can migrate/consolidate/remove the utils.pm settings as well. > I don't think a file that holds: > > > -u username -p password > > > is sufficient, because if it is generalised to other arguments, shell > quoting/expansion may cause a problem (--regex="this string"). just for the record, i don't think you'd actually have to worry about this, since the arguments are never seen by the shell. > The config file is ini style. You can default configfile to > $HOME/np.conf (or maybe /usr/local/nagios/etc/np.conf). The > [:stanzaname] defines a stanza within the config file, otherwise > defaults to name of plugin (maybe reserve "main" as a stanza name - > this config file has given me some ideas for future stuff). if we could configure the default location of this file at ./configure time it would be extra nice for packagers. > But I'm guessing using that long names will be preferred. I think a > plugin invocation with -v -v should show the command line options with > the extra parameters added in, so a user knows what has been run. agreed. > In terms of implementation on the C side, I think we could create a > new utils function called np_getopt_long which basically calls > getopt_long. But if it finds --extra-opts, then it reads the ini file > and then returns parameters to the plugin as if they were from the > command line, so there shouldn't be many changes required at the > plugin level. This allows us to then run tests against this function > to prove it works as expected (did I just hawk testing again? Sorry!). yes, this sounds very nice. 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 ton.voon at altinity.com Wed Oct 18 16:03:07 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 18 Oct 2006 15:03:07 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161178039.7822.23.camel@localhost> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <1161178039.7822.23.camel@localhost> Message-ID: On 18 Oct 2006, at 14:27, sean finney wrote: > however, if we are going this route, it might be worth discussing > if we > can migrate/consolidate/remove the utils.pm settings as well. Sean, Which settings do you mean? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at altinity.com Wed Oct 18 16:18:15 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 18 Oct 2006 15:18:15 +0100 Subject: [Nagiosplug-devel] Nagios::Plugin 0.14 perl module released Message-ID: Hi! Just to let you know that Nagios::Plugin 0.14 has just been released to CPAN. This is a perl module to help developers write plugins in perl easily: http://search.cpan.org/dist/Nagios-Plugin/ There's been a huge amount of work put in by Gavin Carr and Nathan Vonnahme and Gavin will be taking the lead on the perl module as we move forward. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Wed Oct 18 16:33:48 2006 From: seanius at seanius.net (sean finney) Date: Wed, 18 Oct 2006 16:33:48 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <1161178039.7822.23.camel@localhost> Message-ID: <1161182028.7822.49.camel@localhost> hey ton, On Wed, 2006-10-18 at 15:03 +0100, Ton Voon wrote: > On 18 Oct 2006, at 14:27, sean finney wrote: > > > however, if we are going this route, it might be worth discussing if > > we > > > > can migrate/consolidate/remove the utils.pm settings as well. > Which settings do you mean? i would say as much as possible :) one of the biggest pains (historically) with managing installation of the plugins is getting them to find the utils.pm in the right place (i.e. the susbt script). i've also always felt that some of the information in these files really ought to be treated more as configuration options as opposed to library settings. for example $PATH_TO_FOO is something that the local admin might want to change. so if most of the utils.pm functions are going into Nagios::Plugin, my thinking was that the other stuff could be incorporated into this scheme. 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 ton.voon at altinity.com Wed Oct 18 17:20:14 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 18 Oct 2006 16:20:14 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161182028.7822.49.camel@localhost> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <1161178039.7822.23.camel@localhost> <1161182028.7822.49.camel@localhost> Message-ID: <18DC322F-72B5-479F-95CC-465FDBACFF3E@altinity.com> On 18 Oct 2006, at 15:33, sean finney wrote: >> Which settings do you mean? > > i would say as much as possible :) one of the biggest pains > (historically) with managing installation of the plugins is getting > them > to find the utils.pm in the right place (i.e. the susbt script). Agreed. I want to deprecate utils.pm as soon as possible in favour of Nagios::Plugin. There's not a huge amount of functionality in there anyway, as most people have already noted. > i've also always felt that some of the information in these files > really > ought to be treated more as configuration options as opposed to > library > settings. for example $PATH_TO_FOO is something that the local admin > might want to change. > > so if most of the utils.pm functions are going into Nagios::Plugin, my > thinking was that the other stuff could be incorporated into this > scheme. I never saw the point of $PATH_TO_FOO variables. I would just call system() without the full path, no? Otherwise, if we have this ini configuration file, we could have a stanza like: [main] path_to_rpcinfo=/usr/sbin/rpcinfo path_to_lmstat= path_to_smbclient=/usr/bin/smbclient path_to_mailq=/usr/bin/mailq path_to_qmail_qstat= Values added by configure, of course. I've just thought, if this ini file is created by the nagios- plugins ./configure, how does Nagios::Plugin know where it resides? Would it have to check various possible locations? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rouilj at cs.umb.edu Wed Oct 18 17:20:46 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 18 Oct 2006 11:20:46 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Wed, 18 Oct 2006 21:21:25 +1000." <20061018112125.GD15099@openfusion.com.au> Message-ID: <200610181520.k9IFKkxY011817@mx1.cs.umb.edu> In message <20061018112125.GD15099 at openfusion.com.au>, Gavin Carr writes: >On Wed, Oct 18, 2006 at 09:43:52AM +0100, Ton Voon wrote: >> On 18 Oct 2006, at 02:08, Gavin Carr wrote: >> >I'm not strongly opposed to something like this if people feel it's >> >significantly simpler. There are two main differences between this >> >and what I proposed: > > > >> I'm coming round to the idea of the config file - it has been well >> argued here. >> >> I don't like the idea of having the "extra level of indirection" with >> another set of "standard" parameters (Where are they defined? Why are >> the different?). So, I think the ini file should just hold the >> current options, but in a more secure/readable format. > >I'm fine with this suggestion. For some reason I'd forgotten about long >option names, which should usually be fine for disambiguating options. > >> Plugins that support this new config file parsing of options take the >> option (as Sean suggested) of >> >> --extra-opts=[configfile][:stanzaname] > >Syntax quibble: how about 'configfile#section', like URL fragments? >Colon is already used in host:/path/to/file forms, and in ranges. Well, # has special meaning to the shell. And you may be trying to pass this argument across systems using ssh or other mechanism which makes getting the quotes really tricky. Hence # $ are bad choices. However maybe '/path/to/file at stanzaname' works since it is using the entry in the file AT stanzaname. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From rouilj at cs.umb.edu Wed Oct 18 17:43:39 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 18 Oct 2006 11:43:39 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Wed, 18 Oct 2006 16:20:14 BST." <18DC322F-72B5-479F-95CC-465FDBACFF3E@altinity.com> Message-ID: <200610181543.k9IFhdwH016137@mx1.cs.umb.edu> In message <18DC322F-72B5-479F-95CC-465FDBACFF3E at altinity.com>, Ton Voon writes: >I never saw the point of $PATH_TO_FOO variables. I would just call >system() without the full path, no? Well if you use system() it searches on the path of the nagios daemon as started from init. Usually it has a few key directories on it but not all. I know I had to install a new ntp installation to get a working ntp that would not have been on the default path >Otherwise, if we have this ini configuration file, we could have a >stanza like: > >[main] >path_to_rpcinfo=/usr/sbin/rpcinfo >path_to_lmstat= >path_to_smbclient=/usr/bin/smbclient >path_to_mailq=/usr/bin/mailq >path_to_qmail_qstat= > >Values added by configure, of course. > >I've just thought, if this ini file is created by the nagios- >plugins ./configure, how does Nagios::Plugin know where it resides? >Would it have to check various possible locations? Ah yes, the "Hello chicken met egg" problem. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From seanius at seanius.net Wed Oct 18 18:11:12 2006 From: seanius at seanius.net (sean finney) Date: Wed, 18 Oct 2006 18:11:12 +0200 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <18DC322F-72B5-479F-95CC-465FDBACFF3E@altinity.com> References: <20061016111350.GB15099@openfusion.com.au> <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <1161178039.7822.23.camel@localhost> <1161182028.7822.49.camel@localhost> <18DC322F-72B5-479F-95CC-465FDBACFF3E@altinity.com> Message-ID: <1161187872.7822.67.camel@localhost> hey ton, On Wed, 2006-10-18 at 16:20 +0100, Ton Voon wrote: > Agreed. I want to deprecate utils.pm as soon as possible in favour of > Nagios::Plugin. There's not a huge amount of functionality in there > anyway, as most people have already noted. > > > i've also always felt that some of the information in these files > > really > > ought to be treated more as configuration options as opposed to > > library > > settings. for example $PATH_TO_FOO is something that the local > > admin > > might want to change. > > > > > > so if most of the utils.pm functions are going into Nagios::Plugin, > > my > > thinking was that the other stuff could be incorporated into this > > scheme. > > > I never saw the point of $PATH_TO_FOO variables. I would just call > system() without the full path, no? ideally if you have the path, you can avoid system in favor of execle() or similar, which saves you a fork/exec call. i *think* the np_runcmd functions do this, for example. > Otherwise, if we have this ini configuration file, we could have a > stanza like: > > > [main] > path_to_rpcinfo=/usr/sbin/rpcinfo > path_to_lmstat= > path_to_smbclient=/usr/bin/smbclient > path_to_mailq=/usr/bin/mailq > path_to_qmail_qstat= > > Values added by configure, of course. i was thinking something along those lines. at risk of exploding "feature creep", i could also suggest some other stuff we could throw in there, such as default paths, environment variables, etc. but maybe we should nip this in the bud for now and decide if its the way we want to go, and implement the meat of it for the reason that we really want it first. > I've just thought, if this ini file is created by the > nagios-plugins ./configure, how does Nagios::Plugin know where it > resides? Would it have to check various possible locations? i would suggest a using couple reasonable defaults, and then provide some way to specify an override from this at build-time. i'm not too familiar with CPAN but i imagine there must be a way to do that :) 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 nathan.vonnahme at bannerhealth.com Wed Oct 18 21:56:54 2006 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Wed, 18 Oct 2006 11:56:54 -0800 Subject: [Nagiosplug-devel] [RFC] Plugins config file Message-ID: <077F1B782014ED48A58E7927914D36A0022429C4@fai01500.bhs.bannerhealth.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of John P. Rouillard > Sent: Wednesday, October 18, 2006 7:21 AM > >> Plugins that support this new config file parsing of > options take the > >> option (as Sean suggested) of > >> > >> --extra-opts=[configfile][:stanzaname] > > > >Syntax quibble: how about 'configfile#section', like URL fragments? > >Colon is already used in host:/path/to/file forms, and in ranges. > > Well, # has special meaning to the shell. And you may be trying to > pass this argument across systems using ssh or other mechanism which > makes getting the quotes really tricky. Hence # $ are bad > choices. However maybe '/path/to/file at stanzaname' works since it is > using the entry in the file AT stanzaname. Wouldn't stanza@/path/to/file be more logical? Perhaps a CGIish questionmark would work? --extra-opts=/path/to/file?stanzaname Actually it would probably be clearer and more memorable to have two optional options, so you can omit one easily: --cfg-file=/path/to/file --cfg-stanza=stanzaname I can help with the Perl implementation after Nov 1... -n From gavin at openfusion.com.au Thu Oct 19 01:25:27 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 19 Oct 2006 09:25:27 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <1161187872.7822.67.camel@localhost> References: <1161018371.30535.8.camel@localhost> <20061017030823.GB17971@openfusion.com.au> <1161072358.7063.10.camel@localhost> <20061018010825.GA21862@openfusion.com.au> <86EB1FB0-5F3E-4F9F-88D3-1CA031AEA178@altinity.com> <1161178039.7822.23.camel@localhost> <1161182028.7822.49.camel@localhost> <18DC322F-72B5-479F-95CC-465FDBACFF3E@altinity.com> <1161187872.7822.67.camel@localhost> Message-ID: <20061018232527.GA26087@openfusion.com.au> On Wed, Oct 18, 2006 at 06:11:12PM +0200, sean finney wrote: > > Otherwise, if we have this ini configuration file, we could have a > > stanza like: > > > > > > [main] > > path_to_rpcinfo=/usr/sbin/rpcinfo > > path_to_lmstat= > > path_to_smbclient=/usr/bin/smbclient > > path_to_mailq=/usr/bin/mailq > > path_to_qmail_qstat= > > > > Values added by configure, of course. > > i was thinking something along those lines. at risk of exploding > "feature creep", i could also suggest some other stuff we could > throw in there, such as default paths, environment variables, etc. > but maybe we should nip this in the bud for now and decide if its > the way we want to go, and implement the meat of it for the reason > that we really want it first. I agree. > > I've just thought, if this ini file is created by the > > nagios-plugins ./configure, how does Nagios::Plugin know where it > > resides? Would it have to check various possible locations? > > i would suggest a using couple reasonable defaults, and then provide > some way to specify an override from this at build-time. i'm not too > familiar with CPAN but i imagine there must be a way to do that :) Yep, we can do that. Cheers, Gavin From gavin at openfusion.com.au Thu Oct 19 01:35:25 2006 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 19 Oct 2006 09:35:25 +1000 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <077F1B782014ED48A58E7927914D36A0022429C4@fai01500.bhs.bannerhealth.com> References: <077F1B782014ED48A58E7927914D36A0022429C4@fai01500.bhs.bannerhealth.com> Message-ID: <20061018233525.GB26087@openfusion.com.au> On Wed, Oct 18, 2006 at 11:56:54AM -0800, Vonnahme, Nathan wrote: > > >> Plugins that support this new config file parsing of > > options take the > > >> option (as Sean suggested) of > > >> > > >> --extra-opts=[configfile][:stanzaname] > > > > > >Syntax quibble: how about 'configfile#section', like URL fragments? > > >Colon is already used in host:/path/to/file forms, and in ranges. > > > > Well, # has special meaning to the shell. And you may be trying to > > pass this argument across systems using ssh or other mechanism which > > makes getting the quotes really tricky. Hence # $ are bad > > choices. However maybe '/path/to/file at stanzaname' works since it is > > using the entry in the file AT stanzaname. > > > Wouldn't stanza@/path/to/file be more logical? > > Perhaps a CGIish questionmark would work? > --extra-opts=/path/to/file?stanzaname > > Actually it would probably be clearer and more memorable to have two > optional options, so you can omit one easily: > --cfg-file=/path/to/file --cfg-stanza=stanzaname One further wrinkle - a fairly typical use case, I imagine, will be that I want to use extra options from the default file and the default section (i.e. plugin name?). It would be nice to be able to support that too ... --extra-opts ? --extra-opts=1 ? I like Nathan's suggestion of separate args too though. Hmmm. Cheers, Gavin From rouilj at cs.umb.edu Thu Oct 19 02:15:57 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Wed, 18 Oct 2006 20:15:57 -0400 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: Your message of "Wed, 18 Oct 2006 11:56:54 -0800." <077F1B782014ED48A58E7927914D36A0022429C4@fai01500.bhs.bannerhealth.com> Message-ID: <200610190015.k9J0Fv7a019229@mx1.cs.umb.edu> In message <077F1B782014ED48A58E7927914D36A0022429C4 at fai01500.bhs.bannerhealth. com>, "Vonnahme, Nathan" writes: >> -----Original Message----- >> From: nagiosplug-devel-bounces at lists.sourceforge.net >> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On >> Behalf Of John P. Rouillard >> Sent: Wednesday, October 18, 2006 7:21 AM >> Well, # has special meaning to the shell. And you may be trying to >> pass this argument across systems using ssh or other mechanism which >> makes getting the quotes really tricky. Hence # $ are bad >> choices. However maybe '/path/to/file at stanzaname' works since it is >> using the entry in the file AT stanzaname. > >Wouldn't stanza@/path/to/file be more logical? that works as well. >Perhaps a CGIish questionmark would work? > --extra-opts=/path/to/file?stanzaname The ? is a wild card in shell. >Actually it would probably be clearer and more memorable to have two >optional options, so you can omit one easily: > --cfg-file=/path/to/file --cfg-stanza=stanzaname Also a valid implementation. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From ton.voon at altinity.com Thu Oct 19 10:37:23 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 19 Oct 2006 09:37:23 +0100 Subject: [Nagiosplug-devel] [RFC] Plugins config file In-Reply-To: <20061018233525.GB26087@openfusion.com.au> References: <077F1B782014ED48A58E7927914D36A0022429C4@fai01500.bhs.bannerhealth.com> <20061018233525.GB26087@openfusion.com.au> Message-ID: On 19 Oct 2006, at 00:35, Gavin Carr wrote: > On Wed, Oct 18, 2006 at 11:56:54AM -0800, Vonnahme, Nathan wrote: >> >> Wouldn't stanza@/path/to/file be more logical? >> >> Perhaps a CGIish questionmark would work? >> --extra-opts=/path/to/file?stanzaname >> >> Actually it would probably be clearer and more memorable to have two >> optional options, so you can omit one easily: >> --cfg-file=/path/to/file --cfg-stanza=stanzaname > > One further wrinkle - a fairly typical use case, I imagine, will be > that I want to use extra options from the default file and the default > section (i.e. plugin name?). It would be nice to be able to support > that too ... > > --extra-opts ? > --extra-opts=1 ? > > I like Nathan's suggestion of separate args too though. Hmmm. I'd echo Sean's "don't make this too complicated right now" message. My conceptual idea of these extra opts is that when you hit --extra- opts=???, this option is effectively replaced in line with the options in the config file. You may have other options in front or behind. Assume: {default config file} [check_mysql] username=tonvoon password=secret [more_options] username=altinity warning=10 critical=15 Then: ./check_mysql -S --extra-opts= -H localhost is effectively: ./check_mysql -S --username=tonvoon --password=secret -H localhost However, if you use Nathan's separate args form, you'd have to parse all the options before you can replace (as you may not want the default stanza name). Also where do you replace? ./check_mysql -S --cfg-file= -H localhost --cfg-stanza= Do you replace --cfg-file or --cfg-stanza? I think to avoid the confusion (at the expense of a more obscure syntax), it should be a single option. This then allows Gavin's request of having multiple options. So: ./check_mysql -S --extra-opts= --extra-opts=more_options -H localhost Is effectively: ./check_mysql -S --username=tonvoon --password=secret -- username=altinity --warning=10 --critical=15 -H localhost I think this is fairly intuitive. Notice username is listed twice. I don't think the "replacement opts" function should care what has passed before or after - it just puts everything down since some plugins expect arguments a multiple number of times (check_disk -p / - p /var). How the plugin responds to double requests is the plugin's responsibility. Ooh, I'm getting excited! Where can I sign up? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils-georg.paus at elkem.no Thu Oct 19 15:38:18 2006 From: nils-georg.paus at elkem.no (nils-georg.paus at elkem.no) Date: Thu, 19 Oct 2006 15:38:18 +0200 Subject: [Nagiosplug-devel] Nils-Georg Paus is out of the office. Message-ID: I will be out of the office starting 19.10.2006 and will not return until 31.10.2006. I will respond to your message when I return. NOTICE Please immediately e-mail back to sender if you are not the intended recipient.Thereafter delete the e-mail along with any attachments without making copies. Elkem reserves all rights of privilege, confidentiality and copyright. From noreply at sourceforge.net Thu Oct 19 20:45:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 11:45:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1567390 ] utils.pm is_hostname Message-ID: Patches item #1567390, was opened at 2006-09-29 01:08 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1567390&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: O'Shaughnessy Evans (shaug) >Assigned to: Ton Voon (tonvoon) Summary: utils.pm is_hostname Initial Comment: Patch allows is_hostname() to recognize hosts and domains that begin with numbers. Current version of is_hostname() only allows numbers to exist in subsequent characters, but this no longer matches current DNS usage standards. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 19:45 Message: Logged In: YES user_id=664364 O'Shaughnessy, Thanks for the report. Fixed in CVS. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1567390&group_id=29880 From noreply at sourceforge.net Thu Oct 19 20:58:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 11:58:48 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1562572 ] check_http redirection fix Message-ID: Patches item #1562572, was opened at 2006-09-21 01:41 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1562572&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Aravind Gottipati (gottipati) >Assigned to: Ton Voon (tonvoon) Summary: check_http redirection fix Initial Comment: check_http fails to follow http redirects. It fails in cases where the return headers have a line that starts with L like this example below. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= check_http -I 63.245.209.26 -H www.worldfirefoxday.com -f follow -v -u / GET / HTTP/1.0 User-Agent: check_http/1.81 (nagios-plugins 1.4.1) Host: www.worldfirefoxday.com http://63.245.209.26:80/ is 439 characters STATUS: HTTP/1.1 302 Found **** HEADER **** Date: Wed, 20 Sep 2006 06:12:31 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Wed, 20 Sep 2006 06:12:31 GMT Pragma: no-cache Location: http://www.worldfirefoxday.com/en/ Content-Length: 0 Connection: close Content-Type: text/html; charset=UTF-8 **** CONTENT **** GET /Last-Modified: HTTP/1.0 User-Agent: check_http/1.81 (nagios-plugins 1.4.1) Host: www.worldfirefoxday.com http://www.worldfirefoxday.com:80/Last-Modified: is 483 characters STATUS: HTTP/1.1 404 Not Found -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The problem seems to be with this line in the redir function in check_http.c if (sscanf (pos, "%[Ll]%*[Oo]%*[Cc]%*[Aa]%*[Tt]%*[Ii]%*[Oo]%*[Nn]:%n", xx, &i) < 1) { Checking the value of i seems to be a better indicator of the match than the return value of sscanf. The following patch fixes this problem for me. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 19:58 Message: Logged In: YES user_id=664364 Aravind, Good catch. Patch in CVS. Thanks. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1562572&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:01:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:01:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1546175 ] fixes argument linked list for check_disk utility Message-ID: Patches item #1546175, was opened at 2006-08-24 19:33 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1546175&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Augustine (augustine_ab) >Assigned to: Ton Voon (tonvoon) Summary: fixes argument linked list for check_disk utility Initial Comment: in check_disk.c name_list structure is used without allocated memory being cleared. this works on linux but not on several other unix based operating systems (was discovered while building for AIX). Problem is fully described in bug report: [ 1540327 ] check_disk C_IDFP/W_IDFP inputerror, affects 1.4.3 not 1.4.2 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:01 Message: Logged In: YES user_id=664364 Augustine, Thanks for the report. This should already be fixed in CVS. Please try the snapshot at http://nagiosplug.sf.net/snapshot. Please reopen if it is still a problem. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1546175&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:03:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:03:44 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1121018 ] Fix "check_disk -e" returning "Unable to read output" Message-ID: Patches item #1121018, was opened at 2005-02-11 20:04 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1121018&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: Pending Resolution: None Priority: 5 Submitted By: r2c (r2c) >Assigned to: Ton Voon (tonvoon) Summary: Fix "check_disk -e" returning "Unable to read output" Initial Comment: When running check_disk with -e option and all filesystems are OK it returns "Unable to read output". This is because when every disk_result == STATE_OK and the erronly is TRUE, the max_state function at the end of the if is never reached. This causes the variable result to be STATE_UNKNOW, printing the above error. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:03 Message: Logged In: YES user_id=664364 Hi r2c, I think this problem is out of date as there has been many changes to check_disk. I will mark the call into pending - please update if this is still a problem. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1121018&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:05:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:05:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1499684 ] New Check: check_rsync Message-ID: Patches item #1499684, was opened at 2006-06-02 19:06 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1499684&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: dERMOTH (dermoth) >Assigned to: Ton Voon (tonvoon) Summary: New Check: check_rsync Initial Comment: I wrote check_rsync for the purpose of checking rsync servers availability, as well as (optionally) individual modules availability. It also supports authentication on modules. It requires File::Rsync from CPAN. Usage: check_rsync -H [-p ] [-m [,,] [-m [,,]...]] The only required argument is -H, in wich case it will only try to list modules on the Rsync server. One or more -m arguments can be passed with one module name per -m argument. You can also append a username and password to the module name by separating them with commas (without spaces). Comments are welcome. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:05 Message: Logged In: YES user_id=664364 Hi Dermoth, Unfortunately, we are not taking new plugins into the main distribution. Please consider publishing your plugin on http://nagiosexchange.org. Thanks for taking the time to raise a tracker. Ton ---------------------------------------------------------------------- Comment By: dERMOTH (dermoth) Date: 2006-06-09 18:28 Message: Logged In: YES user_id=375623 I recently updated from nagios 2.0b3 to 2.4 and File::Rsync don't work properly with the ePN from 2.4 (To clear things up both nagios used ePN + caching) This version does the exact same thing but with IPC::Run and IPC::Cmd as a replacement for File:Rsync. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1499684&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:26:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:26:04 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1310495 ] check_snmp.c Doesn't Compile on RH7.3 Message-ID: Bugs item #1310495, was opened at 2005-10-01 22:09 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1310495&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Craig Orsinger (cjorsinger) >Assigned to: Ton Voon (tonvoon) Summary: check_snmp.c Doesn't Compile on RH7.3 Initial Comment: Because there's a local variable declared in the middle of a while loop, this source file won't compile on RedHat 7.3. The error was introduced in nagios-plugins version 1.4.1, and still exists in version 1.4.2. I've attempted to attach a patch file that fixes this. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:26 Message: Logged In: YES user_id=664364 Craig, Robby, Thanks for your patches. Applied to CVS now. Ton ---------------------------------------------------------------------- Comment By: Craig Orsinger (cjorsinger) Date: 2006-01-13 22:13 Message: Logged In: YES user_id=1261217 Thanks, alierak. It looks like they're not using the asprintf() function correctly. It appears, based on the man page and some experimentation, that you're supposed to pass it the address of an empty string pointer, and then free() that string once you're done with it. This isn't what they're doing. In fact, they use asprintf several times in this same source file without freeing the strings. I'm surprised they haven't noticed memory leak problems in this plugin. I'm not sure what the best way to fix the problem is, but I'm attempting to attach your fix as a patch. My original was a quick fix for the immediate issue, which was just getting the thing to build so I could try it out. I can't try to fix this right now, because my network's in disarray and I don't have nagios running on it. ---------------------------------------------------------------------- Comment By: Robby Griffin (alierak) Date: 2006-01-13 19:35 Message: Logged In: YES user_id=83996 Well, no, sourceforge won't let me attach a file to someone else's bug report, so here you go: --- nagios-plugins-1.4.2/plugins/check_snmp.c.orig Wed Jun 1 15:41: 01 2005 +++ nagios-plugins-1.4.2/plugins/check_snmp.c Thu Jan 12 18:22: 47 2006 @@ -337,10 +337,17 @@ asprintf (&outbuff, "%s %s", outbuff, unitv[i]); i++; - +#if 0 char *str[MAX_INPUT_BUFFER]; asprintf(str, "=%s%s;;;; ", show, type ? type : ""); strcat(perfstr, *str); +#else + strcat(perfstr, "="); + strcat(perfstr, show); + if (type) + strcat(perfstr, type); + strcat(perfstr, ";;;; "); +#endif } /* end while (ptr) */ ---------------------------------------------------------------------- Comment By: Robby Griffin (alierak) Date: 2006-01-13 19:33 Message: Logged In: YES user_id=83996 Still exists in CVS, too, and also won't compile on NetBSD 1.6. I don't like this variable declaration at all, btw, because it's an array of pointers to strings, which the program then uses as if it were a pointer to a string. I'll attach an alternate patch which eliminates the declaration entirely. ---------------------------------------------------------------------- Comment By: Jeremy D Pavleck (judg3) Date: 2005-11-19 05:50 Message: Logged In: YES user_id=510182 exact same problem on Solaris 9. The patch fixed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1310495&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:29:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:29:10 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1213786 ] Enable SNMP version 2c in check_snmp.c Message-ID: Patches item #1213786, was opened at 2005-06-02 21:42 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1213786&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alan Hagge (ahagge) >Assigned to: Ton Voon (tonvoon) Summary: Enable SNMP version 2c in check_snmp.c Initial Comment: This patch (against version 1.4) allows check_snmp.c to support SNMP version 2c. This is needed to support 64-bit counters in some equipment (such as ethernet switches) which roll their 32-bit counters too frequently. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:29 Message: Logged In: YES user_id=664364 Alan, Thanks for taking the time to raise this. Already in CVS. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1213786&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:41:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:41:43 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1540327 ] check_disk C_IDFP/W_IDFP inputerror, affects 1.4.3 not 1.4.2 Message-ID: Bugs item #1540327, was opened at 2006-08-15 02:25 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1540327&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 Submitted By: Karl Kornel (akkornel) >Assigned to: Ton Voon (tonvoon) Summary: check_disk C_IDFP/W_IDFP inputerror, affects 1.4.3 not 1.4.2 Initial Comment: The check_disk plugin that comes in nagios-plugins- 1.4.3 does not work for me: $ ./check_disk -w 25% -c 10% -p /home INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (0.0) and both should be between zero and 100 percent, inclusive for /home 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] When I configured nagios-plugins-1.4.3, I ran `./configure --prefix=/usr/local/nagios-stage -- disable-nls --disable-rpath --with-cgiurl=/cgi-bin -- with-nagios-user=nagios --with-nagios-group=nagios -- with-trusted- path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr /local/sbin --with-mysql=/usr`, and got the following results: --with-ping6-command: /bin/ping6 -n -U -w %d -c %d %s --with-ping-command: /bin/ping -n -U -w %d -c %d %s --with-lwres: no --with-ipv6: yes --with-mysql: /usr/bin/mysql_config --with-openssl: yes --with-gnutls: no --enable-emulate-getaddrinfo: no --with-perl: /usr/bin/perl --with-cgiurl: /cgi-bin --with-nagios-user: nagios --with-nagios-group: nagios --with-trusted- path: /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/us r/local/sbin Building check_disk on 1.4.3 resulted in the following commands (and errors): if gcc -DLOCALEDIR=\"/usr/local/nagios- stage/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. - I.. -I../lib -I../intl -I/usr/include/ldap - I/usr/include/postgresql -I/usr/include -Wall -g - O2 -MT check_disk.o -MD -MP - MF ".deps/check_disk.Tpo" -c -o check_disk.o check_disk.c; \ then mv - f ".deps/check_disk.Tpo" ".deps/check_disk.Po"; else rm -f ".deps/check_disk.Tpo"; exit 1; fi check_disk.c: In function 'main': check_disk.c:171: warning: statement with no effect check_disk.c:172: warning: statement with no effect check_disk.c: At top level: check_disk.c:47: warning: 'inode_format' defined but not used /bin/sh ../libtool --mode=link --tag=CC gcc -Wall -g - O2 -L. -o check_disk check_disk.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lssl -lcrypto gcc -Wall -g -O2 -o check_disk check_disk.o utils.o popen.o -L/home/nagios/nagios-plugins- 1.4.3/plugins ../lib/libnagiosplug.a ../lib/libcoreuti ls.a -lssl -lcrypto NOTE: The check_disk that came with 1.4.2 was fine! When I compiled nagios-plugins-1.4.2, I ran `./configure`, and got the following results: --with-perl: /usr/bin/perl --with-cgiurl: /nagios/cgi-bin --with-nagios-user: nagios --with-nagios-group: nagios --with-trusted-path: /bin:/sbin:/usr/bin:/usr/sbin --with-ping-command: /bin/ping -n -U -w %d -c %d %s --with-ping6-command: /bin/ping6 -n -U -w %d -c %d %s --with-lwres: no --with-ipv6: yes --with-openssl: yes --enable-emulate-getaddrinfo: no Building check_disk on 1.4.2 resulted in the following commands being executed: if gcc - DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/include/ldap -I/usr/include/postgresql - I/include -g -O2 -MT check_disk.o -MD -MP - MF ".deps/check_disk.Tpo" -c -o check_disk.o check_disk.c; \ then mv - f ".deps/check_disk.Tpo" ".deps/check_disk.Po"; else rm -f ".deps/check_disk.Tpo"; exit 1; fi gcc -g -O2 -L. -L/usr/lib -o check_disk check_disk.o utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -I/usr/include Finally, running v1.4.2 of check_disk gives me: $ ./check_disk -w 25% -c 10% -p /home DISK OK - free space: /home 46355 MB (92%);| /home=4042MB;37797;45356;0;50396 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:41 Message: Logged In: YES user_id=664364 Hi all, Can you please try the check_disk in the snapshot. There have been major changes, including initialising variables correctly. http://nagiosplug.sf.net/snapshot. I'll mark this call in pending - please update if it still a problem. Ton ---------------------------------------------------------------------- Comment By: Hector Lasso (hectorlasso) Date: 2006-09-04 23:19 Message: Logged In: YES user_id=1590688 I also had this problem on a server with SUSE (kernel recompiled). After checking and checking I found out that on the arguments processing function, when the option is -p (line 457) the values are copied to a structure (a node of a linked list), however the values of w_idfp and c_idfp are not copied to the structure. I addded the following two lines: se->w_idfp = w_idfp; se->c_idfp = c_idfp; before the line "se->found = 0;" recompiled and it worked fine. I didn't have time to check all the code so the problem might be somewhere else. ---------------------------------------------------------------------- Comment By: Augustine (augustine_ab) Date: 2006-08-24 17:04 Message: Logged In: YES user_id=1583130 I experienced this problem when building plugins for AIX (code works fine on linux). It appears the issue is uninitialized name_list structure. My quick fix was to add memset after each malloc: se = (struct name_list *) malloc (sizeof (struct name_list)); memset(se,0,sizeof(struct name_list)); hope this helps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1540327&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:43:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:43:27 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1487560 ] Problem with check_disk on HPUX 11 Message-ID: Bugs item #1487560, was opened at 2006-05-12 18:22 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487560&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Bill Jarrett (wfjarrett) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk on HPUX 11 Initial Comment: There seems to be a problem with the way check_disk behaves with device names over a certain length on HPUX 11.00 I downloaded precompiled nagios-plugins binaries from nagios exchange, but I believe this applies to all versions of the plugin. On HPUX 11.00, if a device name is long enough that it goes into the next column of the output, a newline is put in after the device name. It appears that check_disk ignores everything after the newline, when it should just change it to a space or ignore it #./check_disk -w 20% -c 10% -p /dev/vgdbprod/live_arch Unable to read output: /usr/bin/df -Pk /dev/vgdbprod/live_arch /dev/vgdbprod/live_arch ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:43 Message: Logged In: YES user_id=664364 Bill, There have been major changes to check_disk. Please try the snapshot at http:// nagiosplug.sf.net/snapshot. This call is marked into pending. Please change if it is still a problem. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 14:55 Message: Logged In: YES user_id=664364 Bill, Which version of the plugins are you using? df output hasn't been used since 1.4 was released. Please try the snapshot at http://nagiosplug.sf.net/snapshot. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1487560&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:44:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:44:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1485816 ] check_disk exclude option always exludes (/) Message-ID: Bugs item #1485816, was opened at 2006-05-10 18:52 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: maemigh (maemigh) Assigned to: Ton Voon (tonvoon) Summary: check_disk exclude option always exludes (/) Initial Comment: check_disk (1.64) always exludes (/) when using -x. For example, the output below shows that using -x /var also causes the (/) directory to be excluded. ./check_disk -w 10% -c 5% DISK WARNING - free space: / 4153 MB (69% inode=90%); /var 5660 MB (94% inode=99%); /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ./check_disk -w 10% -c 5% -x /var DISK OK - free space: /var/run 4369 MB (100% inode=64%); /tmp 4369 MB (81% inode=64%); /opt 16292 MB (90% inode=98%); /home/applications 20110 MB (50% inode=95%); ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:44 Message: Logged In: YES user_id=664364 maemigh, Am I right in saying this can be closed now? I'll mark into pending so it will auto close after 7 days. Please update if it is still an issue. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 00:12 Message: Logged In: YES user_id=664364 maemigh, I'm made some major changes to check_disk which should fix the original problem. One change was to move the filesystem comparisons out into utils_disk.c. I'd definitely be interested in your wildcard patch if you can add it into utils_disk.c with some libtap tests in lib/tests/test_disk.c. Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-22 01:04 Message: Logged In: YES user_id=1520524 Sorry for so many updates. I don't know how I missed a small bug. I set the comment in the file for what I meant to happen, but forgot to change the values after I pasted it. I retested it (now that I'm wide awake) and it seems to be working as expected. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-21 02:47 Message: Logged In: YES user_id=1520524 Uploading version 1.65.3m. This one adds slightly better HTML formatted text (places *s around the partition that triggered the alarm) and adds an -a option. The -a option tells check_disk to display all partitions even if -p is also specified: Example check_disk -w 10% -c 5% -a -C -w 5% -c 3% -p / Checks / at 5% and 3% and every other mount at 10% and 5% ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 08:14 Message: Logged In: YES user_id=1520524 Forgot to mention: -p should be working the same way it has been in the past. ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-20 08:12 Message: Logged In: YES user_id=1520524 I didn't test the last upload enough, so I removed it. I've added lots of additional code to check_disk and I've tested it with every scenario I could think of (including the one you mentioned earlier). It all seems to work properly now. I have added several new features as well: -x will exclude a mount point that matches exactly -s will exclude a path and any mount points within -U outputs the percentages in terms of used space/inodes -H formats the output in HTML (makes it really easy to read on the status page) I think I'm going to continue working on it as I might want the ability to specify different warn/crit percentages for different mount points; any suggestions on how to go about doing that would be nice :) I've attached the file, versioned 1.65.1 ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-18 16:39 Message: Logged In: YES user_id=1520524 To answer your question, -X cdfs will not work. The cdrom mount is all ufs and -X ufs will exclude a few extra partitions. I've gone and recoded the file. I've added an extra switch (-s) which will exclude an entire path structure whereas -x will only exclude exact matches. (ie -x /var will NOT exclude /var/run; -s /var WILL exclude both /var and /var/run). This code should also behave the same way it used to -- -p /etc will include (/). I've attached a copy of the whole file. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-18 13:39 Message: Logged In: YES user_id=664364 maemigh, Thanks for the report and the patch! I'm not really keen on the wildcard addition. Tracker 1485683 (http:// sourceforge.net/tracker/index.php? func=detail&aid=1485683&group_id=29880&atid=397600) could be overcome by using a -X cdfs option. However, the patch for the exact name is interesting, because I think there are several bugs reported which this may fix. I've tried the patch out and I get a regression test failure. Prior to your patch, ./check_disk -p /etc would report the result for / (just like df /etc would). However, with the exact length check, check_disk now complains that /etc is not found. Thinking some more about it, this is probably acceptable since check_disk is a sysadmin tool rather than a user tool. Any opinions from anyone else? Ton ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 22:53 Message: Logged In: YES user_id=1520524 I forgot to mention that it appeared the plugin was trying to exlude everything that stems from a path when used with -x (although the function was broken). I've implemented it with a wildcard because you may have a mount within the directory of another mount. In the case above, if we were to use the old method, not only would /var be excluded, but also /var/run (and this is not desired). ---------------------------------------------------------------------- Comment By: maemigh (maemigh) Date: 2006-05-11 19:20 Message: Logged In: YES user_id=1520524 I modified the walk_name_list function to operate properly. Additionally, my changes took care of my feature request (1485683) as well. I tried every test case I could think of and the code seemed to work properly. Please review for correctness and efficiency. int walk_name_list (struct name_list *list, const char *name) { int name_len; name_len = strlen(name); while (list) { /* if the paths match up to the length of the search path, * AND if the paths names are the same length then we have a winner. * OR if the search path is shorter than the mount path and * ends with the wildcard '*' we have a winner. * The wildcard character must be escaped out, thus list_name_len-2 */ int list_name_len; list_name_len = strlen(list->name); if ((name_len == list_name_len && strncmp(list->name, name, list_name_len) == 0) || (name_len >= list_name_len && strncmp(list->name, name, list_name_len-2) == 0 && strncmp(&list->name[list_name_len-1], "*", 1) == 0)) { list->found = 1; list->found_len = name_len; /* if required for name_lists that have not saved w_df, etc (eg exclude lists) */ if (list->w_df) w_df = list->w_df; if (list->c_df) c_df = list->c_df; if (list->w_dfp>=0.0) w_dfp = list->w_dfp; if (list->c_dfp>=0.0) c_dfp = list->c_dfp; return TRUE; } list = list->name_next; } return FALSE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1485816&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:46:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:46:24 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 07:04 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Pending Resolution: Fixed Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:46 Message: Logged In: YES user_id=664364 Tobias, Can you checkout the CVS snapshot please. Perf data has recently been added back in and should be okay now. Marking this call into pending. Ton ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-10-10 13:06 Message: Logged In: YES user_id=481892 Hi tonvoon, today I checked the actual release 1.4.3. But the problem still persists. Here is what check_disk prints to stdout. The ext2 filesystem /boot is ok. All others are reiserfs. :-( DISK OK - free space:| /=118MB;818;920;-2147483648;1023 /boot=14MB;103;116;99;129 /home=192MB;818;920;-2147483648;1023 /opt=550MB;1637;1842;-2147483648;2047 /srv=57MB;408;459;-2147483648;511 /tmp=144MB;818;920;-2147483648;1023 /usr=731MB;1637;1842;-2147483648;2047 /usr/local=44MB;408;459;-2147483648;511 /var=167MB;818;920;-2147483648;1023 /var/tmp=61MB;818;818;-2147483648;1023 Thanks Tobias ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-08-17 12:31 Message: Logged In: YES user_id=481892 Hi, sorry that I could not test the newest version earlier but yesterday I did. The problem with it is, that we use the performance data output to update rrd files. Besides the actual value we also read the warning and critical threshold, the min and max value. In the new version these are gone. This is the output from the actual version I tested. > ./check_disk (nagios-plugins 1.4.3) 1.75 > ./check_disk -w 10% -c 5% -p /home DISK OK - free space: /home 1720 MB (41% inode=-);| /home=2375MB;;; Maybe you could just check if min is lower than 0 and than set it to zero? Thanks again. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 00:15 Message: Logged In: YES user_id=664364 Tobias, Can you please try the latest snapshot? The min value has been removed (which is one way of fixing your original problem :) ). But the values calculated should now be consistent with df output. The inode value will be printed as "-" which is consistent with df -i. Ton ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-06-19 06:43 Message: Logged In: YES user_id=481892 Hi everybody, sorry, since I am not a C programmer I can't figure out the problem, but it still persists. Tried newest plugin version. ~> /opt/nagios/plugins/check_disk --version check_disk (nagios-plugins 1.4.3) 1.67 ~> /opt/nagios/plugins/check_disk -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;511;511;-2147483648;511 I reopend the call again. Thanks. Tobias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-06-15 08:52 Message: Logged In: YES user_id=664364 Hi all! The patch by Ralph is already applied to CVS in check_disk.c v1.67. Please try the snapshot at http://nagiosplug.sf.net/snapshot. I'm putting this call into pending. Ton ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-06-15 08:12 Message: Logged In: YES user_id=1526665 Hi everybody! I have similar problem on FreeBSD 6.1 with check_disk.c,v 1.64 2006/03/27 08:19:01 Ralph R??ner patch solved this problem. ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-18 10:28 Message: Logged In: YES user_id=481892 Hi everybody, checked out newest snapshot 20060517 but same problem. Tobias ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-05-08 19:08 Message: Logged In: YES user_id=1515003 Hi everybody! I have a similar problem on Solaris, only I get bitten by validate_arguments(), which complains that "C_IDFP (67065044...467904.000000) should be less than W_IDFP (0.0)". It appears that the minimum free inode percentage was not correctly initialized. This only appears when file systems are selected with "-p". The reason I suspect is that the c_idfp and w_idfp members of the path list structure are never initialized in this case, at least not at the point where c_dfp and w_dfp are (check_disk.c lines 457ff). So random malloc()ed memory is passed to validate_arguments(), and the results vary according to architecture and phase of the moon. I created a patch that treats the [cw]_idfp like [cw]_dfp at the point where the "-p" argument is parsed. This makes the problem go away for me. If there are other places where the path list is added to then there is a good chance that the same oversight happened there too. Since I don't find a way to attach a file to a thread I did not open, I will include the patch here: --8><----------------------------------- *** nagios-plugins-1.4.3/plugins/check_disk.c.orig Mon May 8 19:50:33 2006 --- nagios-plugins-1.4.3/plugins/check_disk.c Mon May 8 19:49:48 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; --8><----------------------------------- Hope this helps, Ralph R??ner ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-05 15:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 09:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:47:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:47:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480574 ] check_disk is missing -lm on Solaris (rel. 1.4.3) Message-ID: Bugs item #1480574, was opened at 2006-05-02 19:03 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Submitted By: Ralph R??ner (ralph_roessner) >Assigned to: Ton Voon (tonvoon) Summary: check_disk is missing -lm on Solaris (rel. 1.4.3) Initial Comment: The common.h include defines, on Solaris only, a replacement definition for floorf(), which Solaris (up to and including version 8) does not have. Thus, on Solaris only, all plugins including common.h need a definition of floor() (on Linux that would be necessary only for those plugins that actually use floorf()), i.e. they need to link libm.so . The Makefile.in does not respect that need, and consequently compiling check_disk on Solaris fails. I would expect all other plugins that include common.h to have the same problem, but strangely that appears not to be the case. For my needs it was sufficient to add MATHLIBS to the dependency line for check_disk in the plugins/Makefile.in, and I include a patch that does exactly that. However, this should probably be resolved more generally. Regards, Ralph R??ner ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:47 Message: Logged In: YES user_id=664364 Ralph, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. The check_disk code has been re-written without the use of floorf anymore. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 From noreply at sourceforge.net Thu Oct 19 21:49:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:49:05 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-05 00:59 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&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 Submitted By: Ted Cabeen (secabeen) Assigned to: Ton Voon (tonvoon) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:49 Message: Logged In: YES user_id=664364 Doesn't look like any updates since I last requested in July. Marking call into pending. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 00:18 Message: Logged In: YES user_id=664364 Ted, Can you try the latest snapshot at http://nagiosplug.sf.net/snapshot. There have been major changes to check_disk to sync it with coreutils' df so there shouldn't be sign problems. If you still have problems, can you tell me what version of df are you using? Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-11-08 12:05 Message: Logged In: YES user_id=664364 >From 1.4 onwards, we use the GNU coreutils library to get df data. I don't know if FreeBSD use their own routines or not, but GNU coreutils should support it. Yes, I guess signed integers should fix. Was an assumption on our part that values would be always positive. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-08 11:28 Message: Logged In: YES user_id=226838 hi, well chalk this up to my having been away from traditional unix/bsd implementations. afaict in linux such reserved space is still taken into calculation of total available space (ie, you could get ENOSPC before the disk reached 0%). but anyway, i think the fix is still obvious, that we should do all scans and assignments as signed integers instead of unsigned. if i don't hear any complaints from anyone else on the plugins team, i'll probably do this at some point (and hope that it doesn't break something else) also, having taken a look at the check_disk code, i can't seem to find any references to the df program... so i guess if you're using 1.4.2 or later that it's purely within the internal disk space routines. ---------------------------------------------------------------------- Comment By: Ted Cabeen (secabeen) Date: 2005-11-07 21:25 Message: Logged In: YES user_id=40466 All modern unix file-systems reserve a portion (5-10%) of the disk space for use by root only and to speed disk accesses. If the root user exceeds the normal disk space and uses some of the reserve space, the system will represent the amount of free space as negative. I don't know how check_disk is checking the disk space (df or internal routines). Is there an easy way to check? check_disk (nagios-plugins 1.4.2) 1.57 is the version I'm running. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-07 12:56 Message: Logged In: YES user_id=226838 hi, um, i just have to ask. how do you have negative free space? some other information that would be helpful: - is check_disk using the df command or internal disk space routines? - if df, what df command syntax is check_disk using? - what version of the plugins are you using? i believe that the plugin is making an assumption that the amount of disk space available is unsigned, because, er... well i'd never heard of negative disk space, anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From nathan.vonnahme at bannerhealth.com Thu Oct 19 21:49:23 2006 From: nathan.vonnahme at bannerhealth.com (Vonnahme, Nathan) Date: Thu, 19 Oct 2006 11:49:23 -0800 Subject: [Nagiosplug-devel] [RFC] Plugins config file Message-ID: <077F1B782014ED48A58E7927914D36A0023613AA@fai01500.bhs.bannerhealth.com> Ton Voon wrote, > However, if you use Nathan's separate args form, you'd have to parse all the options before you can replace (as you may not want the default stanza name). Also where do you replace? > > ./check_mysql -S --cfg-file= -H localhost --cfg-stanza= > > Do you replace --cfg-file or --cfg-stanza? I think to avoid the confusion (at the expense of a more obscure syntax), it should be a single option. This then allows Gavin's request of having multiple options. So: > > ./check_mysql -S --extra-opts= --extra-opts=more_options -H localhost > > Is effectively: > > ./check_mysql -S --username=tonvoon --password=secret --username=altinity --warning=10 --critical=15 -H localhost > > I think this is fairly intuitive. Notice username is listed twice. I don't think the "replacement opts" function should care what has passed before or after - it just puts everything down since some plugins expect arguments a multiple number of times (check_disk -p / -p /var). How the plugin responds to double requests is the plugin's responsibility. I guess I was thinking you'd parse the options and then load the config files, but always allow explicit command line options to override things in the cfg files. something like this (Perlishly... sorry my C is too rusty): given the invocation ./check_mysql -S --extra-opts= --extra-opts=more_options -H localhost --critical=99 and the files default.cfg (username=tonvoon, password, warning, critical) and more_options (username=altinity) get all the command line options, giving you a data structure like this: $opts = [ {name=>S, value=>undef}, {name=>host , value=>localhost}, {name=>extra-opts, value=>undef}, {name=>extra-opts, value=>more_options}, {name=>critical, value=>99}, ]; then, for each extra-opts arg, slurp the appropriate part of the appropriate config file into the $opts array, and delete the extra-opts options. In this case the username from the second config file would overwrite the first, and the data structure would end up: $opts = [ {name=>S, value=>undef}, {name=>host , value=>localhost}, {name=>username , value=>altinity}, {name=>password, value=>secret}, {name=>warning, value=>10}, {name=>critical, value=>99}, ]; If you are parsing it this way, having two separate options for file and stanza makes sense, and allows you to, for example: load all args from the 'my_plugin' stanza of the default cfg file my_plugin --cfg-file load from the mysql stanza of the default cfg file instead my_plugin --cfg-stanza=mysql load all args from the 'my_plugin' stanza of the /other/file cfg file my_plugin --cfg-file=/other/file load args from the default cfg file, but then override from the mysql stanza from /other/file, but override any definition of 'critical' in the cfg files with critical=99 my_plugin --critical=99 --cfg-file --cfg-file=/other/file --cfg-stanza=mysql So we would have clear syntax, and clear expectations that command line options override things in the cfg files and the second cfg file mentioned in the command line options overrides the first. From noreply at sourceforge.net Fri Oct 20 11:28:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 02:28:23 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1481615 ] Problem with check_disk Message-ID: Bugs item #1481615, was opened at 2006-05-04 08:04 Message generated for change (Comment added) made by mucke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tobias Mucke (mucke) Assigned to: Ton Voon (tonvoon) Summary: Problem with check_disk Initial Comment: Hi everybody, yesterday I tried the new plugin version 1.4.3. I experienced a problem with check_disk. Here is the output. Filesystem /home is a reiserfs. I guess that's the reason for inode=nan%?. But that's not the problem. Look at the performance data. In the MIN field. It should be 0 but it is -2147483648. /opt/nagios/plugins/check_disk -w 20 -c 10 -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;491;501;-2147483648;511 Thanks in advance. Tobias ---------------------------------------------------------------------- >Comment By: Tobias Mucke (mucke) Date: 2006-10-20 11:28 Message: Logged In: YES user_id=481892 Hi Ton, checked newest version. Problem fixed. Thanks a lot. I closed the bug report. Tobias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-10-19 21:46 Message: Logged In: YES user_id=664364 Tobias, Can you checkout the CVS snapshot please. Perf data has recently been added back in and should be okay now. Marking this call into pending. Ton ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-10-10 14:06 Message: Logged In: YES user_id=481892 Hi tonvoon, today I checked the actual release 1.4.3. But the problem still persists. Here is what check_disk prints to stdout. The ext2 filesystem /boot is ok. All others are reiserfs. :-( DISK OK - free space:| /=118MB;818;920;-2147483648;1023 /boot=14MB;103;116;99;129 /home=192MB;818;920;-2147483648;1023 /opt=550MB;1637;1842;-2147483648;2047 /srv=57MB;408;459;-2147483648;511 /tmp=144MB;818;920;-2147483648;1023 /usr=731MB;1637;1842;-2147483648;2047 /usr/local=44MB;408;459;-2147483648;511 /var=167MB;818;920;-2147483648;1023 /var/tmp=61MB;818;818;-2147483648;1023 Thanks Tobias ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-08-17 13:31 Message: Logged In: YES user_id=481892 Hi, sorry that I could not test the newest version earlier but yesterday I did. The problem with it is, that we use the performance data output to update rrd files. Besides the actual value we also read the warning and critical threshold, the min and max value. In the new version these are gone. This is the output from the actual version I tested. > ./check_disk (nagios-plugins 1.4.3) 1.75 > ./check_disk -w 10% -c 5% -p /home DISK OK - free space: /home 1720 MB (41% inode=-);| /home=2375MB;;; Maybe you could just check if min is lower than 0 and than set it to zero? Thanks again. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-20 01:15 Message: Logged In: YES user_id=664364 Tobias, Can you please try the latest snapshot? The min value has been removed (which is one way of fixing your original problem :) ). But the values calculated should now be consistent with df output. The inode value will be printed as "-" which is consistent with df -i. Ton ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-06-19 07:43 Message: Logged In: YES user_id=481892 Hi everybody, sorry, since I am not a C programmer I can't figure out the problem, but it still persists. Tried newest plugin version. ~> /opt/nagios/plugins/check_disk --version check_disk (nagios-plugins 1.4.3) 1.67 ~> /opt/nagios/plugins/check_disk -p /home DISK OK - free space: /home 480 MB (94% inode=nan%);| /home=32MB;511;511;-2147483648;511 I reopend the call again. Thanks. Tobias ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-06-15 09:52 Message: Logged In: YES user_id=664364 Hi all! The patch by Ralph is already applied to CVS in check_disk.c v1.67. Please try the snapshot at http://nagiosplug.sf.net/snapshot. I'm putting this call into pending. Ton ---------------------------------------------------------------------- Comment By: Olexandr Davydenko (blackraven1977) Date: 2006-06-15 09:12 Message: Logged In: YES user_id=1526665 Hi everybody! I have similar problem on FreeBSD 6.1 with check_disk.c,v 1.64 2006/03/27 08:19:01 Ralph R??ner patch solved this problem. ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-18 11:28 Message: Logged In: YES user_id=481892 Hi everybody, checked out newest snapshot 20060517 but same problem. Tobias ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-05-08 20:08 Message: Logged In: YES user_id=1515003 Hi everybody! I have a similar problem on Solaris, only I get bitten by validate_arguments(), which complains that "C_IDFP (67065044...467904.000000) should be less than W_IDFP (0.0)". It appears that the minimum free inode percentage was not correctly initialized. This only appears when file systems are selected with "-p". The reason I suspect is that the c_idfp and w_idfp members of the path list structure are never initialized in this case, at least not at the point where c_dfp and w_dfp are (check_disk.c lines 457ff). So random malloc()ed memory is passed to validate_arguments(), and the results vary according to architecture and phase of the moon. I created a patch that treats the [cw]_idfp like [cw]_dfp at the point where the "-p" argument is parsed. This makes the problem go away for me. If there are other places where the path list is added to then there is a good chance that the same oversight happened there too. Since I don't find a way to attach a file to a thread I did not open, I will include the patch here: --8><----------------------------------- *** nagios-plugins-1.4.3/plugins/check_disk.c.orig Mon May 8 19:50:33 2006 --- nagios-plugins-1.4.3/plugins/check_disk.c Mon May 8 19:49:48 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; --8><----------------------------------- Hope this helps, Ralph R??ner ---------------------------------------------------------------------- Comment By: Tobias Mucke (mucke) Date: 2006-05-05 16:20 Message: Logged In: YES user_id=481892 Ton, checked it, but same problem. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-05-05 10:37 Message: Logged In: YES user_id=664364 Tobias, Can you check the snapshot at http://nagiosplug.sf.net/snapshot? There was a fix reported for inode problems on Solaris, but probably applicable to reiserfs too. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1481615&group_id=29880 From flo at bier.homeip.net Fri Oct 20 12:45:13 2006 From: flo at bier.homeip.net (Florian Gleixner) Date: Fri, 20 Oct 2006 12:45:13 +0200 Subject: [Nagiosplug-devel] Patch for check_oracle.sh and compile error at check_ntp.c Message-ID: <4538A8B9.9070706@bier.homeip.net> Hi, i realized, that you forgot to include my patch - probably because i did not use sourceforge's patch management. I've attached the old mails. I tried to make plugins-1.4.4 and got this error: make[2]: Entering directory `/var/tmp/nagios-plugins-1.4.4/plugins' if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap -I/usr/include/pgsql -I/usr/include -g -O2 -MT check_ntp.o -MD -MP -MF ".deps/check_ntp.Tpo" -c -o check_ntp.o check_ntp.c; \ then mv -f ".deps/check_ntp.Tpo" ".deps/check_ntp.Po"; else rm -f ".deps/check_ntp.Tpo"; exit 1; fi cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory check_ntp.c: In function `setup_request': check_ntp.c:295: invalid operands to binary & check_ntp.c:295: invalid operands to binary & check_ntp.c:295: invalid operands to binary & check_ntp.c:295: invalid operands to binary & make[2]: *** [check_ntp.o] Error 1 make[2]: Leaving directory `/var/tmp/nagios-plugins-1.4.4/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/nagios-plugins-1.4.4' make: *** [all] Error 2 it's a pretty old machine with Suse Linux Enterprise 8 and a 2.4.19 Linux Kernel. Florian Gleixner -------- Original Message -------- Date: Thu, 17 Aug 2006 11:12:02 +0200 From: Florian Gleixner To: Nagios Plugin Development Mailing List Subject: Re: [Nagiosplug-devel] Patch for check_oracle.sh OOps, one forgot one NVL()! @@ -244,13 +244,14 @@ result=`sqlplus -s ${3}/${4}@${2} << EOF set pagesize 0 set numf '9999999.99' -select b.free,a.total,100 - trunc(b.free/a.total * 1000) / 10 prc +select NVL(b.free,0.0),a.total,100 - trunc(NVL(b.free,0.0)/a.total * 1000) / 10 prc from ( select tablespace_name,sum(bytes)/1024/1024 total -from dba_data_files group by tablespace_name) A, +from dba_data_files group by tablespace_name) A +LEFT OUTER JOIN ( select tablespace_name,sum(bytes)/1024/1024 free from dba_free_space group by tablespace_name) B -where a.tablespace_name=b.tablespace_name and a.tablespace_name='${5}'; +ON a.tablespace_name=b.tablespace_name WHERE a.tablespace_name='${5}'; EOF` if [ -n "`echo $result | grep ORA-`" ] ; then Florian Gleixner wrote: > Hi, > > check_oracle gives > > /usr/local/nagios/libexec/check_oracle: [: : integer expression expected > /usr/local/nagios/libexec/check_oracle: [: : integer expression expected > /usr/local/nagios/libexec/check_oracle: [: : integer expression expected > > if the table dba_free_space does not contain any free segment -> the > tablespace is 100% full. I changed the query so that it returns 100% in > this condition. > > Here's the patch: > > diff -ud check_oracle.sh check_oracle > --- check_oracle_v14.sh 2006-08-17 10:57:29.605426000 +0200 > +++ check_oracle 2006-08-17 10:59:16.006634000 +0200 > @@ -244,13 +244,14 @@ > result=`sqlplus -s ${3}/${4}@${2} << EOF > set pagesize 0 > set numf '9999999.99' > -select b.free,a.total,100 - trunc(b.free/a.total * 1000) / 10 prc > +select b.free,a.total,100 - trunc(NVL(b.free,0.0)/a.total * 1000) / 10 prc > from ( > select tablespace_name,sum(bytes)/1024/1024 total > -from dba_data_files group by tablespace_name) A, > +from dba_data_files group by tablespace_name) A > +LEFT OUTER JOIN > ( select tablespace_name,sum(bytes)/1024/1024 free > from dba_free_space group by tablespace_name) B > -where a.tablespace_name=b.tablespace_name and a.tablespace_name='${5}'; > +ON a.tablespace_name=b.tablespace_name WHERE a.tablespace_name='${5}'; > EOF` > > if [ -n "`echo $result | grep ORA-`" ] ; then > > > > Florian Gleixner > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________________ > 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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________________ 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 Fri Oct 20 18:31:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 09:31:04 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1581402 ] utils.pm no longer allows hyphens in hostnames Message-ID: Bugs item #1581402, was opened at 2006-10-20 18:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1581402&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Holger Wei? (hweiss) Assigned to: Nobody/Anonymous (nobody) Summary: utils.pm no longer allows hyphens in hostnames Initial Comment: With revision 1.9 of plugins-scripts/utils.pm.in, is_hostname was changed to allow hostnames beginning with digits. However, due to this change, hyphens within hostnames are no longer allowed. The attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1581402&group_id=29880 From noreply at sourceforge.net Mon Oct 23 17:11:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Oct 2006 08:11:29 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480574 ] check_disk is missing -lm on Solaris (rel. 1.4.3) Message-ID: Bugs item #1480574, was opened at 2006-05-02 20:03 Message generated for change (Comment added) made by ralph_roessner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Open Resolution: None Priority: 5 Submitted By: Ralph R??ner (ralph_roessner) Assigned to: Ton Voon (tonvoon) Summary: check_disk is missing -lm on Solaris (rel. 1.4.3) Initial Comment: The common.h include defines, on Solaris only, a replacement definition for floorf(), which Solaris (up to and including version 8) does not have. Thus, on Solaris only, all plugins including common.h need a definition of floor() (on Linux that would be necessary only for those plugins that actually use floorf()), i.e. they need to link libm.so . The Makefile.in does not respect that need, and consequently compiling check_disk on Solaris fails. I would expect all other plugins that include common.h to have the same problem, but strangely that appears not to be the case. For my needs it was sufficient to add MATHLIBS to the dependency line for check_disk in the plugins/Makefile.in, and I include a patch that does exactly that. However, this should probably be resolved more generally. Regards, Ralph R??ner ---------------------------------------------------------------------- >Comment By: Ralph R??ner (ralph_roessner) Date: 2006-10-23 17:11 Message: Logged In: YES user_id=1515003 Hi, tried the 200610222352 snapshot. The error persists but has jumped to another plugin. This time, compilation fails for the first plugin to make, check_apt.c, same link error: definition of floor is missing. See, common.h defines (on the Solaris platform) a function floorf(), which is included into all the plugins. Most of the plugins do not use this function. For some, the compiler recognizes this and leaves out the definition. For others (and don't ask me why they are treated differently) the defintion of floorf() remains and triggers the linker to look for floor(). Conclusion: As long as the definition of floor() remains in common.h (line 216), you will need to include a -lm in the link line. I am not a configure master, so i will not provide a patch that does this. I hope someone else will know how to. Regards, Ralph R??ner ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-10-19 21:47 Message: Logged In: YES user_id=664364 Ralph, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. The check_disk code has been re-written without the use of floorf anymore. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 From noreply at sourceforge.net Mon Oct 23 17:30:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Oct 2006 08:30:23 -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 ralph_roessner 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: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: John Rouillard (rouilj) Assigned to: Nobody/Anonymous (nobody) 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: 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 noreply at sourceforge.net Mon Oct 23 17:41:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Oct 2006 08:41:12 -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 cmaser 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: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: John Rouillard (rouilj) Assigned to: Nobody/Anonymous (nobody) 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: 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 noreply at sourceforge.net Tue Oct 24 12:24:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Oct 2006 03:24:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1583467 ] C++ comments used in C code Message-ID: Bugs item #1583467, was opened at 2006-10-24 12:24 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=1583467&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Baertschi (markus_b) Assigned to: Nobody/Anonymous (nobody) Summary: C++ comments used in C code Initial Comment: While compiling nagios-plugins-1.4.4 on AIX using the IBM compiler I'm stumbling over two cases where C++-style comments '//' in stead of proper C comments are used '/* */'. The compiler flags these as Syntax error as this comment style is not allowed in ANSI C. Replacing the // with /* */ fixes the problem and all compiles fine. Here the "check_disk.c", line 639.3: 1506-046 (S) Syntax error. 639: // return; "check_http.c", line 277.7: 1506-046 (S) Syntax error. 277: // asprintf (&http_opt_headers, "%s", optarg); Markus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1583467&group_id=29880 From ton.voon at altinity.com Thu Oct 26 22:47:56 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 26 Oct 2006 21:47:56 +0100 Subject: [Nagiosplug-devel] Notification of new release Message-ID: <0ECB135B-A9FC-4104-80EC-0C377A68832A@altinity.com> Hi! Just to let you know that due to a stupid bug by myself in utils.pm.in, I plan on cutting a 1.4.5 release. Thanks to Holger Weiss for spotting it. I've put a test in place to catch this in future. Benoit has also been updating the localisation for plugins and should be finished by Wed 1st November, so I plan on cutting the next version then. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Thu Oct 26 22:53:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 13:53:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1583467 ] C++ comments used in C code Message-ID: Bugs item #1583467, was opened at 2006-10-24 11:24 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1583467&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: Fixed Priority: 5 Private: No Submitted By: Markus Baertschi (markus_b) >Assigned to: Ton Voon (tonvoon) Summary: C++ comments used in C code Initial Comment: While compiling nagios-plugins-1.4.4 on AIX using the IBM compiler I'm stumbling over two cases where C++-style comments '//' in stead of proper C comments are used '/* */'. The compiler flags these as Syntax error as this comment style is not allowed in ANSI C. Replacing the // with /* */ fixes the problem and all compiles fine. Here the "check_disk.c", line 639.3: 1506-046 (S) Syntax error. 639: // return; "check_http.c", line 277.7: 1506-046 (S) Syntax error. 277: // asprintf (&http_opt_headers, "%s", optarg); Markus ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-26 21:53 Message: Logged In: YES user_id=664364 Markus, Thanks. Fixed in CVS now. Does anyone know how to get cpp to flag that we have used // instead of /* ? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1583467&group_id=29880 From noreply at sourceforge.net Thu Oct 26 23:00:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 14:00:31 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1583467 ] C++ comments used in C code Message-ID: Bugs item #1583467, was opened at 2006-10-24 12:24 Message generated for change (Comment added) made by markus_b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1583467&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: Fixed Priority: 5 Private: No Submitted By: Markus Baertschi (markus_b) Assigned to: Ton Voon (tonvoon) Summary: C++ comments used in C code Initial Comment: While compiling nagios-plugins-1.4.4 on AIX using the IBM compiler I'm stumbling over two cases where C++-style comments '//' in stead of proper C comments are used '/* */'. The compiler flags these as Syntax error as this comment style is not allowed in ANSI C. Replacing the // with /* */ fixes the problem and all compiles fine. Here the "check_disk.c", line 639.3: 1506-046 (S) Syntax error. 639: // return; "check_http.c", line 277.7: 1506-046 (S) Syntax error. 277: // asprintf (&http_opt_headers, "%s", optarg); Markus ---------------------------------------------------------------------- >Comment By: Markus Baertschi (markus_b) Date: 2006-10-26 23:00 Message: Logged In: YES user_id=156828 I've had a short look at the gcc option (I suppose you talk about gcc). There is -pedantic and -Wcomment options which warn for such things. http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Warning-Options.html#Warning-Options Thanks Markus ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-10-26 22:53 Message: Logged In: YES user_id=664364 Markus, Thanks. Fixed in CVS now. Does anyone know how to get cpp to flag that we have used // instead of /* ? Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1583467&group_id=29880 From noreply at sourceforge.net Thu Oct 26 23:02:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 14:02:46 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1581402 ] utils.pm no longer allows hyphens in hostnames Message-ID: Bugs item #1581402, was opened at 2006-10-20 17:31 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1581402&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: Holger Wei? (hweiss) >Assigned to: Ton Voon (tonvoon) Summary: utils.pm no longer allows hyphens in hostnames Initial Comment: With revision 1.9 of plugins-scripts/utils.pm.in, is_hostname was changed to allow hostnames beginning with digits. However, due to this change, hyphens within hostnames are no longer allowed. The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2006-10-26 22:02 Message: Logged In: YES user_id=664364 Holger, Thanks. Fixed in CVS and tests added so no this shouldn't happen again. A new release of the plugins will be cut next week. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1581402&group_id=29880 From ton.voon at altinity.com Thu Oct 26 23:11:53 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 26 Oct 2006 22:11:53 +0100 Subject: [Nagiosplug-devel] Patch for check_oracle.sh and compile error at check_ntp.c In-Reply-To: <4538A8B9.9070706@bier.homeip.net> References: <4538A8B9.9070706@bier.homeip.net> Message-ID: <6AAE2B23-3113-4024-8068-B9ECA2FFA29D@altinity.com> Florian, Thanks for the patches. I've applied the check_oracle one, although I have no access to Oracle to try it out. Can you test the cvs snapshot at http://nagiosplug.sf.net/snapshot please? I have no idea about the check_ntp one. Maybe Sean can help there? Ton On 20 Oct 2006, at 11:45, Florian Gleixner wrote: > Hi, > > i realized, that you forgot to include my patch - probably because > i did > not use sourceforge's patch management. I've attached the old mails. > > I tried to make plugins-1.4.4 and got this error: > > make[2]: Entering directory `/var/tmp/nagios-plugins-1.4.4/plugins' > if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H > -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include/ldap > -I/usr/include/pgsql -I/usr/include -g -O2 -MT check_ntp.o -MD -MP > -MF ".deps/check_ntp.Tpo" -c -o check_ntp.o check_ntp.c; \ > then mv -f ".deps/check_ntp.Tpo" ".deps/check_ntp.Po"; else rm -f > ".deps/check_ntp.Tpo"; exit 1; fi > cc1: warning: changing search order for system directory "/usr/ > include" > cc1: warning: as it has already been specified as a non-system > directory > check_ntp.c: In function `setup_request': > check_ntp.c:295: invalid operands to binary & > check_ntp.c:295: invalid operands to binary & > check_ntp.c:295: invalid operands to binary & > check_ntp.c:295: invalid operands to binary & > make[2]: *** [check_ntp.o] Error 1 > make[2]: Leaving directory `/var/tmp/nagios-plugins-1.4.4/plugins' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/var/tmp/nagios-plugins-1.4.4' > make: *** [all] Error 2 > > it's a pretty old machine with Suse Linux Enterprise 8 and a 2.4.19 > Linux Kernel. > > Florian Gleixner > > -------- Original Message -------- > Date: Thu, 17 Aug 2006 11:12:02 +0200 > From: Florian Gleixner > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] Patch for check_oracle.sh > > > OOps, one forgot one NVL()! > > > @@ -244,13 +244,14 @@ > result=`sqlplus -s ${3}/${4}@${2} << EOF > set pagesize 0 > set numf '9999999.99' > -select b.free,a.total,100 - trunc(b.free/a.total * 1000) / 10 prc > +select NVL(b.free,0.0),a.total,100 - trunc(NVL(b.free,0.0)/a.total * > 1000) / 10 prc > from ( > select tablespace_name,sum(bytes)/1024/1024 total > -from dba_data_files group by tablespace_name) A, > +from dba_data_files group by tablespace_name) A > +LEFT OUTER JOIN > ( select tablespace_name,sum(bytes)/1024/1024 free > from dba_free_space group by tablespace_name) B > -where a.tablespace_name=b.tablespace_name and > a.tablespace_name='${5}'; > +ON a.tablespace_name=b.tablespace_name WHERE > a.tablespace_name='${5}'; > EOF` > > if [ -n "`echo $result | grep ORA-`" ] ; then > > > Florian Gleixner wrote: >> Hi, >> >> check_oracle gives >> >> /usr/local/nagios/libexec/check_oracle: [: : integer expression >> expected >> /usr/local/nagios/libexec/check_oracle: [: : integer expression >> expected >> /usr/local/nagios/libexec/check_oracle: [: : integer expression >> expected >> >> if the table dba_free_space does not contain any free segment -> the >> tablespace is 100% full. I changed the query so that it returns >> 100% in >> this condition. >> >> Here's the patch: >> >> diff -ud check_oracle.sh check_oracle >> --- check_oracle_v14.sh 2006-08-17 10:57:29.605426000 +0200 >> +++ check_oracle 2006-08-17 10:59:16.006634000 +0200 >> @@ -244,13 +244,14 @@ >> result=`sqlplus -s ${3}/${4}@${2} << EOF >> set pagesize 0 >> set numf '9999999.99' >> -select b.free,a.total,100 - trunc(b.free/a.total * 1000) / 10 prc >> +select b.free,a.total,100 - trunc(NVL(b.free,0.0)/a.total * >> 1000) / 10 prc >> from ( >> select tablespace_name,sum(bytes)/1024/1024 total >> -from dba_data_files group by tablespace_name) A, >> +from dba_data_files group by tablespace_name) A >> +LEFT OUTER JOIN >> ( select tablespace_name,sum(bytes)/1024/1024 free >> from dba_free_space group by tablespace_name) B >> -where a.tablespace_name=b.tablespace_name and a.tablespace_name='$ >> {5}'; >> +ON a.tablespace_name=b.tablespace_name WHERE >> a.tablespace_name='${5}'; >> EOF` >> >> if [ -n "`echo $result | grep ORA-`" ] ; then >> >> >> >> Florian Gleixner http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Fri Oct 27 10:39:19 2006 From: ae at op5.se (Andreas Ericsson) Date: Fri, 27 Oct 2006 10:39:19 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-checkins] nagiosplug/plugins-scripts/t utils.t, NONE, 1.1 In-Reply-To: References: Message-ID: <4541C5B7.4010209@op5.se> Ton Voon wrote: > Update of /cvsroot/nagiosplug/nagiosplug/plugins-scripts/t > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv7073/t > > Added Files: > utils.t > Log Message: > Fixed regression where hostnames with hyphens were rejected (1581402 - Holger Weiss) > > > --- NEW FILE: utils.t --- > #!/usr/bin/perl -w -I .. > # > # utils.pm tests > # > # $Id: utils.t,v 1.1 2006/10/26 21:02:21 tonvoon Exp $ > # > > #use strict; > use Test::More; > use NPTest; > > use lib ".."; > use utils; > > my $hostname_checks = { > "www.altinity.com" => 1, > "www.888.com" => 1, > "888.com" => 1, > "host-hyphened.com" => 1, > "rubbish" => 1, > "-start.com" => 0, > "endsindot." => 0, This is a bit odd, really. There's nothing wrong with a hostname ending in a dot. What *is* odd is a hostname ending in a dot that cannot be a fully qualified domainname. "www.google.gom." is actually the *real* address. "www.google.com" gets auto-translated to add the last dot if there is none, whereas "www.google." is not a real address. This is not because it ends with a dot, but because it's missing the top-domain and the ending dot forbids library functions to amend anything to it. I would suggest changing the test-hostname to "nonfqdn-but-ends-in-dot." so as to not confuse future hackers. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Fri Oct 27 16:01:31 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 27 Oct 2006 15:01:31 +0100 Subject: [Nagiosplug-devel] Testcase for is_hostname (was something else) In-Reply-To: <4541C5B7.4010209@op5.se> References: <4541C5B7.4010209@op5.se> Message-ID: On 27 Oct 2006, at 09:39, Andreas Ericsson wrote: > Ton Voon wrote: >> Update of /cvsroot/nagiosplug/nagiosplug/plugins-scripts/t >> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv7073/t >> >> Added Files: >> utils.t >> Log Message: >> Fixed regression where hostnames with hyphens were rejected >> (1581402 - Holger Weiss) >> >> >> --- NEW FILE: utils.t --- >> #!/usr/bin/perl -w -I .. >> # >> # utils.pm tests >> # >> # $Id: utils.t,v 1.1 2006/10/26 21:02:21 tonvoon Exp $ >> # >> >> #use strict; >> use Test::More; >> use NPTest; >> >> use lib ".."; >> use utils; >> >> my $hostname_checks = { >> "www.altinity.com" => 1, >> "www.888.com" => 1, >> "888.com" => 1, >> "host-hyphened.com" => 1, >> "rubbish" => 1, >> "-start.com" => 0, >> "endsindot." => 0, > > This is a bit odd, really. There's nothing wrong with a hostname > ending > in a dot. What *is* odd is a hostname ending in a dot that cannot be a > fully qualified domainname. "www.google.gom." is actually the *real* > address. "www.google.com" gets auto-translated to add the last dot if > there is none, whereas "www.google." is not a real address. This is > not > because it ends with a dot, but because it's missing the top-domain > and > the ending dot forbids library functions to amend anything to it. > > I would suggest changing the test-hostname to "nonfqdn-but-ends-in- > dot." > so as to not confuse future hackers. > This is exactly the kind of discussions I want to see from using testcases! Better we spot these edge cases here, rather than in someone's use of the code. Andreas, I'm not sure what you would like to see. Is it: "nonfqdn-but-ends-in-dot." => 0 "otherwise.something." => 1 ? I know "something" is not an official top-level domain, but I think it is beyond the remit of is_hostname to find that out. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Fri Oct 27 16:50:24 2006 From: seanius at seanius.net (sean finney) Date: Fri, 27 Oct 2006 16:50:24 +0200 Subject: [Nagiosplug-devel] Testcase for is_hostname (was something else) In-Reply-To: References: <4541C5B7.4010209@op5.se> Message-ID: <1161960624.22905.6.camel@localhost> On Fri, 2006-10-27 at 15:01 +0100, Ton Voon wrote: > Andreas, I'm not sure what you would like to see. Is it: > "nonfqdn-but-ends-in-dot." => 0 > "otherwise.something." => 1 i'd say something ending in '.' should be considered a valid hostname no matter what (assume there are no other problems with it). whether or not it *resolves* ought to be an orthogonal issue. or is the test also testing resolvable domains? 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 ton.voon at altinity.com Fri Oct 27 16:59:11 2006 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 27 Oct 2006 15:59:11 +0100 Subject: [Nagiosplug-devel] Testcase for is_hostname (was something else) In-Reply-To: <1161960624.22905.6.camel@localhost> References: <4541C5B7.4010209@op5.se> <1161960624.22905.6.camel@localhost> Message-ID: On 27 Oct 2006, at 15:50, sean finney wrote: > On Fri, 2006-10-27 at 15:01 +0100, Ton Voon wrote: > >> Andreas, I'm not sure what you would like to see. Is it: >> "nonfqdn-but-ends-in-dot." => 0 >> "otherwise.something." => 1 > > i'd say something ending in '.' should be considered a valid > hostname no > matter what (assume there are no other problems with it). whether or > not it *resolves* ought to be an orthogonal issue. Sounds fair. I guess you may want to test the domain "com." or if you implement an internal DNS with your own top level domain (we use "altinity" as our top level). OK, I'll change the test and alter the code to reflect. > or is the test also testing resolvable domains? No - it is purely a textual test. To save for a later time, but there's an argument to not bother doing this type of check at all and have an "unresolveable hostname" caught in exceptions later down in any plugins. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ban.nobuhiro at gmail.com Sun Oct 29 12:10:39 2006 From: ban.nobuhiro at gmail.com (Nobuhiro Ban) Date: Sun, 29 Oct 2006 20:10:39 +0900 Subject: [Nagiosplug-devel] [PATCH] fix SEGV of check_radius Message-ID: Hi all, I got a segfault when I ran check_radius. So I read check_radius.c and found `data' was used uninitialized in main(). After fixing this problem, it looks ok. Here is the patch: --- nagios-plugins-HEAD-200610282352/plugins/check_radius.c.orig 2006-10-20 08:53:28.000000000 +0900 +++ nagios-plugins-HEAD-200610282352/plugins/check_radius.c 2006-10-29 17:30:31.000000000 +0900 @@ -139,6 +139,7 @@ service = PW_AUTHENTICATE_ONLY; + memset (&data, 0, sizeof data); if (!(rc_avpair_add (&data.send_pairs, PW_SERVICE_TYPE, &service, 0) && rc_avpair_add (&data.send_pairs, PW_USER_NAME, username, 0) && rc_avpair_add (&data.send_pairs, PW_USER_PASSWORD, password, 0) && From noreply at sourceforge.net Mon Oct 30 02:35:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Oct 2006 17:35:36 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1586932 ] addition to parse output from check_ssh Message-ID: Patches item #1586932, was opened at 2006-10-29 20:35 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=1586932&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: Brian Pontz (axehind) Assigned to: Nobody/Anonymous (nobody) Summary: addition to parse output from check_ssh Initial Comment: Use check_ssh -s and it will parse the output looking for the string. Example: If you have different ssh versions you check for and you just want to make sure you get a ssh header when you connect to the ssh port /usr/local/nagios/check_ssh -s SSH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1586932&group_id=29880 From Matthew.Martin at qwest.com Fri Oct 27 22:36:02 2006 From: Matthew.Martin at qwest.com (Martin, Matthew) Date: Fri, 27 Oct 2006 15:36:02 -0500 Subject: [Nagiosplug-devel] 2 problems with check_ifstatus Message-ID: Hello, I am using check_ifstatus to monitor the status of several hundred Nokia/Check Point firewalls. There are two issues with check_ifstatus that seem to be errors as far as I can tell: 1) Dormant serial interfaces return status of "OK". A dormant serial connection should be CRITICAL, right? I changed the following line # 189 to address this: if ($ifdown > 0) { becomes: if (($ifdown > 0) || ($ifdormant > 0)) { For example here is the output from a Nokia/Check Point firewalls with eight interfaces: four Ethernet and one each of PPOE, Loop, Tunnel and Serial. The Serial is down and the 4th Ethernet is disabled. It shows 8 up and one dormant. Status Information: OK: host 'xxx.yyy.zzz.www', interfaces up: 8, down: 0, dormant: 1, excluded: 0, unused: 0 Performance Data: up=8,down=0,dormant=1,excluded=0,unused=0 I contend that it should show "up: 6", "dormant: 1", and "unused: 1", and that the returned status should be CRITICAL. Is this a misunderstanding on my part, or a bug? ======================================================================== ======= 2) Administratively down interfaces are not counted. Shouldn't these be added to the "unused" category? ======================================================================== ======= Here is the interesting part of the ifTable for the firewall in question. It has an admin down physical Ethernet, and admin down Logical Ethernet a dormant serial and a dormant T1. Yet check_interfaces shows no unused interfaces and OK status. interfaces.ifNumber.0 = 12 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifIndex.7 = 7 interfaces.ifTable.ifEntry.ifIndex.8 = 8 interfaces.ifTable.ifEntry.ifIndex.9 = 9 interfaces.ifTable.ifEntry.ifIndex.10 = 10 interfaces.ifTable.ifEntry.ifIndex.11 = 11 interfaces.ifTable.ifEntry.ifIndex.12 = 12 interfaces.ifTable.ifEntry.ifDescr.1 = ser-s1p1 DS1 Serial Link Nokia TAXI T1 interfaces.ifTable.ifEntry.ifDescr.2 = pppoe0 Ethernet Layer interfaces.ifTable.ifEntry.ifDescr.3 = eth1 Ethernet Layer Intel EtherExpress Pro 10/100B interfaces.ifTable.ifEntry.ifDescr.4 = eth2 Ethernet Layer Intel EtherExpress Pro 10/100B interfaces.ifTable.ifEntry.ifDescr.5 = eth3 Ethernet Layer Intel EtherExpress Pro 10/100B interfaces.ifTable.ifEntry.ifDescr.6 = eth4 Ethernet Layer Intel EtherExpress Pro 10/100B interfaces.ifTable.ifEntry.ifDescr.7 = ser-s1p1c0 CHDLC IP Layer interfaces.ifTable.ifEntry.ifDescr.8 = loop0c0 Software Loopback Layer interfaces.ifTable.ifEntry.ifDescr.9 = eth1c0 IP Layer interfaces.ifTable.ifEntry.ifDescr.10 = eth2c0 IP Layer interfaces.ifTable.ifEntry.ifDescr.11 = eth3c0 IP Layer interfaces.ifTable.ifEntry.ifDescr.12 = eth4c0 IP Layer interfaces.ifTable.ifEntry.ifType.1 = ds1(18) interfaces.ifTable.ifEntry.ifType.2 = eon(25) interfaces.ifTable.ifEntry.ifType.3 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifType.4 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifType.5 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifType.6 = ethernetCsmacd(6) interfaces.ifTable.ifEntry.ifType.7 = hdlc(118) interfaces.ifTable.ifEntry.ifType.8 = softwareLoopback(24) interfaces.ifTable.ifEntry.ifType.9 = other(1) interfaces.ifTable.ifEntry.ifType.10 = other(1) interfaces.ifTable.ifEntry.ifType.11 = other(1) interfaces.ifTable.ifEntry.ifType.12 = other(1) interfaces.ifTable.ifEntry.ifMtu.1 = 8188 interfaces.ifTable.ifEntry.ifMtu.2 = 1514 interfaces.ifTable.ifEntry.ifMtu.3 = 1514 interfaces.ifTable.ifEntry.ifMtu.4 = 1514 interfaces.ifTable.ifEntry.ifMtu.5 = 1514 interfaces.ifTable.ifEntry.ifMtu.6 = 1514 interfaces.ifTable.ifEntry.ifMtu.7 = 1500 interfaces.ifTable.ifEntry.ifMtu.8 = 63000 interfaces.ifTable.ifEntry.ifMtu.9 = 1500 interfaces.ifTable.ifEntry.ifMtu.10 = 1500 interfaces.ifTable.ifEntry.ifMtu.11 = 1500 interfaces.ifTable.ifEntry.ifMtu.12 = 1518 interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 1544 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 100000 interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 100000 interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 100000 interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 100000 interfaces.ifTable.ifEntry.ifSpeed.7 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.8 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.9 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.10 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.11 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.12 = Gauge: 0 interfaces.ifTable.ifEntry.ifPhysAddress.1 = interfaces.ifTable.ifEntry.ifPhysAddress.2 = interfaces.ifTable.ifEntry.ifPhysAddress.3 = 0:a0:8e:7a:df:4c interfaces.ifTable.ifEntry.ifPhysAddress.4 = 0:a0:8e:7a:df:4d interfaces.ifTable.ifEntry.ifPhysAddress.5 = 0:a0:8e:7a:df:4e interfaces.ifTable.ifEntry.ifPhysAddress.6 = 0:a0:8e:7a:df:4f interfaces.ifTable.ifEntry.ifPhysAddress.7 = interfaces.ifTable.ifEntry.ifPhysAddress.8 = interfaces.ifTable.ifEntry.ifPhysAddress.9 = interfaces.ifTable.ifEntry.ifPhysAddress.10 = interfaces.ifTable.ifEntry.ifPhysAddress.11 = interfaces.ifTable.ifEntry.ifPhysAddress.12 = interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.3 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.4 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.5 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.6 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.7 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.8 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.9 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.10 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.11 = up(1) interfaces.ifTable.ifEntry.ifAdminStatus.12 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.1 = dormant(5) interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.4 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.5 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.6 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.7 = lowerLayerDown(7) interfaces.ifTable.ifEntry.ifOperStatus.8 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.9 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.10 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.11 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.12 = lowerLayerDown(7) Thanks for your help ! ======================================================================== ======= ./check_ifstatus --version check_ifstatus (nagios-plugins 1.4.2) 1.9 Copyright (C) 2000 Christoph Kron Updates 5/2002 Subhendu Ghosh Matthew Martin Internet Security Engineer Qwest Communication Corp. matthew.martin at qwest.com - Internal Use Only - Disclose and Distribute only to Qwest Employees and authorized persons working for Qwest. Disclosure outside of Qwest is prohibited without authorization. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders at fupp.net Mon Oct 30 14:56:36 2006 From: anders at fupp.net (Anders Nordby) Date: Mon, 30 Oct 2006 14:56:36 +0100 Subject: [Nagiosplug-devel] Problems with check_procs and pst3 in Solaris 9 Message-ID: <20061030135636.GA84307@fupp.net> Hi, If I build pst3 straight without anything special, it gives me this error: # ./plugins-root/pst3: /dev/ksyms is not a 32-bit kernel namelist pst3: Failed to open kernel memory: Error 0 To get the pst3 program getting further, I had to compile it as a 64-bit binary (and since I was doing that, I did that to the whole plugin package): # CFLAGS="-g -O2 -m64" STRIP="" ./configure --without-gnu-ld # make But the pst3 program crashes. When I try to run it manually through gdb (a 64-bit version of gdb 6.0), I get: # /root/gdb-6.0/gdb/gdb ./pst3 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) run Starting program: /root/nagios-plugins-HEAD-200610300052/plugins-root/pst3 S UID PPID VSZ RSS %CPU COMMAND ARGS S 0 0 1280 712 0.0 init /etc/init - S 0 1 1816 1096 0.0 sac /usr/lib/saf/sac -t 300 S 25 1 4456 1272 0.0 clientmqueue sendmail: Queue runner at 00:15:00 for /var/spool/clientmqueue Program received signal SIGSEGV, Segmentation fault. 0xffffffff7f400648 in memcpy () from /usr/platform/SUNW,Sun-Fire-V240/lib/sparcv9/libc_psr.so.1 (gdb) bt #0 0xffffffff7f400648 in memcpy () from /usr/platform/SUNW,Sun-Fire-V240/lib/sparcv9/libc_psr.so.1 #1 0xffffffff7f202268 in kvm_getcmd32 () from /usr/lib/64/libkvm.so.1 #2 0xffffffff7f2025a0 in kvm_getcmd () from /usr/lib/64/libkvm.so.1 #3 0x00000001000012bc in GetArgVectors (pid=1058288) at pst3.c:222 (gdb) quit The program is running. Exit anyway? (y or n) y I am using nagios-plugins-1.4.4.tar.gz and nagios-plugins-HEAD-200610300052.tar.gz (the gdb run above is done with the snapshot). This problem does not exist in Solaris 8. Also I suggest someone add hints about using --without-gnu-ld and adding /usr/ccs/bin to PATH in Solaris, as nagios-plugins does not build easily without it. Let me know if anyone can figure out a fix before I do. Just want it fixed. Bye, -- Anders. From noreply at sourceforge.net Tue Oct 31 17:30:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 08:30:56 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1480574 ] check_disk is missing -lm on Solaris (rel. 1.4.3) Message-ID: Bugs item #1480574, was opened at 2006-05-02 19:03 Message generated for change (Comment added) made by aderixon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralph R??ner (ralph_roessner) Assigned to: Ton Voon (tonvoon) Summary: check_disk is missing -lm on Solaris (rel. 1.4.3) Initial Comment: The common.h include defines, on Solaris only, a replacement definition for floorf(), which Solaris (up to and including version 8) does not have. Thus, on Solaris only, all plugins including common.h need a definition of floor() (on Linux that would be necessary only for those plugins that actually use floorf()), i.e. they need to link libm.so . The Makefile.in does not respect that need, and consequently compiling check_disk on Solaris fails. I would expect all other plugins that include common.h to have the same problem, but strangely that appears not to be the case. For my needs it was sufficient to add MATHLIBS to the dependency line for check_disk in the plugins/Makefile.in, and I include a patch that does exactly that. However, this should probably be resolved more generally. Regards, Ralph R??ner ---------------------------------------------------------------------- Comment By: Ade Rixon (aderixon) Date: 2006-10-31 16:30 Message: Logged In: YES user_id=145082 This occurs with 1.4.4 if built with the Sun Studio 11 compiler (SunPro C), but not GCC. It happens for all the binary plugins, including check_disk; the quickest workaround is to manually edit the Makefiles and add -lm to the LIBS. ---------------------------------------------------------------------- Comment By: Ralph R??ner (ralph_roessner) Date: 2006-10-23 16:11 Message: Logged In: YES user_id=1515003 Hi, tried the 200610222352 snapshot. The error persists but has jumped to another plugin. This time, compilation fails for the first plugin to make, check_apt.c, same link error: definition of floor is missing. See, common.h defines (on the Solaris platform) a function floorf(), which is included into all the plugins. Most of the plugins do not use this function. For some, the compiler recognizes this and leaves out the definition. For others (and don't ask me why they are treated differently) the defintion of floorf() remains and triggers the linker to look for floor(). Conclusion: As long as the definition of floor() remains in common.h (line 216), you will need to include a -lm in the link line. I am not a configure master, so i will not provide a patch that does this. I hope someone else will know how to. Regards, Ralph R??ner ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-10-19 20:47 Message: Logged In: YES user_id=664364 Ralph, Can you please try the snapshot at http://nagiosplug.sf.net/snapshot. The check_disk code has been re-written without the use of floorf anymore. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1480574&group_id=29880 From noreply at sourceforge.net Tue Oct 31 17:57:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 08:57:11 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1588031 ] check_swap coredump fix for solaris Message-ID: Patches item #1588031, was opened at 2006-10-31 16:57 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=1588031&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: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap coredump fix for solaris Initial Comment: check_swap in plugins 1.4.4 coredumps on solaris (and other SVR4 hosts) when swapctl returns an unexpected value. This patch provides a tidier exit and also checks for some malloc errors in allocating memory for the vars used. I have not amended the BSD section for the same problems since I have no way of testing if the changes I make are sane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1588031&group_id=29880 From noreply at sourceforge.net Tue Oct 31 18:05:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 09:05:17 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1573638 ] check_swap SEGV's on Solaris Message-ID: Bugs item #1573638, was opened at 2006-10-09 10:21 Message generated for change (Comment added) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573638&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: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) >Summary: check_swap SEGV's on Solaris Initial Comment: $ ./check_swap -w 20% -c 10% swapctl failed: : Bad address Segmentation Fault(coredump) $ uname -a SunOS xxxx 5.10 Generic_118833-18 sun4u sparc SUNW,Sun-Fire-V440 This is from "nagios-plugins-HEAD-200610082352.tar.gz" It seems to compile ok: === if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagios2cl/package/usr/local/nagios2cl/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/sfw//include -I/usr/sfw//include -g -O2 -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo" -c -o check_swap.o check_swap.c; \ then mv -f ".deps/check_swap.Tpo" ".deps/check_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi In file included from check_swap.c:33: common.h:216: warning: static declaration of 'floorf' follows non-static declaration /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/sfw/lib -L. -L/usr/sfw//lib -o check_swap check_swap.o -lm utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a popen.o -lsocket -lssl -lcrypto gcc -g -O2 -o check_swap check_swap.o utils.o popen.o -L/usr/sfw/lib -L/tmp/nagios-plugins-HEAD-200610082352/plugins -L/usr/sfw//lib -lm ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lssl -lcrypto === This appears to be the code at issue ( the SVR4 flag is in effect rather than the BSD one) # ifdef CHECK_SWAP_SWAPCTL_SVR4 /* get the number of active swap devices */ nswaps=swapctl(SC_GETNSWP, NULL); /* initialize swap table + entries */ tbl=(swaptbl_t*)malloc(sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); memset(tbl, 0, sizeof(swaptbl_t)+(sizeof(swapent_t)*nswaps)); tbl->swt_n=nswaps; for(i=0;iswt_ent[i]; ent->ste_path=(char*)malloc(sizeof(char)*MAXPATHLEN); } /* and now, tally 'em up */ swapctl_res=swapctl(SC_LIST, tbl); if(swapctl_res < 0){ perror(_("swapctl failed: ")); result = STATE_WARNING; } ---------------------------------------------------------------------- >Comment By: Duncan Ferguson (duncan_ferguson) Date: 2006-10-31 17:05 Message: Logged In: YES user_id=865292 I have submitted a patch in the tracker for check_swap to fix the coredump on all solaris versions (and other SVR4 hosts) and tidy up the error output a little. However, it still does not work correctly as I keep getting the error "swapctl failed: Bad address". As far as I can tell (with a lot of hacking of the code by commenting out everything possible) if compiled directly using gcc it works, but when using "make" it doesnt, as though something included via common.h, popen.h or utils.h is causing an issue but i have so far been unable to trace the cause. I have also compared the code to an example at http://www.idiom.com/~gford/admin/howto/perf.html#swapctl but there are no disernable differences, leading me to think the issue is outside of this source file. I'll keep hacking incase by luck i find the issue. Duncs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1573638&group_id=29880 From guthrie at counterexample.org Tue Oct 31 21:42:34 2006 From: guthrie at counterexample.org (John T. Guthrie III) Date: Tue, 31 Oct 2006 15:42:34 -0500 (EST) Subject: [Nagiosplug-devel] configure patch for older versions of MySQL Message-ID: <200610312042.k9VKgYvQ004569@euler.counterexample.org> Hello all, I recently tried compiling the nagios-plugins package on a Red Hat 9 box. The version of MySQL on this machine was mysql-3.23.58-1.90.10.legacy. It turns out that the mysql_config program for this version of MySQL does not have a --include flag. I have verified this on a different machine running 3.23.56 as well, so I am guessing that MySQL 3 and older lacked this flag, but I can't prove that. It turns out that this did not prevent configure from completing its run. Rather, some of the sed commands in the configure file contained empty strings, so that the Makefile came out garbled, causing all sorts of fun. I am attaching a patch to the configure.in file that will add in a new flag, --with-mysql-includedir=DIR, to the generated configure script. If mysql_config has a --include flag, then the result of that gets used. If not, then the script looks at the --with-mysql-include flag. If that is not present, or does not seem to exist, then it makes a final desparation attempt using $with_mysql/include/mysql. If that doesn't work, then it gives up and exits. Any comments? John Guthrie guthrie at counterexample.org -------------- next part -------------- *** nagios-plugins-1.4.3/configure.in.orig Thu Sep 21 21:51:49 2006 --- nagios-plugins-1.4.3/configure.in Fri Sep 22 00:14:27 2006 *************** *** 274,280 **** else with_mysql=$MYSQLCONFIG EXTRAS="$EXTRAS check_mysql check_mysql_query" ! MYSQLINCLUDE=`$MYSQLCONFIG --include` MYSQLLIBS=`$MYSQLCONFIG --libs` MYSQLCFLAGS=`$MYSQLCONFIG --cflags` AC_SUBST(MYSQLINCLUDE) --- 274,318 ---- else with_mysql=$MYSQLCONFIG EXTRAS="$EXTRAS check_mysql check_mysql_query" ! dnl Some ancient version of mysql_config don't have a --include option. ! if $MYSQLCONFIG | grep \\--include 2>&1 >/dev/null ; then ! MYSQLINCLUDE=`$MYSQLCONFIG --include` ! else ! AC_ARG_WITH(mysql-includedir, ! ACX_HELP_STRING([--with-mysql-includedir=DIR], ! [Include directory for mysql in case configure has problems locating it. Expects DIR/mysql_version.h to exist.]), ! with_mysql_includedir=$withval, ! with_mysql_includedir=none) ! echo "Apparently you have an old version of mysql_config... It won't" ! echo "tell me where it's include directory is. Checking other locations..." ! if test $with_mysql_includedir != "none" ; then ! echo "Trying $with_mysql_includedir..." ! if test -f $with_mysql_includedir/mysql_version.h ; then ! echo "Found it!" ! MYSQLINCLUDE="-I$with_mysql_includedir" ! else ! echo "Trying $with_mysql/include/mysql as a last resort.." ! if test -f $with_mysql/include/mysql/mysql_version.h ; then ! echo "Found it!" ! MYSQLINCLUDE="-I$with_mysql/include/mysql" ! else ! with_mysql_includedir=none ! fi ! fi ! fi ! if test $with_mysql_includedir = "none" ; then ! echo "It appears that you have a version of MySQL whose mysql_config" ! echo "program won't reveal the location of the MySQL include" ! echo "directory. In addition, the directory that you have specified" ! echo "using the --with-mysql-includedir option either does not exist," ! echo "does not contain the file mysql_version.h, or has been" ! echo "specified incorrectly. Given that I can not find a workable" ! echo "/usr/include/mysql directory either, I am going to quit at this" ! echo "point. You may either try again with a different MySQL include" ! echo "directory or you may proceed without MySQL support." ! exit 1 ! fi ! fi MYSQLLIBS=`$MYSQLCONFIG --libs` MYSQLCFLAGS=`$MYSQLCONFIG --cflags` AC_SUBST(MYSQLINCLUDE)