From Ton.Voon at egg.com Fri Nov 1 09:29:39 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Fri Nov 1 09:29:39 2002 Subject: [Nagiosplug-devel] Swap on Solaris Message-ID: <53104E20A25CD411B556009027E50636064D4E0D@pnnemp02.pn.egg.com> Hi! The check_swap with v1.3Beta1 does not work very well on Solaris. According to this expert (ref http://www.sun.com/sun-on-net/itworld/UIR980701perf.html), you cannot use swap -l to determine the amount of swap available. You should use the swap -s command instead. Here are some patches for v1.3Beta1 for check_swap.c and plugins/configure. I tried to patch configure.in, but was failing miserably with all the automake and autoconf stuff. <> <> Warning: it probably breaks other OSes until someone smarter than me can properly integrated it into configure.in. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. -------------- next part -------------- A non-text attachment was scrubbed... Name: plugins-configure.patch Type: application/octet-stream Size: 1530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_swap.patch Type: application/octet-stream Size: 1825 bytes Desc: not available URL: From kdebisschop at alert.infoplease.com Sun Nov 3 03:43:01 2002 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Sun Nov 3 03:43:01 2002 Subject: [Nagiosplug-devel] test Message-ID: <1036323716.31712.32.camel@miles.debisschop.net> Sorry, please ignore -- Karl From noreply at sourceforge.net Tue Nov 5 10:17:02 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Tue Nov 5 10:17:02 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-633721 ] Bug in Check_nt (nsclient) ??? Message-ID: Bugs item #633721, was opened at 2002-11-05 10:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=633721&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Arjan de Graaff (agraaff) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Check_nt (nsclient) ??? Initial Comment: I have some trouble retriving counters values from the NT4 and W2000 performance monitor. I have found that when you try to retrive a counter which contains a '/' in the name you will get a number back that makes no sense. I tryed to do this with several counters containing forward slashes and found the same problems. Example: ./check_nt -H 10.11.250.10 -v COUNTER - l "\Memory\Page Faults/sec","%.3f" because of the '/' in "Page Faults/sec" something goes wrong with the query. i do get a value back but it is not the same value i see when i look at perfmon in Windows. What is the value i get here and how can i get the value i requested? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=633721&group_id=29880 From noreply at sourceforge.net Wed Nov 6 08:02:04 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Wed Nov 6 08:02:04 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-634393 ] tls support for check_smtp Message-ID: Feature Requests item #634393, was opened at 2002-11-06 13:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=634393&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Bernhard Weisshuhn (bkw) Assigned to: Nobody/Anonymous (nobody) Summary: tls support for check_smtp Initial Comment: It would be really nice to have a feature like check_http's --certificate for check_smtp also. Issue a STARTTLS and analyse the given cert. Any chance to see something like that soon? Or sould I try to roll my own? cheers, bkw ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=634393&group_id=29880 From russell at quadrix.com Wed Nov 6 09:11:02 2002 From: russell at quadrix.com (Russell Scibetti) Date: Wed Nov 6 09:11:02 2002 Subject: [Nagiosplug-devel] Release of Plugins Message-ID: <3DC94D74.2060907@quadrix.com> I was wondering what the status of a new tarball release of the plugins is. I am currently going around trying to update all my nagios instances to the most recent version (for Nagios, 1.0b6), but I am a little stuck with the plugins. I know that there have been a lot of fixes since the 1.3b1 tarball, so I don't want to use plugins with known problems. But people here (including myself) are a little hesitant grabbing the most recent version from CVS. One person said that grabbing from the CVS wouldn't be so bad if we were at least grabbing from a known tag in the CVS. So my question is two-fold. Is there going to be a new beta tarball released soon, given all the recent changes? And could there at least be a CVS tag added at the mort stable versions so that we would be grabbing from a known mark in the CVS tree? Thanks. -Russell Scibetti -- Russell Scibetti Quadrix Solutions, Inc. http://www.quadrix.com (732) 235-2335, ext. 7038 From sghosh at sghosh.org Wed Nov 6 10:24:10 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Nov 6 10:24:10 2002 Subject: [Nagiosplug-devel] Release of Plugins In-Reply-To: <3DC94D74.2060907@quadrix.com> Message-ID: There will be a new tarball release "real soon". Karl has been working hard on some of the autoconf issue and deleting some old crud that is no longer needed. There are a few patches that still need to be applied. If I was to hazard a guess - end of the month might be it. (Although Karl may shoot me :) -sg On Wed, 6 Nov 2002, Russell Scibetti wrote: > I was wondering what the status of a new tarball release of the plugins > is. I am currently going around trying to update all my nagios > instances to the most recent version (for Nagios, 1.0b6), but I am a > little stuck with the plugins. I know that there have been a lot of > fixes since the 1.3b1 tarball, so I don't want to use plugins with known > problems. But people here (including myself) are a little hesitant > grabbing the most recent version from CVS. One person said that > grabbing from the CVS wouldn't be so bad if we were at least grabbing > from a known tag in the CVS. > > So my question is two-fold. Is there going to be a new beta tarball > released soon, given all the recent changes? And could there at least > be a CVS tag added at the mort stable versions so that we would be > grabbing from a known mark in the CVS tree? Thanks. > > -Russell Scibetti > > -- From karl at debisschop.net Thu Nov 7 06:41:14 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 7 06:41:14 2002 Subject: [Nagiosplug-devel] Release of Plugins In-Reply-To: References: Message-ID: <1036678286.1433.22.camel@miles.debisschop.net> On Wed, 2002-11-06 at 13:23, Subhendu Ghosh wrote: > There will be a new tarball release "real soon". Karl has been working > hard on some of the autoconf issue and deleting some old crud that is no > longer needed. > > There are a few patches that still need to be applied. > > If I was to hazard a guess - end of the month might be it. (Although Karl > may shoot me :) That's what's so good about open source development. I have no idea where you live, so I can't shoot you ;-) End on Novemeber sounds pretty reasonable. I'll throw one caveat in there though. I will be moving in that same time frame. So I may lose net access for a few days, and so on. So I'd suggest trying to aim for a release candidate by the 25. Then we can do a release end on Nov, or in the first few days of december. For that to work, however, people will need to test the snapshot tarballs (www.debisschop.net/src/nagios) and give feedback prior to the release candidate. -- Karl From noreply at sourceforge.net Fri Nov 8 08:48:03 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Fri Nov 8 08:48:03 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-635536 ] compilation problem solution for HP-UX! Message-ID: Patches item #635536, was opened at 2002-11-08 16:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=635536&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre ARMENGAUD (armengaud) Assigned to: Nobody/Anonymous (nobody) Summary: compilation problem solution for HP-UX! Initial Comment: Like many people here I had troubles compiling nagios plugins on HP-UX. I wanted to solve it cleanly, so I took the last CVS version and tried to debug it. I found several problems, that I could solve in the "configure.in" file. There was a problem in the snprintf.c : I guess it's a bug in the original file from SAMBA, but I didn't dare touching it (there is a test on if not defined HAVE_C99_SNPRINTF that isn't defined anywhere). I added a test in configure.in for HP-UX to define it, and the "#undef HAVE_C99_SNPRINTF" in the acconfig.h There was also problem in the order of test of functions that made them fail (probably because of snprintf). I solved that by changing test order. I changed also the configuration to make swap_format work, but it's a little dirty because I didn't want to touch the C source, so I made used a shell command to have the good swapinfo format. All seems ok now, and I tested the same configuration files on Linux, and it's working. I join the diff file for this new configuration (files configure.in and acconfig.h) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=635536&group_id=29880 From sghosh at sghosh.org Tue Nov 12 10:46:02 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Nov 12 10:46:02 2002 Subject: [Nagiosplug-devel] Re: nagiosplug- check_snmp In-Reply-To: <20021112090910.A17046@ceres.ca.gov> Message-ID: Thanks Michael. Looks like another change between v4.x and 5.x (Also might look into supporting some IPv6 and TCP options in 5x) As a side note: there was a change in r1.8 (line 326) where the "}else{" clause was dropped. Without out it, I can't seem to get my warning/critical range checking to work. check_num() properly sets iresult but the lack of the "else" clause overrides it. I have a patch - but wanted to confirm before applying it. -subhendu On Tue, 12 Nov 2002, Michael Haro wrote: > I can't find `-p port' documented in net-snmp 5.0.6. man on > snmpcmds and searching for `port' only results in `hostname:port', > no `-p port' option. man on snmpget shows nothing useful. Maybe > older versions of net-snmp have a -p port option or I'm missing something, > but I can't find it. I also tried `snmpget -p 161 -v1 hostname oid' and was > returned the usage screen for snmpget. > > I don't have any snmp devices not running on port 161 so I can't help fully > test if it works, but doing hostname:161 does work for me. > > Michael > > On Mon, Nov 11, 2002 at 10:57:37PM -0500, Karl DeBisschop wrote: > > On Mon, 2002-11-11 at 09:59, Subhendu Ghosh wrote: > > > Hi Karl > > > > > > Just about to merge my changes on check_snmp - quick Q. > > > > > > The cmdline port specification got changed from "-p port" to "host:port" > > > This doesn't seem to be a documented option. > > > > > > Any particular reason for the change? > > > > I got a user patch that suggested it was required for newer net-snmp. I > > tested with ucd and could not break it. But if it is not required for > > net-snmp, probably we should stick wutrh what is documented. > > > > Michael -- was that intentional or accidental? > > > > I suspect the most important thing was that we had options after > > arguments, which is not POSIX compliant, so -p in the right order might > > work, where it did not before because of ordering. > > > > -- > > Karl > -- From Ton.Voon at egg.com Wed Nov 13 08:30:22 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Wed Nov 13 08:30:22 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211081100 for Solaris Message-ID: <53104E20A25CD411B556009027E50636064D4E99@pnnemp02.pn.egg.com> Compile report for nagios-plugins-200211081100 on Solaris. $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 $ uname -a SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 Using Solaris' make command. No automake - using the one in the tarball. $ ./configure $ make all gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c snprintf.c snprintf.c -o snprintf.o gcc: cannot specify -o with -c and multiple compilations *** Error code 1 make: Fatal error: Command failed for target `snprintf.o' Solaris' make doesn't like the Makefile lines: snprintf.o: snprintf.c $(COMPILE) -c $? -o $@ It seems that $? is expanded as "snprintf.c snprintf.c". I fixed it by changing the lines to: snprintf.o: snprintf.c $(COMPILE) -c $(srcdir)/snprintf.c -o $@ This is more consistent with getopt.o and getopt1.o. $ make make: Warning: Too many rules defined for target check_ftp make: Warning: Too many rules defined for target check_imap make: Warning: Too many rules defined for target check_nntp make: Warning: Too many rules defined for target check_pop Maybe just need: check_ftp check_imap check_nntp check_pop: check_tcp ln -sf check_tcp $@ Ton Ton Voon IT Operations - Environments North Wing, Derby Telephone: 01384 26 (4406) mailto: ton.voon at egg.com This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From Mailer-Daemon at lists.sourceforge.net Wed Nov 13 08:30:32 2002 From: Mailer-Daemon at lists.sourceforge.net (Mail Delivery System) Date: Wed Nov 13 08:30:32 2002 Subject: [Nagiosplug-devel] Mail delivery failed: returning message to sender Message-ID: This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: save to /var/spool/exim/rejects/rejectedklezvirus generated by message filter failed to lock mailbox /var/spool/exim/rejects/rejectedklezvirus (lock file): retry timeout exceeded nagiosplug-devel at lists.sourceforge.net This message has been rejected because your message looks like you are infected by the Klez Virus and you are spamming us and wasting our resources as a result and your system is spamming us because you are infected. If you have to use windows, you should at least not use outlook. It is inherently insecure; you are generating lots of wasted bandwidth, as well as support headackes by using it, and you are jeopardizing Please seriously consider using another mail client In the event you were discussing virus signatures, please escape them so as not to trip this filter ------ This is a copy of the message, including all the headers. ------ ------ The body of the message is 156266 characters long; only the first ------ 10240 or so are included here. Return-path: Received: from howno.asysijd.cz ([193.85.146.154] helo=mail.sourceforge.net) by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18Bzr1-0004bN-00 for ; Wed, 13 Nov 2002 07:54:59 -0800 FROM: Martin DATE: st, 13 XI 2002 16:55:01+0000 X-Mailer: EBT Reporter v 2.x TO: nagiosplug-devel at lists.sourceforge.net subject: ASYS IJD Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC1234567890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Message-Id: --====_ABC1234567890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC1234567890DEF_====" --====_ABC1234567890DEF_==== Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,

Product Name: Microsoft Windows 2000
Product Id: 52792-006-2356397-09651

Process List:
Eventlog Protokol ud?lost?
NAV Auto-Protect Slu?ba NAV Auto-Protect
NtLmSsp NT LM Security Support Provider
ProtectedStorage Chr?n?n? ?lo?i?t?
SysmonLog V?strahy a protokolov?n? v?konu
Eventlog Protokol ud?lost?
NAV Auto-Protect Slu?ba NAV Auto-Protect
NtLmSsp NT LM Security Support Provider
ProtectedStorage Chr?n?n? ?lo?i?t?
SysmonLog V?strahy a protokolov?n? v?konu

Thank you. --====_ABC1234567890DEF_====-- --====_ABC1234567890DEF_==== Content-Type: audio/x-wav; Name = "README.EXE" Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBy dW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAADNwnnaiaMXiYmjF4mJoxeJCr8ZiYijF4ng vB6JjaMXiWC8GomIoxeJUmljaImjF4kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAA TAEDAO1eYj0AAAAAAAAAAOAADwELAQYAAIABAABAAAAAAAAAkB0AAAAQAAAAkAEAAABA AAAQAAAAEAAABAAAAAUAIAAEAAAAAAAAAADQAQAAEAAAdrwCAAIAAAAAABAAABAAAAAA EAAAEAAAAAAAABAAAAAAAAAAAAAAACR3AQAoAAAAALABAOwSAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA OAIAACAAAAAAEAAAOAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAwHAB AAAQAAAAgAEAABAAAAAAAAAAAAAAAAAAACAAAOAuZGF0YQAAAPQVAAAAkAEAABAAAACQ AQAAAAAAAAAAAAAAAABAAADALnJzcmMAAAAAIAAAALABAAAgAAAAoAEAAAAAAAAAAAAA AAAAQAAAzBUFkjUQAAAAAAAAAAAAAABNU1ZCVk02MC5ETEwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHuIEGashBBmtuwFZnacD2bKIhBmxMgBZkIgEGZOwgFmYIgQ Zhe5AGZPvABmlEAEZl5yAmYSIRBmN5UPZrTDAGa+mw9m27EFZrbiBWZzzwFmu7sAZulB BGYWsg9mHPEFZq/jBWa7bQ5mwXICZuuUD2b30RBmuiQAZne5AGY4uQBmjCMAZoOVD2YA uQBmg5YPZteVA2b2rABmqdgAZmmFEGbuDA9mpPYFZuMkEGZg7AVmRMEAZgclAGaE0A9m JGgCZpm5AGa4IwBmABMPZvL+AGbnow5m7CQEZlp1AWYfzgFmv7gAZh3qBWa1xwFmt4gQ ZuzlBWYEJABmRIYQZhhnAmbRiRBmcd4QZtDHAWb4yAFmc5wPZkGIEGbY3gFm97AFZpYA AWb5Ng5moscBZuuLEGbT7gVmQ60BZkiCEGZlcAJmxssPZq/XD2Za1QBm0DMEZjBmAmYG mQ9mN5YPZjnxBWbc0QRmUN4QZlceD2YzugBmcCUAZuC5AGbD2wBmK5IBZja1DmZp7gVm jDkOZgnFAGZ2dQFmCrsAZl7JAWZL6xBmUsMAZqR0AWa3lQ9mt5YPZm24AGbRuABmd74B ZuuVD2YmkA9mctsAZo6dBmbqIxBmjZcOZh0iAGac7hBm/qQOZkwoEGYtIhBmMyQEZrvW AGZTJhBmAIkQZg+XDmYDJBBmbfAFZhGyBWbK7AVmEi0OZqO4AGYbCQ9mmVsPZgngD2Y0 hwFmIaUOZhEmAGajIwBmeCMAZgAAAAAmABQAAAAAACa7QADXukAAAAAAAFASQAAwAAAA Xq5AAGWuQAB0rkAAhK5AAK6uQABcr0AAC7BAALywQABrsUAAHLJAAMuyQAB8s0AAK7RA ANy0QACLtUAAnLVAAOG1QAAgtkAAdrZAAFS3QABot0AAdLdAAJO3QAC9t0AA57dAABG4 QAA7uEAAQLhAAF+4QACJuEAAs7hAAN24QAAHuUAAMrlAAFC5QAD7uUAA+7lAAPu5QAAV ukAALbpAAC26QABHukAAX7pAAF+6QAB4ukAAirpAANC6QADQukAAAAAAAAYABAAAAAAA tMBAAGLAQAAGAAQAAAAAAE7FQAAbxUAABgAEAAAAAABry0AAT8tAAAYABAAAAAAAtsxA AKzMQAAMAAgAAAAAAAAAAACpzUAADgAIAAAAAABw0EAANdBAAAYABAAAAAAARNJAADDS QAAlABQAL9xAAAAAAAA33EAAAAAAAKATQAAmAAAA1dJAANzSQADr0kAACdNAABnTQAAl 00AAXtNAAJHTQADg00AA7dNAAPrTQAD600AAT9RAAPjUQAA51UAARtVAAF3VQACT1UAA nNVAAJzVQADD1UAA+dVAADnWQAD41kAAF9hAAILYQADi2EAA4thAAG/ZQACB2UAAjtlA AKXZQAAg2kAAJdpAACXaQACq2kAALNtAACjcQAAAAAAAAQAIAALdQAAHAAgA0uFAABfi QADZ4UAABgAEAAAAAACz5UAAc+VAAAYABAAAAAAA/OZAAOnmQAAWABAAAAAAADPpQAAX 6UAAkBRAAAAAAAABAAAAAQAAAOroQAAAAAAABgAEAAAAAABh7EAAN+xAACYAFAAAAAAA GP1AAJ78QAAAAAAAyBRAAFIAAADu7EAAAe1AAB3tQAA57UAASO1AAF/tQAD97UAAAu5A AALuQAAc7kAAKe5AADjuQABL7kAA6e5AAPjuQAD97kAA/e5AAAzvQAAm70AAQ+9AAFTv QABh70AAdu9AAIrvQACi70AAuO9AALjvQAAE8EAAEfBAACDwQAAl8EAAJfBAAJ/yQAA3 80AAOfNAADvzQAA780AAR/NAAITzQACS80AAqvNAAMDzQADA80AADfRAABr0QAAn9EAA LPRAACz0QABX9UAAafVAAG71QABb90AA8/dAAPX3QAD390AA9/dAAAP4QACE+EAARPlA ALH5QAAY+kAAGPpAAHT6QADH+kAAXPtAAHf7QAD5+0AA+ftAABj8QAA2/EAAOPxAAFb8 QABW/EAAVvxAAFb8QABW/EAAVvxAAH78QACD/EAAg/xAAIj8QACX/EAAAAAAAAIABAAA AAAAa/5AAAAAAAAuABQAAAAAAKIeQQBdHkEAAAAAAEAWQABAAAAA3v5AAAv/QAAa/0AA bw5BAI4OQQCcDkEAqg5BALgOQQDFDkEA2g5BABEPQQBOD0EAYw9BAIIPQQCjD0EAuA9B APQPQQA4EEEARRBBAJMQQQDhEEEALxFBAEURQQBmEUEAhhFBAJsRQQCbEUEA7hFBAKAS QQA8E0EA7hNBAJMUQQBFFUEAlBVBAEYWQQBSFkEAeRZBAM4WQQAkF0EALRdBAFUXQQCp F0EAWxhBAPgYQQCqGUEARxpBAPkaQQAaG0EAHxtBAHMbQQAlHEEAwhxBAHQdQQCVHUEA lR1BAJUdQQCvHUEA0B1BAPAdQQDwHUEABR5BABweQQAvHkEAVh5BAAAAAAACAAQAAAAA AAklQQAAAAAADgAIAAAAAAA3J0EAAydBAA4ACAAAAAAAITFBAN8wQQAGAAQAAAAAAKw6 QQBvOkEABAAEAAAAAAAAAAAAPj1BAA4ACAAAAAAAJkFBAPlAQQAOAAgAAAAAAJJDQQBr Q0EABgAEAAAAAADwREEA5kRBAA4ACAAAAAAA7UVBANRFQQAeABAAAAAAAKpIQQB+SEEA 8BdAAAAAAAABAAAAAQAAAF5IQQAAAAAABgAEAAAAAAASSkEACEpBAAIABAAAAAAAN01B AAAAAAAOAAgAAAAAALJOQQCPTkEACAAEAAAAAAAAAAAAO09BAAwACAAAAAAAAAAAAAlQ QQAGAAQAAAAAABpSQQD9UUEADgAIAAAAAABpVEEAPVRBAAAAAAAAADBAAAAAAABAUEAO AAgAAAAAALBXQQB8V0EADgAIAAAAAADNWEEAolhBAAwACAAAAAAAAAAAANViQQAmABQA AAAAACtwQQB0b0EAAAAAAMgYQABHAAAAHmVBAD1lQQBKZUEAWWVBAHJlQQCFZUEAhWVB AEZmQQBzZkEAm2ZBAKBmQQCgZkEAzmZBANxmQQDhZkEA4WZBAPlmQQAHZ0EAHmdBAB5n QQAjZ0EAI2dBAD5nQQBVZ0EAWmdBAFpnQQBnZ0EAjWdBAN1nQQA6aEEAlmhBALVoQQC6 aEEAumhBAAFpQQAiaUEAQWlBAEZpQQBGaUEAjWlBAK5pQQDNaUEA0mlBANJpQQAbakEA PGpBAFtqQQBgakEAYGpBAIJqQQCjakEAwmpBAMdqQQDHakEAHW1BAD5tQQAJbkEAeG5B AJluQQC4bkEAum5BALpuQQDcbkEA/W5BABxvQQAeb0EAHm9BACtvQQArb0EAQm9BAGpv QQAAAAAAAAAAAAYABAAAAAAA6XFBAMlxQQAGAAQAAAAAAFVzQQA4c0EAAwAIAG10QQBy dEEAAAAAAAEACAAwdUEAAQAIAAt2QQAHAAgA23ZBAOx2QQDidkEA/yXAEEAA/yU8EUAA /yVkEUAA/yWEEEAA/yVsEEAA/yWoEUAA/yU4EEAA/yXAEUAA/yWMEEAA/yW8EUAA/yWs EUAA/yVYEUAA/yUQEUAA/yVUEUAA/yVAEEAA/yUMEEAA/yUIEkAA/yUIEEAA/yUoEkAA /yWEEUAA/yWsEEAA/yUwEUAA/yUcEkAA/yUYEkAA/yX8EEAA/yW8EEAA/yW4EEAA/yUo EEAA/yVQEUAA/yVgEEAA/yUEEkAA/yVIEEAA/yXUEEAA/yUEEEAA/yWIEUAA/yV0EEAA /yWgEEAA/yXgEUAA/yUkEkAA/yXcEUAA/yUwEkAA/yVoEEAA/yXEEUAA/yWAEEAA/yW0 EUAA/yVQEEAA/yXgEEAA/yU0EEAA/yVcEUAA/yVsEUAA/yUAEEAA/yXUEUAA/yUAEkAA /yVMEUAA/yXoEUAA/yUYEEAA/yXIEEAA/yUkEEAA/yVEEEAA/yVcEEAA/yUcEUAA/yUs EkAA/yXQEEAA/yUQEkAA/yWwEUAA/yUYEUAA/yV8EEAA/yWUEEAA/yUUEUAA/yUkEUAA /yV8EUAA/yUgEkAA/yWgEUAA/yXsEEAA/yUUEkAA/yVkEEAA/yUgEEAA/yWMEUAA/yVo EUAA/yUUEEAA/yU4EUAA/yXoEEAA/yXEEEAA/yW4EUAA/yV0EUAA/yXcEEAA/yXQEUAA /yX8EUAA/yX0EUAA/yWcEEAA/yVIEUAA/yX4EEAA/yX4EUAA/yV4EEAA/yWkEUAA/yUc EEAA/yWcEUAA/yUQEEAA/yWYEUAA/yWoEEAA/yUAEUAA/yXYEUAA/yXkEEAA/yUsEUAA /yXwEUAA/yW0EEAA/yWUEUAA/yX0EEAA/yWQEUAA/yWQEEAA/yV4EUAA/yXYEEAA/yWY EEAA/yUwEEAA/yVgEUAA/yXwEEAA/yWIEEAA/yVYEEAA/yWkEEAA/yUEEUAA/yUsEEAA /yUMEUAA/yXsEUAA/yVMEEAA/yXMEUAA/yVwEUAA/yXkEUAA/yVAEUAA/yVwEEAA/yUM EkAA/yVEEUAA/yWAEUAA/yWwEEAA/yUIEUAA/yU8EEAA/yUoEUAA/yVUEEAA/yU0EUAA /yXMEEAA/yUgEUAA/yXIEUAAAABo4C1AAOju////AABAAAAAMAAAADgAAAAAAAAAgZhg Dha01hGP5gAA4m2ihwAAAAAAAAEAAAAuY3RsAABCcmlkZQB1AQAAdAEAAAAAAAAAAIgA AAAAAAAAAgAAAAMAAACDmGAOFrTWEY/mAADibaKHAQAAAJgAAACoAAAAAQAAAAAAAAAB IEEAuGQAAKBkQQAAAAAAVXNlckNvbnRyb2wxAGdBAIKYYA4WtNYRj+YAAOJtooeEmGAO FrTWEY/mAADibaKH/8wxAAJpmGAOFrTWEY/mAADibaKHaphgDha01hGP5gAA4m2ihzpP rTOZZs8RtwwAqgBg05MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAy DwAAhg4AAAAFAEZvcm0xAA0BBQBCcmlkZQAZAQBCACIAIz4OAABsdAAANg4AAAAAAQAC ABAQAAAAAAAAaAUAACYAAAAgIAAAAAAAAKgIAACOBQAAKAAAABAAAAAgAAAAAQAIAAAA AABAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAIAAgAAAAICAAAAAgAAAAICAAAAAgADA wMAAwNzAAPDKpgCAgIAA/wD/AP8AAAD//wAAAP8AAAD//wAAAP8A////APD7/wCkoKAA +Pj4AMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADMZjMAmWZm AMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzM mQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwAMwD/AGYAQkJCAP8AmQDM MwAA/zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA /5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9m AP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaW lgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEABAQEAAgICAAMDAwAERERABYWFgAc HBwAIiIiACkpKQBVVVUATU1NADk5OQCAfP8AUFD/AJMA1gD/7MwAxtbvANbn5wCQqa0A AAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wAADP/AABmAAAAZjMAAGZm AABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADMAAAAzDMAAMxmAADM mQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwAMwD/ADMzAAAz MzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAzmTMA M5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+Z ADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBm zAAAZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kA mQCZAJkAzACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/ AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/ MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwBoaBkZGWhoaGhoaGhoaGhoaBnnaGgYbOIZ 6OfnaGhoaF4ZaGhsbBno6B5BQefnaGhdGWjD4xnoQR5BQUFBQedoXR8YAhnoQR5oaBlB QUFB513QH+PoHkFoaGhoGUFBQede0UEZ6EEeaGhoaGhoaGhoXvbRH+hBHh4eHh4eHh4e Hmhe9kIfQUFBQSUlRkZGRh5oGdD3QUEeaGhoaBlbTEYeaGjj7v1BHh5oaBklVFseaGho GePuBx4eGRkeTFtGHmhoaGgZHiYtHh4lRiVGHmhBaGhoaB4eQUFBQSVGHmhoQWhoaGho aB4eHh4eHmhoaB5oaGhoaGhoaGhoaB4eHh5ox/8AAJgP//8wAwAAIAH//wDAAAAB4P// Af8AAAAA//+AAAAAgeD//8DBAADAAf//4AIAAPAG///8DgAA/+GUASgAAAAgAAAAQAAA AAEACAAAAAAAgAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgACAAIAAAACAgAAAAIAAAACA gAAAAIAAwMDAAMDcwADwyqYAgICAAP8A/wD/AAAA//8AAAD/AAAA//8AAAD/AP///wDw +/8ApKCgAPj4+ADMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwz AMzMZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAEJC QgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8zzAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADM Zv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wAAP/MMwD/zGYA/8yZAP/MzAD/zP8A //8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A//9mACEApQBfX18Ad3d3 AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAAQEBAAICAgADAwMABER EQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW 5+cAkKmtAAAAMwAAAGYAAACZAAAAzAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAAZgAA AGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkzAACZZgAAmZkAAJnMAACZ/wAAzAAAAMwz AADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAAMwAzADMAZgAzAJkAMwDMADMA /wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAzZpkAM2bMADNm/wAz mQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM/wAz/zMA M/9mADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNm AGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZ zABmmf8AZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZ mQAAmTOZAJkAmQCZAMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkA mWbMAJkz/wCZmTMAmZlmAJmZmQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/ AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf//AMwAAACZADMAaGhoaMLCwsLC4mhoaGhoaGho aGhoaGhoaGhoaGhoaGhoaMIZGefn5+fn4uJoaGhoaGhoaGhoaGhoaGhoaGhoaGhdGR/n aGhoaGjn56BvbMIC4hkZaGhoaGhoaGhoaGhoaF0f52hoaGhoaGhsbOLiOufn5+fn5+do aGhoaGhoaGhoXUHnaGhoaGhsbOIYOucf6OceHh5BQefnaGhoaGhoaF1dQedoaGhsbOLj 6Bno5+ceHkFBQUFBQUHn52hoaGhocV1BQedobxjiGecZ5x4eQUFBQUFBQUFBQUFB52ho aGhxXUFB53IYAuPoGegeHkFBHh4eQUFBQUFBQUFB52hoaHFdQUHnvALi5xnnHkFBQefn 5+fnQUFBQUFBQUEe52hoXV0gQR4YAuMZ6B4eQUEeaGhoaGgZ50FBQSRHJEHnaGhdcHBB Qefi4+fnHkFBHmhoaGhoaGgZ50ElRiQlRh7naF5wcEBB5+PoGR4eQR5oaGhoaGhoaGgZ H0FBQUFBQedoXnBdIEFB5+PnHkFBHmhoaGhoaGhoaGhoaGhoaGhoaGhoX From metz at studenten.net Wed Nov 13 09:48:06 2002 From: metz at studenten.net (Joachim Metz) Date: Wed Nov 13 09:48:06 2002 Subject: [Nagiosplug-devel] The scaling of the timing within the check_http plugin Message-ID: <1037209660.1653.23.camel@scotch> Dear reader (nagios plugin developer), I was experimenting with Nagios and the plugins and was a bit disappointed about the scale of the response timing of the check_http plugins (What the plugin return on its status line.), namely seconds. I was expecting milli seconds. Has this a certain reason ? I have not looked at the timing of other plugins, but I was wondered if this might change in future versions of the plugins, from seconds to milli seconds ? If have made some changes to the check_http.c file I had, and provided for a scale of milli seconds. I only have adjusted the output, not the thresholds (perhaps a nice additional change). It works under SuSE Linux. I do not know if it is cross platform. And I have only tested the seperate plugin. Perhaps it is a useful feature for future version of the plugins ? Because I do not know if I am using the latest version of the source (did not fetched it from CVS), therefore I send to you the entire adjusted check_http.c file. You are free to use the changes as you like. ------------------------------------------------------------------------ Brief overview of the changes: added #include changed time_t start_time, end_time; to struct timeb start_time_m, end_time_m; but left in for compile issues: time_t start_time, end_time; added in check_http (void), but should probably be a long int time_delta = 0; changed several status printing rules, one of which time_delta = ((end_time_m.time * 1000) + end_time_m.millitm) - ((start_time_m.time * 1000) + start_time_m.millitm); msg = ssprintf (msg, ": %s - %d ms response time %s%s\n", status_line, time_delta, timestamp, (display_html ? "" : "")); ------------------------------------------------------------------------ Regards, Joachim Metz -------------- next part -------------- A non-text attachment was scrubbed... Name: check_http.ms.c.gz Type: application/x-gzip Size: 8500 bytes Desc: not available URL: From lilesb at ijet.com Wed Nov 13 11:00:06 2002 From: lilesb at ijet.com (Bryan Liles) Date: Wed Nov 13 11:00:06 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211081100 for Solaris In-Reply-To: <53104E20A25CD411B556009027E50636064D4E99@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4E99@pnnemp02.pn.egg.com> Message-ID: <20021113140020.31e5877b.lilesb@ijet.com> don't use solaris make. its bad. use gnu make if at all possible. On Wed, 13 Nov 2002 15:54:56 -0000 "Voon, Ton" wrote: > Compile report for nagios-plugins-200211081100 on Solaris. > > $ gcc -v > Reading specs from > /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version > 2.8.1$ uname -a > SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 > > Using Solaris' make command. No automake - using the one in the > tarball. > > $ ./configure > $ make all > gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c > snprintf.c snprintf.c -o snprintf.o > gcc: cannot specify -o with -c and multiple compilations > *** Error code 1 > make: Fatal error: Command failed for target `snprintf.o' > > Solaris' make doesn't like the Makefile lines: > snprintf.o: snprintf.c > $(COMPILE) -c $? -o $@ > > It seems that $? is expanded as "snprintf.c snprintf.c". I fixed it by > changing the lines to: > snprintf.o: snprintf.c > $(COMPILE) -c $(srcdir)/snprintf.c -o $@ > > This is more consistent with getopt.o and getopt1.o. > > $ make > make: Warning: Too many rules defined for target check_ftp > make: Warning: Too many rules defined for target check_imap > make: Warning: Too many rules defined for target check_nntp > make: Warning: Too many rules defined for target check_pop > > Maybe just need: > check_ftp check_imap check_nntp check_pop: check_tcp > ln -sf check_tcp $@ > > Ton > > Ton Voon > IT Operations - Environments > North Wing, Derby > Telephone: 01384 26 (4406) > mailto: ton.voon at egg.com > > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse > Square, 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel From karl at debisschop.net Wed Nov 13 18:20:01 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Nov 13 18:20:01 2002 Subject: [Nagiosplug-devel] The scaling of the timing within the check_http plugin In-Reply-To: <1037209660.1653.23.camel@scotch> References: <1037209660.1653.23.camel@scotch> Message-ID: <1037240286.20135.1.camel@toaster> On Wed, 2002-11-13 at 12:47, Joachim Metz wrote: > Dear reader (nagios plugin developer), > > I was experimenting with Nagios and the plugins and was a bit > disappointed about the scale of the response timing of the check_http > plugins (What the plugin return on its status line.), namely seconds. I > was expecting milli seconds. Has this a certain reason ? CVS reports milliseconds, and accepts millisecond thresholds. There are twice-daily snapshots that include these changes. -- Karl DeBisschop From karl at debisschop.net Wed Nov 13 21:29:03 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Nov 13 21:29:03 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211081100 for Solaris In-Reply-To: <53104E20A25CD411B556009027E50636064D4E99@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4E99@pnnemp02.pn.egg.com> Message-ID: <1037251686.20405.19.camel@toaster> On Wed, 2002-11-13 at 10:54, Voon, Ton wrote: > Compile report for nagios-plugins-200211081100 on Solaris. > > $ gcc -v > Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs > gcc version 2.8.1 > $ uname -a > SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 > > Using Solaris' make command. No automake - using the one in the tarball. > > $ ./configure > $ make all > gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c > snprintf.c snprintf.c -o snprintf.o > gcc: cannot specify -o with -c and multiple compilations > *** Error code 1 > make: Fatal error: Command failed for target `snprintf.o' > > Solaris' make doesn't like the Makefile lines: > snprintf.o: snprintf.c > $(COMPILE) -c $? -o $@ > patch applied. Thanks. > It seems that $? is expanded as "snprintf.c snprintf.c". I fixed it by > changing the lines to: > snprintf.o: snprintf.c > $(COMPILE) -c $(srcdir)/snprintf.c -o $@ > > This is more consistent with getopt.o and getopt1.o. > > $ make > make: Warning: Too many rules defined for target check_ftp > make: Warning: Too many rules defined for target check_imap > make: Warning: Too many rules defined for target check_nntp > make: Warning: Too many rules defined for target check_pop > > Maybe just need: > check_ftp check_imap check_nntp check_pop: check_tcp > ln -sf check_tcp $@ > Applied. Help, but still not perfect. Thanks again. > Ton > > Ton Voon > IT Operations - Environments > North Wing, Derby > Telephone: 01384 26 (4406) > mailto: ton.voon at egg.com > > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel -- Karl DeBisschop From Ton.Voon at egg.com Thu Nov 14 01:51:02 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Thu Nov 14 01:51:02 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211081100 for Solaris Message-ID: <53104E20A25CD411B556009027E50636064D4E9D@pnnemp02.pn.egg.com> I agree Solaris make looks bad, but it is so close to working... > -----Original Message----- > From: Bryan Liles [SMTP:lilesb at ijet.com] > Sent: Wednesday, November 13, 2002 7:00 PM > To: Voon, Ton > Cc: nagiosplug-devel at lists.sourceforge.net > Subject: Re: [Nagiosplug-devel] Report on nagios-plugins-200211081100 > for Solaris > > don't use solaris make. its bad. use gnu make if at all possible. > > On Wed, 13 Nov 2002 15:54:56 -0000 > "Voon, Ton" wrote: > > > Compile report for nagios-plugins-200211081100 on Solaris. > > > > $ gcc -v > > Reading specs from > > /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version > > 2.8.1$ uname -a > > SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 > > > > Using Solaris' make command. No automake - using the one in the > > tarball. > > > > $ ./configure > > $ make all > > gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c > > snprintf.c snprintf.c -o snprintf.o > > gcc: cannot specify -o with -c and multiple compilations > > *** Error code 1 > > make: Fatal error: Command failed for target `snprintf.o' > > > > Solaris' make doesn't like the Makefile lines: > > snprintf.o: snprintf.c > > $(COMPILE) -c $? -o $@ > > > > It seems that $? is expanded as "snprintf.c snprintf.c". I fixed it by > > changing the lines to: > > snprintf.o: snprintf.c > > $(COMPILE) -c $(srcdir)/snprintf.c -o $@ > > > > This is more consistent with getopt.o and getopt1.o. > > > > $ make > > make: Warning: Too many rules defined for target check_ftp > > make: Warning: Too many rules defined for target check_imap > > make: Warning: Too many rules defined for target check_nntp > > make: Warning: Too many rules defined for target check_pop > > > > Maybe just need: > > check_ftp check_imap check_nntp check_pop: check_tcp > > ln -sf check_tcp $@ > > > > Ton > > > > Ton Voon > > IT Operations - Environments > > North Wing, Derby > > Telephone: 01384 26 (4406) > > mailto: ton.voon at egg.com > > > > > > > > This private and confidential e-mail has been sent to you by Egg. > > The Egg group of companies includes Egg Banking plc > > (registered no. 2999842), Egg Financial Products Ltd (registered > > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > > carries out investment business on behalf of Egg and is regulated > > by the Financial Services Authority. > > Registered in England and Wales. Registered offices: 1 Waterhouse > > Square, 138-142 Holborn, London EC1N 2NA. > > If you are not the intended recipient of this e-mail and have > > received it in error, please notify the sender by replying with > > 'received in error' as the subject and then delete it from your > > mailbox. > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Are you worried about > > your web server security? Click here for a FREE Thawte > > Apache SSL Guide and answer your Apache SSL security > > needs: http://www.gothawte.com/rd523.html > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel From noreply at sourceforge.net Thu Nov 14 04:43:01 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Thu Nov 14 04:43:01 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-638257 ] check_nagios typo Message-ID: Patches item #638257, was opened at 2002-11-14 08:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638257&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gyula Szabo (gyufi) Assigned to: Nobody/Anonymous (nobody) Summary: check_nagios typo Initial Comment: check_nagios --help presents a typo in the Example. It prints -H instead -F. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638257&group_id=29880 From kdebisschop at mail.debisschop.net Thu Nov 14 12:18:15 2002 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Thu Nov 14 12:18:15 2002 Subject: [Nagiosplug-devel] Re: Report on nagios-plugins-200211081100 for Solaris In-Reply-To: <53104E20A25CD411B556009027E50636064D4E9D@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4E9D@pnnemp02.pn.egg.com> Message-ID: Voon, Ton writes: > I agree Solaris make looks bad, but it is so close to working... > >> -----Original Message----- >> From: Bryan Liles [SMTP:lilesb at ijet.com] >> Sent: Wednesday, November 13, 2002 7:00 PM >> To: Voon, Ton >> Cc: nagiosplug-devel at lists.sourceforge.net >> Subject: Re: [Nagiosplug-devel] Report on nagios-plugins-200211081100 >> for Solaris >> >> don't use solaris make. its bad. use gnu make if at all possible. automake SHOULD create makefiles that work without requiring GNU make. I do hope to reach that goal. So I appreciate the bug report. That being said, I'm really not sure I'll get non-GNU makes to work well before the 1.3.0 release. I don't really view it a such a priority that it should slow the test and release cycle any more. Just fair warning. -- Karl From kdebisschop at mail.debisschop.net Thu Nov 14 12:25:06 2002 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Thu Nov 14 12:25:06 2002 Subject: [Nagiosplug-devel] Re: nagiosplug- check_snmp In-Reply-To: References: Message-ID: Subhendu Ghosh writes: > Thanks Michael. > > Looks like another change between v4.x and 5.x > (Also might look into supporting some IPv6 and TCP options in 5x) > > As a side note: there was a change in r1.8 (line 326) where the "}else{" > clause was dropped. > > Without out it, I can't seem to get my warning/critical range checking to > work. check_num() properly sets iresult but the lack of the "else" clause > overrides it. > > I have a patch - but wanted to confirm before applying it. > > -subhendu Is it possibly a typo on my part? I don't see a reply from Michael yet, but I do notice that check_snmp in the latest snapshot seems to be in warning state when it shiould not be (at least for my deployment). Is that the same issue? From michael.haro at ceres.ca.gov Thu Nov 14 12:35:03 2002 From: michael.haro at ceres.ca.gov (Michael Haro) Date: Thu Nov 14 12:35:03 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: Message-ID: <000b01c28c1d$37e044e0$240110ac@DARKSTAR> What are you waiting on me for? I haven't had time to fully test the check_snmp plugin this week yet :-/ Also, is check_snmp supposed to support both net-snmp 4.x and 5.x or just 5.x? Michael -----Original Message----- From: Karl DeBisschop [mailto:kdebisschop at h00a0cc3b7988.ne.client2.attbi.com] Sent: Thursday, November 14, 2002 12:24 PM To: Subhendu Ghosh Cc: Michael Haro; NagiosPlug Devel Subject: Re: nagiosplug- check_snmp Subhendu Ghosh writes: > Thanks Michael. > > Looks like another change between v4.x and 5.x > (Also might look into supporting some IPv6 and TCP options in 5x) > > As a side note: there was a change in r1.8 (line 326) where the "}else{" > clause was dropped. > > Without out it, I can't seem to get my warning/critical range checking to > work. check_num() properly sets iresult but the lack of the "else" clause > overrides it. > > I have a patch - but wanted to confirm before applying it. > > -subhendu Is it possibly a typo on my part? I don't see a reply from Michael yet, but I do notice that check_snmp in the latest snapshot seems to be in warning state when it shiould not be (at least for my deployment). Is that the same issue? From sghosh at sghosh.org Thu Nov 14 13:14:03 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Nov 14 13:14:03 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <000b01c28c1d$37e044e0$240110ac@DARKSTAR> Message-ID: Yes - warning state when it shouldn't be. - dropping the " }else{ " clause back in seems to fix it. check_snmp - should be supporting both 4.x and 5.x - most of my testing is 4.x I'll pop the "else" clause back in tonight - and perhaps Jim can create another solaris tarball. -sg On Thu, 14 Nov 2002, Michael Haro wrote: > What are you waiting on me for? I haven't had time to fully test the > check_snmp plugin this week yet :-/ > > Also, is check_snmp supposed to support both net-snmp 4.x and 5.x or just > 5.x? > > Michael > > Subhendu Ghosh writes: > > > Thanks Michael. > > > > Looks like another change between v4.x and 5.x > > (Also might look into supporting some IPv6 and TCP options in 5x) > > > > As a side note: there was a change in r1.8 (line 326) where the "}else{" > > clause was dropped. > > > > Without out it, I can't seem to get my warning/critical range checking to > > work. check_num() properly sets iresult but the lack of the "else" clause > > overrides it. > > > > I have a patch - but wanted to confirm before applying it. > > > > -subhendu > > Is it possibly a typo on my part? > > I don't see a reply from Michael yet, but I do notice that check_snmp in the > latest snapshot seems to be in warning state when it shiould not be (at > least for my deployment). Is that the same issue? > -- From noreply at sourceforge.net Thu Nov 14 13:15:03 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Thu Nov 14 13:15:03 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-638656 ] Fix for check_mrtgtraf Message-ID: Patches item #638656, was opened at 2002-11-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638656&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Dlug (pdlug) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for check_mrtgtraf Initial Comment: check_mrtgtraf does not return error and success codes correctly. Also fixed if {} branching logic for testing the state to return unknown state if nothing else matches (otherwise the possibility of returning multiple status codes exists). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638656&group_id=29880 From michael.haro at ceres.ca.gov Thu Nov 14 13:49:01 2002 From: michael.haro at ceres.ca.gov (Michael Haro) Date: Thu Nov 14 13:49:01 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: Message-ID: <000c01c28c27$8128e7b0$240110ac@DARKSTAR> did my snmp port fix for 5.x break 4.x? -----Original Message----- From: Subhendu Ghosh [mailto:sghosh at sghosh.org] Sent: Thursday, November 14, 2002 1:14 PM To: Michael Haro Cc: 'Karl DeBisschop'; 'NagiosPlug Devel' Subject: RE: nagiosplug- check_snmp Yes - warning state when it shouldn't be. - dropping the " }else{ " clause back in seems to fix it. check_snmp - should be supporting both 4.x and 5.x - most of my testing is 4.x I'll pop the "else" clause back in tonight - and perhaps Jim can create another solaris tarball. -sg On Thu, 14 Nov 2002, Michael Haro wrote: > What are you waiting on me for? I haven't had time to fully test the > check_snmp plugin this week yet :-/ > > Also, is check_snmp supposed to support both net-snmp 4.x and 5.x or just > 5.x? > > Michael > > Subhendu Ghosh writes: > > > Thanks Michael. > > > > Looks like another change between v4.x and 5.x > > (Also might look into supporting some IPv6 and TCP options in 5x) > > > > As a side note: there was a change in r1.8 (line 326) where the "}else{" > > clause was dropped. > > > > Without out it, I can't seem to get my warning/critical range checking to > > work. check_num() properly sets iresult but the lack of the "else" clause > > overrides it. > > > > I have a patch - but wanted to confirm before applying it. > > > > -subhendu > > Is it possibly a typo on my part? > > I don't see a reply from Michael yet, but I do notice that check_snmp in the > latest snapshot seems to be in warning state when it shiould not be (at > least for my deployment). Is that the same issue? > -- From sghosh at sghosh.org Thu Nov 14 14:05:04 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Nov 14 14:05:04 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <000c01c28c27$8128e7b0$240110ac@DARKSTAR> Message-ID: No - the host:port notation works as an undocumented feature in 4.x :) -sg On Thu, 14 Nov 2002, Michael Haro wrote: > did my snmp port fix for 5.x break 4.x? > > -----Original Message----- > From: Subhendu Ghosh [mailto:sghosh at sghosh.org] > Sent: Thursday, November 14, 2002 1:14 PM > To: Michael Haro > Cc: 'Karl DeBisschop'; 'NagiosPlug Devel' > Subject: RE: nagiosplug- check_snmp > > > > Yes - warning state when it shouldn't be. - dropping the " }else{ " > clause back in seems to fix it. > > check_snmp - should be supporting both 4.x and 5.x - most of my testing > is 4.x > > I'll pop the "else" clause back in tonight - and perhaps Jim can create > another solaris tarball. > > -sg > > > On Thu, 14 Nov 2002, Michael Haro wrote: > > > What are you waiting on me for? I haven't had time to fully test the > > check_snmp plugin this week yet :-/ > > > > Also, is check_snmp supposed to support both net-snmp 4.x and 5.x or just > > 5.x? > > > > Michael > > > > Subhendu Ghosh writes: > > > > > Thanks Michael. > > > > > > Looks like another change between v4.x and 5.x > > > (Also might look into supporting some IPv6 and TCP options in 5x) > > > > > > As a side note: there was a change in r1.8 (line 326) where the "}else{" > > > clause was dropped. > > > > > > Without out it, I can't seem to get my warning/critical range checking > to > > > work. check_num() properly sets iresult but the lack of the "else" > clause > > > overrides it. > > > > > > I have a patch - but wanted to confirm before applying it. > > > > > > -subhendu > > > > Is it possibly a typo on my part? > > > > I don't see a reply from Michael yet, but I do notice that check_snmp in > the > > latest snapshot seems to be in warning state when it shiould not be (at > > least for my deployment). Is that the same issue? > > > > -- > > > -- From tonvoon at mac.com Thu Nov 14 16:06:03 2002 From: tonvoon at mac.com (Ton Voon) Date: Thu Nov 14 16:06:03 2002 Subject: [Nagiosplug-devel] makefile.am patch for check_tcp programs Message-ID: Karl, I've been looking through the automake manual and I think this is a clean way of getting check_ftp, check_imap and the other check_tcp derivative programs to be added to the makefile for make all, install and uninstall. The patch is below. This was tested on MacOSX, but I'm hoping to try it out on a Solaris server tomorrow - if you have a new a snapshot ready! Ton *** Makefile.am.200211131100 Thu Nov 14 22:36:54 2002 --- Makefile.am Thu Nov 14 23:44:04 2002 *************** *** 8,14 **** check_mrtg check_mrtgtraf check_nwstat check_overcr check_ping \ check_procs check_real check_smtp check_ssh check_tcp check_time \ check_udp check_ups check_users check_vsz negate urlize \ - check_ftp check_imap check_nntp check_pop \ @EXTRAS@ EXTRA_PROGRAMS = check_mysql check_radius check_pgsql check_snmp check_hpjd \ --- 8,13 ---- *************** *** 20,25 **** --- 19,26 ---- PLUGINHDRS = common.h config.h + check_tcp_programs = check_ftp check_imap check_nntp check_pop + BASEOBJS = utils.o NETOBJS = netutils.o $(BASEOBJS) NETLIBS = $(NETOBJS) $(SOCKETLIBS) *************** *** 36,46 **** ######################################################################## ###### # the actual targets - check_ftp_SOURCES = check_tcp.c - check_imap_SOURCES = check_tcp.c - check_nntp_SOURCES = check_tcp.c - check_pop_SOURCES = check_tcp.c - check_dig_LDADD = $(BASEOBJS) popen.o check_disk_LDADD = $(BASEOBJS) popen.o check_dns_LDADD = $(BASEOBJS) popen.o --- 37,42 ---- *************** *** 75,84 **** check_by_ssh_LDADD = $(BASEOBJS) popen.o negate_LDADD = $(BASEOBJS) popen.o urlize_LDADD = $(BASEOBJS) popen.o - check_ftp_LDADD = $(NETLIBS) $(SSLLIBS) - check_imap_LDADD = $(NETLIBS) $(SSLLIBS) - check_nntp_LDADD = $(NETLIBS) $(SSLLIBS) - check_pop_LDADD = $(NETLIBS) $(SSLLIBS) check_dig_DEPENDENCIES = check_dig.c $(BASEOBJS) popen.o $(DEPLIBS) check_disk_DEPENDENCIES = check_disk.c $(BASEOBJS) popen.o $(DEPLIBS) --- 71,76 ---- *************** *** 114,123 **** check_by_ssh_DEPENDENCIES = check_by_ssh.c $(BASEOBJS) popen.o $(DEPLIBS) negate_DEPENDENCIES = negate.c $(BASEOBJS) popen.o $(DEPLIBS) urlize_DEPENDENCIES = urlize.c $(BASEOBJS) popen.o $(DEPLIBS) - check_ftp_DEPENDENCIES = check_tcp.c $(NETOBJS) $(DEPLIBS) - check_imap_DEPENDENCIES = check_tcp.c $(NETOBJS) $(DEPLIBS) - check_nntp_DEPENDENCIES = check_tcp.c $(NETOBJS) $(DEPLIBS) - check_pop_DEPENDENCIES = check_tcp.c $(NETOBJS) $(DEPLIBS) ######################################################################## ###### # secondary dependencies --- 106,111 ---- *************** *** 135,141 **** $(COMPILE) -c $(srcdir)/getopt1.c -o $@ snprintf.o: snprintf.c ! $(COMPILE) @NEED_VA_LIST@ -c $? -o $@ libgetopt.a: getopt.o getopt1.o $(AR) -r $@ getopt.o getopt1.o --- 123,129 ---- $(COMPILE) -c $(srcdir)/getopt1.c -o $@ snprintf.o: snprintf.c ! $(COMPILE) @NEED_VA_LIST@ -c $(srcdir)/snprintf.c -o $@ libgetopt.a: getopt.o getopt1.o $(AR) -r $@ getopt.o getopt1.o *************** *** 143,147 **** libsnprintf.a: snprintf.o $(AR) -r $@ snprintf.o ! check_ftp check_imap check_nntp check_pop: ln -sf check_tcp $@ --- 131,148 ---- libsnprintf.a: snprintf.o $(AR) -r $@ snprintf.o ! all-local: $(check_tcp_programs) ! ! $(check_tcp_programs): check_tcp ln -sf check_tcp $@ + + install-exec-hook: + for i in $(check_tcp_programs) ; do \ + ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ + done + + clean-local: + rm -f $(check_tcp_programs) + + uninstall-local: + cd $(DESTDIR)$(libexecdir) && rm -f $(check_tcp_programs) From sghosh at sghosh.org Thu Nov 14 20:50:14 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Nov 14 20:50:14 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <1037321172.17978.4.camel@toaster> Message-ID: On 14 Nov 2002, Karl DeBisschop wrote: > On Thu, 2002-11-14 at 16:13, Subhendu Ghosh wrote: > > Yes - warning state when it shouldn't be. - dropping the " }else{ " > > clause back in seems to fix it. > > > > check_snmp - should be supporting both 4.x and 5.x - most of my testing > > is 4.x > > > > I'll pop the "else" clause back in tonight > > I'm about to drop in a patch that includes this, plud better handling of > units for multiple checks. > > Just give my patch a once over, > > I'm changing line 310 to: > > } else if (eval_method[i] & WARN_PRESENT) { > > But you refered to line 326, so I'm not 100% sure we're talking about > the exact same solution, though the problem seems the same. > > line 310 - (above) I don't see anything different from the current CVS. Essentially I have a question about whether the whole if/else if statement covering lines 308-312 make any sense since the CRIT_PRESENT/WARN_PRESENT flags are not (and will not be set until after the output has been evaluated. The eval does start till line 314. Also the flags should get set in the check_num() routine when iresult is modified - but currently don't - so the flags are superflous at the moment. My ref to line 326 was in v1.8 - current CVS line 358-360 - should be concatanated with an "else" clause instead of being separate if statements. -- -sg From sghosh at sghosh.org Thu Nov 14 21:13:05 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Nov 14 21:13:05 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <1037321172.17978.4.camel@toaster> Message-ID: Another issue in check_snmp - process_arguments() case 's' and case 'r' eval_method[jj++] can go out of bounds. Since we are only supporting one string match or regex match - and always for the last provided OID, should not increment jj. How jj is determined is an issue since there are a couple of pathways through the switch statement depending on the order of the arguments on the command line. So long as -s and -r are specifed immediately after -o, we are ok. If we get -w, or -c between -o and -s/-r : we will have out of bounds. -- -sg From karl at debisschop.net Thu Nov 14 22:53:11 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 14 22:53:11 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <000b01c28c1d$37e044e0$240110ac@DARKSTAR> References: <000b01c28c1d$37e044e0$240110ac@DARKSTAR> Message-ID: <1037321223.18000.6.camel@toaster> On Thu, 2002-11-14 at 15:34, Michael Haro wrote: > What are you waiting on me for? Sounds like we're not really waiting on you. Just waiting to get our heads at the same place. -- Karl DeBisschop From karl at debisschop.net Thu Nov 14 22:56:09 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 14 22:56:09 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: References: Message-ID: <1037321172.17978.4.camel@toaster> On Thu, 2002-11-14 at 16:13, Subhendu Ghosh wrote: > Yes - warning state when it shouldn't be. - dropping the " }else{ " > clause back in seems to fix it. > > check_snmp - should be supporting both 4.x and 5.x - most of my testing > is 4.x > > I'll pop the "else" clause back in tonight I'm about to drop in a patch that includes this, plud better handling of units for multiple checks. Just give my patch a once over, I'm changing line 310 to: } else if (eval_method[i] & WARN_PRESENT) { But you refered to line 326, so I'm not 100% sure we're talking about the exact same solution, though the problem seems the same. -- Karl DeBisschop From p.miquet at hafiba.fr Fri Nov 15 01:20:03 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Fri Nov 15 01:20:03 2002 Subject: [Nagiosplug-devel] flexlm plugin Message-ID: <1037351932.5148.60.camel@moishe> Hello, I've tried the flexlm plugin with some errors. The version I've tested is check_flexlm (nagios-plugins 1.3.0-alpha1) 1.4 On running the command ./check_flexlm /symlnks/flexlm/licenses/license.dat I've got the following errors: Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 1. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 1. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 1. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 2. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 2. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 2. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 3. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 3. Use of uninitialized value in concatenation (.) or string at ./check_flexlm line 88, line 3. moishe UP, license server for dalims: UP v6.1 And as far as I'm not a perl expert, I didn't understand the errors. here is the result of the command : /symlnks/flexlm/bin/lmstat -c /symlnks/flexlm/licenses/license.dat Flexible License Manager status on Fri 11/15/2002 10:15 License server status: 6666 at moishe License file(s) on moishe: /symlnks/flexlm/licenses/license.dat: moishe: license server UP (MASTER) v6.1 Vendor daemon status (on moishe): dalims: UP v6.1 Is this error due to different version of the lmstat, or due to the implementation of the perl code itself ? Any idea is welcome. Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.miquet at hafiba.fr Fri Nov 15 01:22:05 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Fri Nov 15 01:22:05 2002 Subject: [Nagiosplug-devel] flexlm options Message-ID: <1037352093.5148.64.camel@moishe> How some new feature could be added to this plugin ? I'd like to add a feature telling us if the license will expire within 30 days for example, and then launch an alert. I know there will be so many way to checks this, but I'd like to get a good implementation. Regards Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.miquet at hafiba.fr Fri Nov 15 01:30:03 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Fri Nov 15 01:30:03 2002 Subject: [Nagiosplug-devel] Usage of the check_local_procs Message-ID: <1037352547.5148.73.camel@moishe> Hello, I've first tried to test the Nagios with some default example, before starting the TRUE life... I've discovered that into the service.cfg, using the check_local_procs as only two arguments 150 and 200. But checking into the checkcommands.cfg the check_procs is waiting for a third argument, which is the state of processes. Then I've added another argument to be able to run this service. Regards. Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.miquet at hafiba.fr Fri Nov 15 01:35:02 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Fri Nov 15 01:35:02 2002 Subject: [Nagiosplug-devel] INSTALL file Message-ID: <1037352840.5263.80.camel@moishe> It seems that a mistake is made into the INSTALL file. We're told of a default CGIURl d) Replace CGIURL with the path used to access the Nagios CGIs with a web browser (default is '/cgi-bin/nagios') BUT should be /nagios/cgi-bin ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at debisschop.net Fri Nov 15 04:04:01 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 15 04:04:01 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: References: Message-ID: <1037361672.32350.421.camel@toaster> On Thu, 2002-11-14 at 23:48, Subhendu Ghosh wrote: > On 14 Nov 2002, Karl DeBisschop wrote: > > > On Thu, 2002-11-14 at 16:13, Subhendu Ghosh wrote: > > > Yes - warning state when it shouldn't be. - dropping the " }else{ " > > > clause back in seems to fix it. > > > > > > check_snmp - should be supporting both 4.x and 5.x - most of my testing > > > is 4.x > > > > > > I'll pop the "else" clause back in tonight > > > > I'm about to drop in a patch that includes this, plud better handling of > > units for multiple checks. > > > > Just give my patch a once over, > > > > I'm changing line 310 to: > > > > } else if (eval_method[i] & WARN_PRESENT) { > > > > But you refered to line 326, so I'm not 100% sure we're talking about > > the exact same solution, though the problem seems the same. > > > > > > line 310 - (above) I don't see anything different from the current CVS. > Essentially I have a question about whether the whole if/else if statement > covering lines 308-312 make any sense since the CRIT_PRESENT/WARN_PRESENT > flags are not (and will not be set until after the output has been > evaluated. The eval does start till line 314. Well, it sort of does. If an oid is present, the while loop runs for each OID that is returned. So just reaching that line correctly triggers (WARN|CRIT)_PRESENT, at least as far as my read goes. Probably all the other tests are superfluous, at least on CRIT_PRESENT -- but you need to run them so the output line is fully informative. However, there is a different problem. When you submit 2 oids, and one is not present in the returns the one that is there. It does return 2 to the shell, so the error is indicated, but we miss it somewhere. Plus, the diagnosis of which oid is missing need standard error, which we don't parse. And taht parsing is not straightforward because the oid is not always returned in the same format as it was sent. [kdebisschop at toaster nagiosplug]$ snmpget -c staff localhost .1.3.6.1.4.1.2021.9.1.9.111 .1.3.6.1.4.1.2021.9.1.9.1 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: UCD-SNMP-MIB::dskPercent.1 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. Failed object: UCD-SNMP-MIB::dskPercent.111 In other words, the code comments are dead on to mark it experimental. We should also make sure it is so marked if it appears in the docs. > Also the flags should get set in the check_num() routine when iresult is > modified - but currently don't - so the flags are superflous at the > moment. I'm not following you here. Can you explain this to me again? > My ref to line 326 was in v1.8 - current CVS line 358-360 - should be > concatanated with an "else" clause instead of being separate if > statements. -- Karl DeBisschop From karl at debisschop.net Fri Nov 15 04:21:00 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 15 04:21:00 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: References: Message-ID: <1037362686.32351.438.camel@toaster> On Fri, 2002-11-15 at 00:12, Subhendu Ghosh wrote: > Another issue in check_snmp - process_arguments() > > case 's' and case 'r' > > eval_method[jj++] can go out of bounds. > > Since we are only supporting one string match or regex match - and > always for the last provided OID, should not increment jj. ISTM it would be nice to not require that it be the last OID. Actually, I'd like to be able to check more than one string, but that can wait. So what it really needs is just a check against MAX_OID (or we need to change that structure and realloc eval_method). In general, I support removing precomiled limits. > How jj is determined is an issue since there are a couple of pathways > through the switch statement depending on the order of the arguments on > the command line. Yes there are several paths. In my thinking, there are sort of three forks -- jj gets incremented by either 1) a string test (-s, -r, -R) 2) an existence test (-e, -E, when they really work) 3) an integer test (-w and -c) But the last is unique in that you need to allow both WARN and CRIT specifications. Overall, there's alot of work that can be done to clean up that processing. For the release, unless there are serious objections, maybe we don't need to commit to making it truly bullet proof. As long as it's possible to specify what the docs say you can, I suggest deferring a major rewrite for 1.3.1 But a rewrite is probably waranted. > So long as -s and -r are specifed immediately after -o, we are ok. If we > get -w, or -c between -o and -s/-r : we will have out of bounds. Can't we just add a check against MAX_OID? -- Karl DeBisschop From gthomas at telemarket.fr Fri Nov 15 05:44:02 2002 From: gthomas at telemarket.fr (Gilles THOMAS) Date: Fri Nov 15 05:44:02 2002 Subject: [Nagiosplug-devel] process plugin Message-ID: <058f01c28cac$e80f3710$760511ac@tm> hi, First, excuse me for my english... I made a plugin in perl, because I need to know if a particular process is present if you are interresting with that I give you the code, I'm not a perl expert so excuse me for the quality of the code, and the return is in french, so sorry but you may translate : #!/usr/bin/perl # You need CPAN module "Proc-ProcessTable-0.37" from Dan Urist. # You can found this module at http://www.cpan.org. # # This script allow you to see if a process is present. # You may/can use this script with nrpe use Proc::ProcessTable; use Getopt::Long; &Getopt::Long::config('auto_abbrev'); # Evaluation des param?tres pass?s ? la commande my $status = GetOptions( "process=s",\$process, ); usage() if ($status == 0 || ! ($process)); $i = 0; $ref = new Proc::ProcessTable; foreach $proc (@{$ref->table}) { if(@ARGV) { next unless grep {$_ == $proc->{pid}} @ARGV; } if ($proc->{fname} =~ m/$process/i){ $i++; printf "$proc->{cmndline} \n"; }; } if ($i > 0) { printf "Il y a $i process '$process' \n"; exit(0); }; printf ("Il n'y a pas de process '$process' en cours ! \n"); exit(2); sub usage() { printf "\n check_process.pl Plugin for Nagios \n"; printf " Nagios : www.nagios.org \n"; printf "\n Missing argument ! \n"; printf "\n Ex : ./test_ps.pl -p nagios \n"; printf "'nagios' is the name of the process \n\n"; printf "it may be 'ping', 'smbd' or 'httpd', etc... \n\n"; printf "-p : the name of the process you want to monitor \n\n"; printf "\nCopyright (C) 2002 Gilles THOMAS 'tom\@persofrance.dyndns.org' \n"; printf "check_process.pl comes with ABSOLUTELY NO WARRANTY \n"; printf "This programm is licensed under the terms of the "; printf "GNU General Public License\n(check source code for details) \n"; printf "\n\n"; exit(3); } From sghosh at sghosh.org Fri Nov 15 08:15:04 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 08:15:04 2002 Subject: [Nagiosplug-devel] process plugin In-Reply-To: <058f01c28cac$e80f3710$760511ac@tm> Message-ID: Merci - How does this compare to the existing check_procs plugins? (Other than output language) -sg On Fri, 15 Nov 2002, Gilles THOMAS wrote: > hi, > > First, excuse me for my english... > > I made a plugin in perl, because I need to know if a particular process is > present if you are interresting with that I give you the code, I'm not a > perl expert so excuse me for the quality of the code, and the return is in > french, so sorry but you may translate : > > > #!/usr/bin/perl > > # You need CPAN module "Proc-ProcessTable-0.37" from Dan Urist. > # You can found this module at http://www.cpan.org. > # > # This script allow you to see if a process is present. > # You may/can use this script with nrpe > > use Proc::ProcessTable; > use Getopt::Long; > &Getopt::Long::config('auto_abbrev'); > > # Evaluation des param?tres pass?s ? la commande > my $status = GetOptions( > "process=s",\$process, > ); > > usage() if ($status == 0 || ! ($process)); > > > $i = 0; > > $ref = new Proc::ProcessTable; > > foreach $proc (@{$ref->table}) { > if(@ARGV) { > next unless grep {$_ == $proc->{pid}} @ARGV; > } > > if ($proc->{fname} =~ m/$process/i){ > > $i++; > printf "$proc->{cmndline} \n"; > }; > > } > > if ($i > 0) { > printf "Il y a $i process '$process' \n"; > exit(0); > }; > > printf ("Il n'y a pas de process '$process' en cours ! \n"); > exit(2); > > sub usage() > { > > printf "\n check_process.pl Plugin for Nagios \n"; > printf " Nagios : www.nagios.org \n"; > printf "\n Missing argument ! \n"; > printf "\n Ex : ./test_ps.pl -p nagios \n"; > printf "'nagios' is the name of the process \n\n"; > printf "it may be 'ping', 'smbd' or 'httpd', etc... \n\n"; > printf "-p : the name of the process you want to monitor \n\n"; > printf "\nCopyright (C) 2002 Gilles THOMAS 'tom\@persofrance.dyndns.org' > \n"; > printf "check_process.pl comes with ABSOLUTELY NO WARRANTY \n"; > printf "This programm is licensed under the terms of the "; > printf "GNU General Public License\n(check source code for details) \n"; > printf "\n\n"; > > exit(3); > > } > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > -- From sghosh at sghosh.org Fri Nov 15 09:06:02 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 09:06:02 2002 Subject: [Nagiosplug-devel] INSTALL file In-Reply-To: <1037352840.5263.80.camel@moishe> Message-ID: fixed in CVS CGIURL as well On 15 Nov 2002, Pascal Miquet wrote: > It seems that a mistake is made into the INSTALL file. > > We're told of a default CGIURl > > d) Replace CGIURL with the path used to access the Nagios CGIs with > a web browser (default is '/cgi-bin/nagios') > > > BUT should be /nagios/cgi-bin ? > Regards > > > -- From karl at debisschop.net Fri Nov 15 09:38:02 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 15 09:38:02 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <1037362686.32351.438.camel@toaster> References: <1037362686.32351.438.camel@toaster> Message-ID: <1037381759.1161.9.camel@miles.debisschop.net> I should also have said, if you have a patch that you tink corrects these things (or some of them), maybe you should go ahead and apply it. We can always back it out if we need to, but I suspect having you code fixes someplace where we can all see them will just make it faster to get to the point where we're ready to include it in the release. On Fri, 2002-11-15 at 07:18, Karl DeBisschop wrote: > On Fri, 2002-11-15 at 00:12, Subhendu Ghosh wrote: > > Another issue in check_snmp - process_arguments() > > > > case 's' and case 'r' > > > > eval_method[jj++] can go out of bounds. > > > > Since we are only supporting one string match or regex match - and > > always for the last provided OID, should not increment jj. > > ISTM it would be nice to not require that it be the last OID. Actually, > I'd like to be able to check more than one string, but that can wait. > > So what it really needs is just a check against MAX_OID (or we need to > change that structure and realloc eval_method). In general, I support > removing precomiled limits. > > > How jj is determined is an issue since there are a couple of pathways > > through the switch statement depending on the order of the arguments on > > the command line. > > Yes there are several paths. In my thinking, there are sort of three > forks -- jj gets incremented by either > > 1) a string test (-s, -r, -R) > 2) an existence test (-e, -E, when they really work) > 3) an integer test (-w and -c) > > But the last is unique in that you need to allow both WARN and CRIT > specifications. > > Overall, there's alot of work that can be done to clean up that > processing. For the release, unless there are serious objections, maybe > we don't need to commit to making it truly bullet proof. As long as it's > possible to specify what the docs say you can, I suggest deferring a > major rewrite for 1.3.1 > > But a rewrite is probably waranted. > > > So long as -s and -r are specifed immediately after -o, we are ok. If we > > get -w, or -c between -o and -s/-r : we will have out of bounds. > > Can't we just add a check against MAX_OID? -- Karl DeBisschop From sghosh at sghosh.org Fri Nov 15 09:40:05 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 09:40:05 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: <1037361672.32350.421.camel@toaster> Message-ID: On 15 Nov 2002, Karl DeBisschop wrote: > > line 310 - (above) I don't see anything different from the current CVS. > > Essentially I have a question about whether the whole if/else if statement > > covering lines 308-312 make any sense since the CRIT_PRESENT/WARN_PRESENT > > flags are not (and will not be set until after the output has been > > evaluated. The eval does start till line 314. > > Well, it sort of does. If an oid is present, the while loop runs for > each OID that is returned. So just reaching that line correctly triggers > (WARN|CRIT)_PRESENT, at least as far as my read goes. Probably all the > other tests are superfluous, at least on CRIT_PRESENT -- but you need to > run them so the output line is fully informative. > if (WARN|CRIT)_PRESENT - then yes - should possibly skip the rest of the checks, but in this case we are checking for the flag to be present in the for the iteration of the OID in the while loop - not the previous loops. That could be achieved by looking at iresult before setting it to STATE_DEPENDENT. > However, there is a different problem. When you submit 2 oids, and one > is not present in the returns the one that is there. -yes this would force the rewrite. :( > > It does return 2 to the shell, so the error is indicated, but we miss it > somewhere. Plus, the diagnosis of which oid is missing need standard > error, which we don't parse. And taht parsing is not straightforward > because the oid is not always returned in the same format as it was > sent. > > [kdebisschop at toaster nagiosplug]$ snmpget -c staff localhost > .1.3.6.1.4.1.2021.9.1.9.111 .1.3.6.1.4.1.2021.9.1.9.1 > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > Failed object: UCD-SNMP-MIB::dskPercent.1 > > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > Failed object: UCD-SNMP-MIB::dskPercent.111 this raises the quistion whether the plugin should put in an -O flag to the command so we know the output format, and could possibly using snmptranslate to map the input to the error OID > > In other words, the code comments are dead on to mark it experimental. > We should also make sure it is so marked if it appears in the docs. > > > Also the flags should get set in the check_num() routine when iresult is > > modified - but currently don't - so the flags are superflous at the > > moment. (WARN|CRIT)_PRESENT flags are never set anywhere - they are just checked - hence my comment about the superflous if/else statement above. check_num should set these flags in addition to setting the result. > > I'm not following you here. Can you explain this to me again? > > > My ref to line 326 was in v1.8 - current CVS line 358-360 - should be > > concatanated with an "else" clause instead of being separate if > > statements. > the basic login checking the output in the while loop if ( WARN|CRIT comparion flags set) else if ( STRING comparision flag set) else if (REGEX comparison flag set) else ( no comparision flags set) currently the trailing else clause is not present (but the contents of the clause are present as a separate statement over-riding the logic) I'll put the changes into CVS. -sg -- From kdebisschop at alert.infoplease.com Fri Nov 15 09:41:10 2002 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri Nov 15 09:41:10 2002 Subject: [Nagiosplug-devel] Time for beta2 release? Message-ID: <1037382039.1149.15.camel@miles.debisschop.net> We talked about this earlier, and I said I wanted to finish removeing call_getopt. That's done (as is replacing ssprintf with asprintf) I know we still have some build problems that can be worked on, and some other bugs, but I am now thinking we are getting toward time to tag CVS and release something more lasting than a snapshot. I have put beta2 into CVS as a release name, but have not tagged CVS. I won't until people agree we are ready to do so. -- Karl DeBisschop From karl at debisschop.net Fri Nov 15 10:06:02 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 15 10:06:02 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: References: Message-ID: <1037383454.1149.21.camel@miles.debisschop.net> On Fri, 2002-11-15 at 12:39, Subhendu Ghosh wrote: > > In other words, the code comments are dead on to mark it experimental. > > We should also make sure it is so marked if it appears in the docs. > > > > > Also the flags should get set in the check_num() routine when iresult is > > > modified - but currently don't - so the flags are superflous at the > > > moment. > > (WARN|CRIT)_PRESENT flags are never set anywhere - they are just checked - > hence my comment about the superflous if/else statement above. check_num > should set these flags in addition to setting the result. > That's incorrect: line 449 of 1.18 > > > > > I'm not following you here. Can you explain this to me again? > > > > > My ref to line 326 was in v1.8 - current CVS line 358-360 - should be > > > concatanated with an "else" clause instead of being separate if > > > statements. > > > > the basic login checking the output in the while loop > > if (WARN|CRIT comparion flags set) no. if (PRESENT) else? if (INTEGER comparison) > > else if ( STRING comparision flag set) > > else if (REGEX comparison flag set) > > else ( no comparision flags set) > > > currently the trailing else clause is not present (but the contents of the > clause are present as a separate statement over-riding the logic) but maybe your logic is better, even if it is not what is currently there. > > I'll put the changes into CVS. -- Karl DeBisschop From rob.king at wholefoods.com Fri Nov 15 13:25:01 2002 From: rob.king at wholefoods.com (Rob King) Date: Fri Nov 15 13:25:01 2002 Subject: [Nagiosplug-devel] check_iftable - Submission Message-ID: <3DD565E7.5000906@wholefoods.com> Hey everyone, I've written a Nagios plugin (in very ugly Bourne shell code) that uses the SNMPv2 TABLE command to poll all the interfaces on a router/machine, and give output like "Interfaces: 653 up, 32 down, 1 admin down, 1 disconnected". It seems to work fine, as we're using it to monitor approx. 200 routers. The benefit to this is that it checks all the interfaces using one SNMP operation for everything, as opposed to one SNMP operation per interface. Please let me know if this would be the appropriate location for me to submit it to have it included in the Nagios plugin distribution. Like I said, it's pretty ugly, but I'd love it if someone cleaned it up and included it. Thanks, Rob From sghosh at sghosh.org Fri Nov 15 13:53:03 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 13:53:03 2002 Subject: [Nagiosplug-devel] check_iftable - Submission In-Reply-To: <3DD565E7.5000906@wholefoods.com> Message-ID: Post it to the list. How different is this from check_ifstatus ? FYI - there is no table command in snmpv2 - but an implementation of getbulk recursion for the snmptable cmdline app in the net-snmp distribution. -sg On Fri, 15 Nov 2002, Rob King wrote: > Hey everyone, > I've written a Nagios plugin (in very ugly Bourne shell code) that > uses the SNMPv2 TABLE command to poll all the interfaces on a > router/machine, and give output like "Interfaces: 653 up, 32 down, 1 > admin down, 1 disconnected". It seems to work fine, as we're using it to > monitor approx. 200 routers. The benefit to this is that it checks all > the interfaces using one SNMP operation for everything, as opposed to > one SNMP operation per interface. > > Please let me know if this would be the appropriate location for me > to submit it to have it included in the Nagios plugin distribution. Like > I said, it's pretty ugly, but I'd love it if someone cleaned it up and > included it. > > Thanks, > Rob > -- From rob.king at wholefoods.com Fri Nov 15 14:07:02 2002 From: rob.king at wholefoods.com (Rob King) Date: Fri Nov 15 14:07:02 2002 Subject: [Nagiosplug-devel] check_iftable - Submission In-Reply-To: References: Message-ID: <3DD56FB2.3090407@wholefoods.com> Hey Subhendu, *grins* Now that I've looked at the check_ifstatus, I don't really see much of a difference. Sorry, when I grabbed the help message for check_ifstatus and I saw that it had a option, I thought that it was used for checking specific ports. So, that's my bad. Duplication of labor, all my fault. Thanks for the pointer, though. Rob Subhendu Ghosh wrote: >Post it to the list. > >How different is this from check_ifstatus ? > >FYI - there is no table command in snmpv2 - but an implementation of >getbulk recursion for the snmptable cmdline app in the net-snmp >distribution. > >-sg > >On Fri, 15 Nov 2002, Rob King wrote: > > > >>Hey everyone, >> I've written a Nagios plugin (in very ugly Bourne shell code) that >>uses the SNMPv2 TABLE command to poll all the interfaces on a >>router/machine, and give output like "Interfaces: 653 up, 32 down, 1 >>admin down, 1 disconnected". It seems to work fine, as we're using it to >>monitor approx. 200 routers. The benefit to this is that it checks all >>the interfaces using one SNMP operation for everything, as opposed to >>one SNMP operation per interface. >> >> Please let me know if this would be the appropriate location for me >>to submit it to have it included in the Nagios plugin distribution. Like >>I said, it's pretty ugly, but I'd love it if someone cleaned it up and >>included it. >> >> Thanks, >> Rob >> >> >> > > > From rob.king at wholefoods.com Fri Nov 15 14:36:02 2002 From: rob.king at wholefoods.com (Rob King) Date: Fri Nov 15 14:36:02 2002 Subject: [Nagiosplug-devel] check_iftable - Submission In-Reply-To: References: <3DD56FB2.3090407@wholefoods.com> Message-ID: <3DD57692.2010506@wholefoods.com> Hey everyone, Ah-ha! I did find a difference. Now I remember why I did it this way. My script also checks the ifConnectorPresent attribute, and doesn't send out an alert if a connector is not present. This prevents it from sending out an error on "virtual" interfaces that are usually down, like dial-out ports. Sorry, that's the difference. :) Thanks, Rob Rob King wrote: > Hey Subhendu, > *grins* Now that I've looked at the check_ifstatus, I don't really > see much of a difference. Sorry, when I grabbed the help message for > check_ifstatus and I saw that it had a option, I thought that > it was used for checking specific ports. > > So, that's my bad. Duplication of labor, all my fault. > > Thanks for the pointer, though. > > Rob > > Subhendu Ghosh wrote: > >> Post it to the list. >> >> How different is this from check_ifstatus ? >> >> FYI - there is no table command in snmpv2 - but an implementation of >> getbulk recursion for the snmptable cmdline app in the net-snmp >> distribution. >> >> -sg >> >> On Fri, 15 Nov 2002, Rob King wrote: >> >> >> >>> Hey everyone, >>> I've written a Nagios plugin (in very ugly Bourne shell code) >>> that uses the SNMPv2 TABLE command to poll all the interfaces on a >>> router/machine, and give output like "Interfaces: 653 up, 32 down, 1 >>> admin down, 1 disconnected". It seems to work fine, as we're using >>> it to monitor approx. 200 routers. The benefit to this is that it >>> checks all the interfaces using one SNMP operation for everything, >>> as opposed to one SNMP operation per interface. >>> >>> Please let me know if this would be the appropriate location for >>> me to submit it to have it included in the Nagios plugin >>> distribution. Like I said, it's pretty ugly, but I'd love it if >>> someone cleaned it up and included it. >>> >>> Thanks, >>> Rob >>> >>> >> >> >> >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > From sghosh at sghosh.org Fri Nov 15 14:39:02 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 14:39:02 2002 Subject: [Nagiosplug-devel] check_iftable - Submission In-Reply-To: <3DD57692.2010506@wholefoods.com> Message-ID: Of course a patch would be nice ;) On Fri, 15 Nov 2002, Rob King wrote: > Hey everyone, > Ah-ha! I did find a difference. Now I remember why I did it this > way. My script also checks the ifConnectorPresent attribute, and doesn't > send out an alert if a connector is not present. This prevents it from > sending out an error on "virtual" interfaces that are usually down, like > dial-out ports. > > Sorry, that's the difference. :) > > Thanks, > Rob > > > Rob King wrote: > > > Hey Subhendu, > > *grins* Now that I've looked at the check_ifstatus, I don't really > > see much of a difference. Sorry, when I grabbed the help message for > > check_ifstatus and I saw that it had a option, I thought that > > it was used for checking specific ports. > > > > So, that's my bad. Duplication of labor, all my fault. > > > > Thanks for the pointer, though. > > > > Rob > > > > Subhendu Ghosh wrote: > > > >> Post it to the list. > >> > >> How different is this from check_ifstatus ? > >> > >> FYI - there is no table command in snmpv2 - but an implementation of > >> getbulk recursion for the snmptable cmdline app in the net-snmp > >> distribution. > >> > >> -sg > >> > >> On Fri, 15 Nov 2002, Rob King wrote: > >> > >> > >> > >>> Hey everyone, > >>> I've written a Nagios plugin (in very ugly Bourne shell code) > >>> that uses the SNMPv2 TABLE command to poll all the interfaces on a > >>> router/machine, and give output like "Interfaces: 653 up, 32 down, 1 > >>> admin down, 1 disconnected". It seems to work fine, as we're using > >>> it to monitor approx. 200 routers. The benefit to this is that it > >>> checks all the interfaces using one SNMP operation for everything, > >>> as opposed to one SNMP operation per interface. > >>> > >>> Please let me know if this would be the appropriate location for > >>> me to submit it to have it included in the Nagios plugin > >>> distribution. Like I said, it's pretty ugly, but I'd love it if > >>> someone cleaned it up and included it. > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >> > >> > >> > >> > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: To learn the basics of securing > > your web site with SSL, click here to get a FREE TRIAL of a Thawte > > Server Certificate: http://www.gothawte.com/rd524.html > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > > > > > -- From sghosh at sghosh.org Fri Nov 15 14:51:02 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Nov 15 14:51:02 2002 Subject: [Nagiosplug-devel] check_iftable - Submission In-Reply-To: <3DD57692.2010506@wholefoods.com> Message-ID: the current version does skip interfaces with an ifType of 23 (PPP) The ifConnectorPresent may not work as well if we have ATM/FR PVCs defined as virtual interfaces - no connectors :( It might be possible to make a user-defineable listy of itTypes to ignore -but that will have to wait till the next release. -sg On Fri, 15 Nov 2002, Rob King wrote: > Hey everyone, > Ah-ha! I did find a difference. Now I remember why I did it this > way. My script also checks the ifConnectorPresent attribute, and doesn't > send out an alert if a connector is not present. This prevents it from > sending out an error on "virtual" interfaces that are usually down, like > dial-out ports. > > Sorry, that's the difference. :) > > Thanks, > Rob > > > Rob King wrote: > > > Hey Subhendu, > > *grins* Now that I've looked at the check_ifstatus, I don't really > > see much of a difference. Sorry, when I grabbed the help message for > > check_ifstatus and I saw that it had a option, I thought that > > it was used for checking specific ports. > > > > So, that's my bad. Duplication of labor, all my fault. > > > > Thanks for the pointer, though. > > > > Rob > > > > Subhendu Ghosh wrote: > > > >> Post it to the list. > >> > >> How different is this from check_ifstatus ? > >> > >> FYI - there is no table command in snmpv2 - but an implementation of > >> getbulk recursion for the snmptable cmdline app in the net-snmp > >> distribution. > >> > >> -sg > >> > >> On Fri, 15 Nov 2002, Rob King wrote: > >> > >> > >> > >>> Hey everyone, > >>> I've written a Nagios plugin (in very ugly Bourne shell code) > >>> that uses the SNMPv2 TABLE command to poll all the interfaces on a > >>> router/machine, and give output like "Interfaces: 653 up, 32 down, 1 > >>> admin down, 1 disconnected". It seems to work fine, as we're using > >>> it to monitor approx. 200 routers. The benefit to this is that it > >>> checks all the interfaces using one SNMP operation for everything, > >>> as opposed to one SNMP operation per interface. > >>> > >>> Please let me know if this would be the appropriate location for > >>> me to submit it to have it included in the Nagios plugin > >>> distribution. Like I said, it's pretty ugly, but I'd love it if > >>> someone cleaned it up and included it. > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >> > >> > >> > >> > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: To learn the basics of securing > > your web site with SSL, click here to get a FREE TRIAL of a Thawte > > Server Certificate: http://www.gothawte.com/rd524.html > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > > > > > -- From noreply at sourceforge.net Fri Nov 15 18:25:01 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Fri Nov 15 18:25:01 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-638898 ] check_ldap enhancement Message-ID: Patches item #638898, was opened at 2002-11-15 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638898&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gyula Szabo (gyufi) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap enhancement Initial Comment: This patch is provide some new argument to plugin. You could compare an LDAP attribute value with the set limits or an expected value. There is verbose mode, print all readable attribute from the DN. New arguments are: [-a ] [-e ] [-W ] [-C ] [-r] [-v] We use it to check the monitoring DN in iPlanet, for currentconnections, threads, replica status etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638898&group_id=29880 From karl at debisschop.net Fri Nov 15 21:07:01 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 15 21:07:01 2002 Subject: [Nagiosplug-devel] RE: nagiosplug- check_snmp In-Reply-To: References: Message-ID: <1037423128.1089.9.camel@miles.debisschop.net> On Fri, 2002-11-15 at 12:39, Subhendu Ghosh wrote: > I'll put the changes into CVS. I basically like your changes. It does render one block ol code redundant, so I remomed it. Also, I reorganized process areguents to reflect the logic you/we outlined: if (INTEGER comparison) else if ( STRING comparision flag set) else if (REGEX comparison flag set) else ( existence/nonexistence) The down side of that is CVS sees it as a major change. Actually, it's not. Anyway, maybe we're converging to releaseable code. -- Karl DeBisschop From mike at beakerware.net Fri Nov 15 23:48:02 2002 From: mike at beakerware.net (Michael Kingsbury) Date: Fri Nov 15 23:48:02 2002 Subject: [Nagiosplug-devel] Tags in the CVS repository... Message-ID: I was trying to add in someone's request for a feature in check_disk, and in the process came across a bug in it. Unfortunately, it was rather difficult to tell what version in the CVS repository corresponses with what is in tar balls etc... I'd like to make a suggestion of creating a tag per 'released' version of a source code tarball to make life easier on those trying to follow what's going on in the repository.... -mike From p.miquet at hafiba.fr Sat Nov 16 00:35:01 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Sat Nov 16 00:35:01 2002 Subject: [Nagiosplug-devel] Integration of customized plugin Message-ID: <1037435637.4974.17.camel@moishe> Certainly, I'll make some specific plugin. What would be the best way to get them integrated ? Note that people using this kind of plugin should be very limited, due to the fact that it will survey some third party software from DALiM Software. Or should I manage my own CVS admin ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at debisschop.net Sat Nov 16 04:48:03 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Sat Nov 16 04:48:03 2002 Subject: [Nagiosplug-devel] Tags in the CVS repository... In-Reply-To: References: Message-ID: <1037450788.1154.2.camel@miles.debisschop.net> On Sat, 2002-11-16 at 02:45, Michael Kingsbury wrote: > I was trying to add in someone's request for a feature in check_disk, and > in the process came across a bug in it. Unfortunately, it was rather > difficult to tell what version in the CVS repository corresponses with what > is in tar balls etc... I'd like to make a suggestion of creating a tag per > 'released' version of a source code tarball to make life easier on those > trying to follow what's going on in the repository.... > > -mike > No release so far, so no tags. But in the future we will tag alphas and beta's too. Please note that 'check_disk --version' will give you the CVS version of the plugin in question. (if you get 1.1.1.1, that means it is the code originally moved over from the nesaint plugins 1.3.0 branch). -- Karl DeBisschop From karl at debisschop.net Sat Nov 16 04:58:01 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Sat Nov 16 04:58:01 2002 Subject: [Nagiosplug-devel] makefile.am patch for check_tcp programs In-Reply-To: References: Message-ID: <1037451378.1089.4.camel@miles.debisschop.net> On Thu, 2002-11-14 at 19:05, Ton Voon wrote: > Karl, > > I've been looking through the automake manual and I think this is a > clean way of getting check_ftp, check_imap and the other check_tcp > derivative programs to be added to the makefile for make all, install > and uninstall. The patch is below. This was tested on MacOSX, but I'm > hoping to try it out on a Solaris server tomorrow - if you have a new a > snapshot ready! > > Ton Thanks! Looks good from here, I'm commiting the changes to CVS now. -- Karl DeBisschop From p.miquet at hafiba.fr Sat Nov 16 11:17:04 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Sat Nov 16 11:17:04 2002 Subject: [Nagiosplug-devel] How to configure services Message-ID: <1037472180.4866.8.camel@moishe> I need to make a plugin to check workflows state, priority, and so on ... All theses workflows run on a server, thought a specific service. I'd like to know how I have to configure each "service". Let's say that my serveur run two workflows wfl1 and wfl2 Do I have to set a service for my aplications, and two services for wfl1 and wfl2. And finaly set two service dependencies for service of wfl1 and service of wfl2 depending on the serveur state. Any good idea is welcome. Regards Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Sat Nov 16 22:35:01 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Sat Nov 16 22:35:01 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-639268 ] check_disk -p option broken Message-ID: Bugs item #639268, was opened at 2002-11-16 02:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=639268&group_id=29880 Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Michael Kingsbury (mkingsbury) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk -p option broken Initial Comment: The -p option on check_disk (CVS version 1.4) is broken. Given an option -p "/ /boot", where / is /dev/md0 and /boot is /dev/hda1, I get the output: "DISK OK - [27018 kB (61%) free on /dev/hda1] [27018kB (61%) free on /dev/hda1]. where the /boot partion is displayed twice rather than /dev/md0. The version in the v1.3 Beta1 tarball does not have this problem. -mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=639268&group_id=29880 From sghosh at sghosh.org Sun Nov 17 12:37:02 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sun Nov 17 12:37:02 2002 Subject: [Nagiosplug-devel] Integration of customized plugin In-Reply-To: <1037435637.4974.17.camel@moishe> Message-ID: Post it to the list. It will get included in the contrib dir. If enough people use it and give feedback - it'll get migrated into the standard install dirs. -sg On 16 Nov 2002, Pascal Miquet wrote: > Certainly, I'll make some specific plugin. > What would be the best way to get them integrated ? > Note that people using this kind of plugin should be very limited, due > to the fact that it will survey some third party software from DALiM > Software. > > Or should I manage my own CVS admin ? > > Regards > > > > -- From mm at elabnet.de Mon Nov 18 03:20:03 2002 From: mm at elabnet.de (Michael Markstaller) Date: Mon Nov 18 03:20:03 2002 Subject: [Nagiosplug-devel] Submission: check_insight / checking Compaq Insight Agent status Message-ID: <4DA50FC8108BE44696B4F837E0C631F5039FE0@elab1.elabnet.com> Hi, I've been looking to check the status/health of Compaq Insight Agents on servers and found a spong plugin (http://spong.sourceforge.net/downloads/plugins/spong-network/check_insi ght) which I've slightly changed to work with Nagios. I have pretty no idea of perl at all, just wanted to make it work for me, so please don't shoot me for this copy-paste-code. I've tested some basic things, it seems to work at least to report a warning if smthg is degraded and OK of xcourse ;) I'm also quite unsure if this is the right way to submit, so I'll just try ;) There're some "unknown" components on all servers I've checked so far, if anybody has a documentation of what's exactly returned when getting the OID 1.3.6.1.4.1.232.11.2.10.1.0 (CPQHOST_MIB isn't very descriptive) I'd be happy to fix this. --- cut --- #!/usr/bin/perl # # (c)2002 Michael Markstaller, Elaborated Networks GmbH # send bug reports to # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # you should have received a copy of the GNU General Public License # along with this program (or with Nagios); if not, write to the # Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA # # # Check Comapq Insight Management Agents Systems Status by SNMP # based on the spong-plugin check_insight from: # http://spong.sourceforge.net/downloads/plugins/spong-network/check_insig ht # # Usage: # check_insight -H -C community # use Net::SNMP; use Getopt::Long; Getopt::Long::Configure('bundling'); $version=0.01; my %ERRORS = ('UNKNOWN' , '-1', 'OK' , '0', 'WARNING', '1', 'CRITICAL', '2'); # # some default values # $TIMEOUT=15; # # get command line options the regular way # GetOptions ("V" => \$opt_V, "version" => \$opt_V, "h" => \$opt_h, "help" => \$opt_h, "v" => \$verbose, "verbose" => \$verbose, "H=s" => \$opt_H, "hostname=s" => \$opt_H, "C=s" => \$opt_C, "community=s" => \$opt_C); # # handle the verbose stuff first # if ($opt_V) { print "\n"; print "check_insight nagios plugin version $version\n"; print "\n"; print "The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute\n"; print "copies of the plugins under the terms of the GNU General Public License.\n"; print "For more information about these matters, see the file named COPYING.\n"; print "\n"; print "(c)2002 Michael Markstaller, Elaborated Networks GmbH\n"; print "\n"; print "\n"; exit $ERRORS{'UNKNOWN'}; } if ($opt_h) { print_help(); exit $ERRORS{'UNKNOWN'}; } # # now get options the weired way and set the defaults # if nothing else is provided # $opt_H = shift unless ($opt_H); print_usage() unless ($opt_H); # # dont let us wait forever... # $SIG{'ALRM'} = sub { print ("ERROR: No response from server (alarm)\n"); exit $ERRORS{"UNKNOWN"}; }; alarm($TIMEOUT); # # now we set things up for the real work # and fire up the request # ######################################################################## ######## my ($host) = ($opt_H); my ($color, $summary, $message ) = ( "green", "", "" ); ($opt_C) || ($opt_C = shift) || ($opt_C = "public"); my ($community) = $opt_C; # We use some look up tables for checking some config options. my (@State) = ("Not Available", "Other", "OK", "Degraded", "Failed"); my (@MIBName) = ("", "Std", "Unknown", "Array", "Netware", "SCSI", "Health","Unknown", "Store", "SM2", "Thresh", "OS", "UPS", "Unknown", "IDE", "Clusters", "Fibre", "MIB", "NIC"); # These are the positions within the table to actually look at. my (@MIBs) = (1, 2, 3, 5, 6, 10, 11, 14, 18); my ($oid) = "1.3.6.1.4.1.232.11.2.10.1.0"; # SysArray # Open the connection. my ($session, $error) = Net::SNMP->session(Hostname => $host, Community => $community); # If we can't open a connection, just return red straight away. if (! defined $session) { print ("ERROR: Unable to contact server '$opt_H'\n"); exit $ERRORS{"UNKNOWN"}; } $session->translate; my ($response) = $session->get_request($oid); if (!defined $response) { # If there's no response, something screwy is going on, give up. $summary = $session->error; print ("ERROR: $summary\n"); exit $ERRORS{"UNKNOWN"}; $session->close; } else { $session->close; # I'm not convinced that this is the easiest way to go about this, this is # from some code which I've inherited and I've modified for use in here. # Hi George! %h = %$response; my ($d) = $h{$oid}; my (@list) = (); # Gobble the first two char's. $d = substr $d,2; while (length($d) > 0) { my ($v) = substr($d,0,2); $v = hex($v); $d = substr $d,2; push @list, $v; } # Value in $MIBs[1] is the overall status of the machine... my ($cond) = $MIBs[1]; $message .= "Status: $State[$cond] "; foreach my $v (@MIBs) { $cond = $list[($v*4)+1]; # A little bit of magic. # We only bother printing the status out if it's actually available, # as if it's N/A or Unknown then it's probably because the machine # isn't available. $message .= "$MIBName[$v]: $State[$cond] " if $cond > 1; next if $cond < 2; # What follows is some trickery to try and not to override a previous # message at the same or lower color. if ($cond == 4) { if ($color ne 'red') { $color = 'red'; $summary = "$MIBName[$v] is failed"; } } elsif ($cond == 3) { if ($color ne 'red') { $color = 'yellow'; $summary = "$MIBName[$v] is degraded" if $summary eq ""; } } elsif ($cond < 2) { if ($color eq 'green') { $color = 'yellow'; $summary = "$MIBName[$v] is unknown ($cond)" if $summary eq ""; } } } } $summary = "Ok" if $summary eq ""; # return ($color, $summary, $message); if ($color eq 'red') { print ("red Output: $message\n"); exit $ERRORS{"CRITICAL"}; } elsif ($color eq 'yellow') { print ("$summary $message\n"); exit $ERRORS{"WARNING"}; } elsif ($color eq 'green') { print ("$message\n"); exit $ERRORS{"OK"}; } sub print_usage () { print "Usage: $0 -H -C \n"; } sub print_help () { print "\n"; print "\n"; print "check_insight nagios plugin version $version\n"; print "\n"; print "The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute\n"; print "copies of the plugins under the terms of the GNU General Public License.\n"; print "For more information about these matters, see the file named COPYING.\n"; print "\n"; print "(c)2002 Michael Markstaller, Elaborated Networks GmbH\n"; print "\n"; print "\n"; print "This plugin checks the Compaq Insight Management agents system status via SNMP on the specified host.\n"; print "\n"; print "\n"; print_usage(); print "\n"; print "Options:\n"; print " -H, --hostname=ADDRESS\n"; print " host name argument for server.\n"; print " -C, --community=STRING\n"; print " SNMP Read-community string.\n"; print " -h, --help\n"; print " print detailed help screen.\n"; print " -V, --version\n"; print " print version information.\n"; print "\n"; print "\n"; } --- cut --- Michael From Ton.Voon at egg.com Mon Nov 18 03:41:02 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Mon Nov 18 03:41:02 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211181100 for Solaris Message-ID: <53104E20A25CD411B556009027E50636064D4EB8@pnnemp02.pn.egg.com> Compile report for nagios-plugins-200211181100 on Solaris. $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 $ uname -a SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 Using Solaris' make command. No automake, aclocal or autoconf. $ ./configure $ make gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c check_time.c check_time.c: In function `main': check_time.c:101: warning: passing arg 2 of `recv' from incompatible pointer type All plugins compile successfully - compilation is much smoother now. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From p.miquet at hafiba.fr Mon Nov 18 05:43:13 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Mon Nov 18 05:43:13 2002 Subject: [Nagiosplug-devel] Disfonctionnement of plugins Message-ID: <1037626920.4783.35.camel@moishe> Hello, This is what I've done : I've got a host named ADAM. On this host, I've got three services ping, twist server, workflows checks. Note that was done to test how nagios behave with my plugins. Unfortunately, there is no remote execution of my plugin. So the check is made on my laptop Moishe, and return succefull, because the service is there. BUT when the network cable is disconnected, the HOST ADAM is in critcal state, the ping service also, but the two other services are OK, because they check Moishe rather than ADAM, but into the system, those two service are attached to the ADAM host. Should it be some checks according mismatched result between Host and services attached ? This to infor administrator that behavior is not what user expect. Regards Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.haro at ceres.ca.gov Mon Nov 18 09:37:03 2002 From: michael.haro at ceres.ca.gov (Michael Haro) Date: Mon Nov 18 09:37:03 2002 Subject: [Nagiosplug-devel] problem with plugins/Makefile.am Message-ID: <002301c28f29$1414e520$240110ac@DARKSTAR> I updated from CVS, ran tools/setup and then configure and make make install failed with at the ln -sf stuff replacing ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ with (cd $(DESTDIR)$(libexecdir) && ln -sf check_tcp $$i ) \ solved my problem. I'm not sure if this is a correct fix though. This is on Solaris 8 using gnu-make. Michael From Jeremy.Bouse at UnderGrid.net Mon Nov 18 09:57:02 2002 From: Jeremy.Bouse at UnderGrid.net (Jeremy T. Bouse) Date: Mon Nov 18 09:57:02 2002 Subject: [Nagiosplug-devel] IPv6 support Message-ID: <20021118175445.GB2664@UnderGrid.net> Just trying to find out if anyone else is in my situation and trying to monitor both IPv4 and IPv6 hosts from a dual-stacked machine... I'm currently working with the CVS version of the plugins with the intent of getting them to be able to support IPv6 as well as the current IPv4 equally... Currently I have the check_ping plugin working with the ability to specify a seperate binary for IPv6 pings and working on the other TCP/UDP service plugins... As soon as I have a working patch against the CVS repository I will submit the patch.... I just wanted to make a notice in the case someone else was working on this so we might not duplicate efforts... Jeremy T. Bouse Jeremy.Bouse at UnderGrid.net jbouse at Debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sghosh at sghosh.org Mon Nov 18 10:48:05 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Nov 18 10:48:05 2002 Subject: [Nagiosplug-devel] IPv6 support In-Reply-To: <20021118175445.GB2664@UnderGrid.net> Message-ID: Not yet - although I expect to bump up against it relatively soon. IPv6 patches will probably get held up until we do the next release. What would be nice is to start with a patch for utils.c to be able to match a IPv6 address similar to the current check for a IPv4 address. -sg On Mon, 18 Nov 2002, Jeremy T. Bouse wrote: > Just trying to find out if anyone else is in my situation and > trying to monitor both IPv4 and IPv6 hosts from a dual-stacked > machine... I'm currently working with the CVS version of the plugins > with the intent of getting them to be able to support IPv6 as well as > the current IPv4 equally... > > Currently I have the check_ping plugin working with the ability > to specify a seperate binary for IPv6 pings and working on the other > TCP/UDP service plugins... As soon as I have a working patch against the > CVS repository I will submit the patch.... I just wanted to make a > notice in the case someone else was working on this so we might not > duplicate efforts... > > Jeremy T. Bouse > Jeremy.Bouse at UnderGrid.net > jbouse at Debian.org > -- From Daniel.Rusch at GlobalCrossing.com Mon Nov 18 11:14:02 2002 From: Daniel.Rusch at GlobalCrossing.com (Rusch, Daniel) Date: Mon Nov 18 11:14:02 2002 Subject: [Nagiosplug-devel] check_javaproc.pl Message-ID: <0DA06E553C3BD511823500508BB8965A02D20AD5@exnadetmbx3.ams.gblxint.com> I saw a posting concerning a plugin called check_javaproc.pl I have searched the CVS tree but I am unable to find it, would someone direct me to it's location Thanks, Dan -----Original Message----- From: Subhendu Ghosh [mailto:sghosh at sghosh.org] Sent: Monday, November 18, 2002 12:47 PM To: nagiosplug-devel at lists.sourceforge.net Subject: Re: [Nagiosplug-devel] IPv6 support Not yet - although I expect to bump up against it relatively soon. IPv6 patches will probably get held up until we do the next release. What would be nice is to start with a patch for utils.c to be able to match a IPv6 address similar to the current check for a IPv4 address. -sg On Mon, 18 Nov 2002, Jeremy T. Bouse wrote: > Just trying to find out if anyone else is in my situation and > trying to monitor both IPv4 and IPv6 hosts from a dual-stacked > machine... I'm currently working with the CVS version of the plugins > with the intent of getting them to be able to support IPv6 as well as > the current IPv4 equally... > > Currently I have the check_ping plugin working with the ability > to specify a seperate binary for IPv6 pings and working on the other > TCP/UDP service plugins... As soon as I have a working patch against the > CVS repository I will submit the patch.... I just wanted to make a > notice in the case someone else was working on this so we might not > duplicate efforts... > > Jeremy T. Bouse > Jeremy.Bouse at UnderGrid.net > jbouse at Debian.org > -- ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel From Jeremy.Bouse at UnderGrid.net Mon Nov 18 11:47:05 2002 From: Jeremy.Bouse at UnderGrid.net (Jeremy T. Bouse) Date: Mon Nov 18 11:47:05 2002 Subject: [Nagiosplug-devel] IPv6 support In-Reply-To: References: <20021118175445.GB2664@UnderGrid.net> Message-ID: <20021118194427.GA5560@UnderGrid.net> On Mon, Nov 18, 2002 at 01:47:08PM -0500, Subhendu Ghosh wrote: > Not yet - although I expect to bump up against it relatively soon. > I both work in a dual-stacked environment and maintain one at home as well... Very handy for accessing all my machines behind the firewall with limited v4 address space... > IPv6 patches will probably get held up until we do the next release. > Understandable that is why I've been doing my work so it worked no matter which [IPv4 or IPv6] were used... However the one catch I'm possibly foreseeing is the configuration files being colon delimited for Nagios itself... > What would be nice is to start with a patch for utils.c to be able to > match a IPv6 address similar to the current check for a IPv4 address. > I'm actually working with some of the internal library functions to re-write the verify code so there is a seperate routine to check for v4 and v6 as well as the hostname... I'm doing this in plugins/utils.c but I"m also finding that my_connect() in plugins/netutils.c will need to be modified to handle v4 and v6 socket connections but after that the read and writes to the sock descriptor should not care one way or the other... Configure routines might need to be changed to actually check for the existence of the v6 support but have to look into which means of checking would be reliable for cross-platform... Jeremy From sghosh at sghosh.org Mon Nov 18 12:15:10 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Nov 18 12:15:10 2002 Subject: [Nagiosplug-devel] check_javaproc.pl In-Reply-To: <0DA06E553C3BD511823500508BB8965A02D20AD5@exnadetmbx3.ams.gblxint.com> Message-ID: On Mon, 18 Nov 2002, Rusch, Daniel wrote: > I saw a posting concerning a plugin called check_javaproc.pl I have > searched the CVS tree but I am unable to find it, would someone direct me to > it's location > > Thanks, > > Dan > Should be in CVS as of today - my email went out before I had finished the upload. FYI- browsing Sourceforge's CVS doesn't seem to be possible at the moment - guess they haven't totally finished their move. -- -sg From karl at debisschop.net Mon Nov 18 23:16:02 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Nov 18 23:16:02 2002 Subject: [Nagiosplug-devel] problem with plugins/Makefile.am In-Reply-To: <002301c28f29$1414e520$240110ac@DARKSTAR> References: <002301c28f29$1414e520$240110ac@DARKSTAR> Message-ID: <1037690058.1089.34.camel@miles.debisschop.net> On Mon, 2002-11-18 at 12:36, Michael Haro wrote: > I updated from CVS, ran tools/setup and then configure and make > > make install failed with at the ln -sf stuff > > replacing > ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ > with > (cd $(DESTDIR)$(libexecdir) && ln -sf check_tcp $$i ) \ > > solved my problem. I'm not sure if this is a correct fix though. > > This is on Solaris 8 using gnu-make. > > Michael Thanks. I updated CVS with: install-exec-hook: cd $(DESTDIR)$(libexecdir) for i in $(check_tcp_programs) ; do ln -sf check_tcp $$i ; done which should have the same effect as your patch -- Karl DeBisschop From karl at debisschop.net Mon Nov 18 23:36:03 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Nov 18 23:36:03 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211181100 for Solaris In-Reply-To: <53104E20A25CD411B556009027E50636064D4EB8@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4EB8@pnnemp02.pn.egg.com> Message-ID: <1037691276.1088.38.camel@miles.debisschop.net> On Mon, 2002-11-18 at 06:40, Voon, Ton wrote: > Compile report for nagios-plugins-200211181100 on Solaris. > > $ gcc -v > Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs > gcc version 2.8.1 > $ uname -a > SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 > > Using Solaris' make command. No automake, aclocal or autoconf. > > $ ./configure > $ make > gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c > check_time.c > check_time.c: In function `main': > check_time.c:101: warning: passing arg 2 of `recv' from incompatible pointer > type I'm stumped. Can you send me the man page from SunOS 5.6? > All plugins compile successfully - compilation is much smoother now. Thanks in great measure to the patience and repeated build tests of the Sun/Solris users on the list. -- Karl DeBisschop From p.miquet at hafiba.fr Mon Nov 18 23:46:05 2002 From: p.miquet at hafiba.fr (Pascal Miquet) Date: Mon Nov 18 23:46:05 2002 Subject: [Nagiosplug-devel] Support of NPRE addon Message-ID: <1037691934.14764.2.camel@moishe> Hello, Is there some support of the NRPE addon. I've fetched the NRPE code, and look inside, and find some HARD coded configuration, like /usr/local/nagios. If the nagios installation was configured on a different location, I think this addon will not work. So If I made changes, was is the best way to get this modifications integrated into "official" version. Regards Pascal Miquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ton.Voon at egg.com Tue Nov 19 02:25:01 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Nov 19 02:25:01 2002 Subject: [Nagiosplug-devel] Report on nagios-plugins-200211181100 for Solaris Message-ID: <53104E20A25CD411B556009027E50636064D4ED3@pnnemp02.pn.egg.com> The man page for recv on SunOS 5.6: <> I changed line 101 from: result = recv (sd, &raw_server_time, sizeof (raw_server_time), 0); to: result = recv (sd, (void *)&raw_server_time, sizeof (raw_server_time), 0); and this seemed to compile fine, but I'm not sure if this is a good fix. > -----Original Message----- > From: Karl DeBisschop [SMTP:karl at debisschop.net] > Sent: Tuesday, November 19, 2002 7:35 AM > To: Voon, Ton > Cc: 'nagiosplug-devel at lists.sourceforge.net' > Subject: Re: [Nagiosplug-devel] Report on nagios-plugins-200211181100 > for Solaris > > On Mon, 2002-11-18 at 06:40, Voon, Ton wrote: > > Compile report for nagios-plugins-200211181100 on Solaris. > > > > $ gcc -v > > Reading specs from > /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs > > gcc version 2.8.1 > > $ uname -a > > SunOS tortoise 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 > > > > Using Solaris' make command. No automake, aclocal or autoconf. > > > > $ ./configure > > $ make > > gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. -g -O2 -c > > check_time.c > > check_time.c: In function `main': > > check_time.c:101: warning: passing arg 2 of `recv' from incompatible > pointer > > type > > I'm stumped. > > Can you send me the man page from SunOS 5.6? > > > All plugins compile successfully - compilation is much smoother now. > > Thanks in great measure to the patience and repeated build tests of the > Sun/Solris users on the list. > > -- > Karl DeBisschop This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: recv.txt URL: From Ton.Voon at egg.com Tue Nov 19 07:12:06 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Nov 19 07:12:06 2002 Subject: FW: [Nagiosplug-devel] problem with plugins/Makefile.am Message-ID: <53104E20A25CD411B556009027E50636064D4EDF@pnnemp02.pn.egg.com> > On Mon, 2002-11-18 at 12:36, Michael Haro wrote: > > I updated from CVS, ran tools/setup and then configure and make > > > > make install failed with at the ln -sf stuff > > > > replacing > > ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ > > with > > (cd $(DESTDIR)$(libexecdir) && ln -sf check_tcp $$i ) \ > > > > solved my problem. I'm not sure if this is a correct fix though. > > > > This is on Solaris 8 using gnu-make. > > > > Michael > > Thanks. I updated CVS with: > > install-exec-hook: > cd $(DESTDIR)$(libexecdir) > for i in $(check_tcp_programs) ; do ln -sf check_tcp $$i ; done > > which should have the same effect as your patch > -- Karl DeBisschop I think this will not work because each makefile line is run in a separate subshell. I've tested the following and it works okay: install-exec-hook: cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do ln -sf check_tcp $$i ; done Also, I've noticed that in SunOS 5.6 and SunOS 5.8: $ cd /tmp $ touch afile $ ln -sf afile alink $ ln -sf afile alink ln: cannot create alink: File exists Which I'm sure is not correct behaviour. To overcome this, can the links be hard links? install-exec-hook: cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do ln -f check_tcp $$i ; done Or add an rm before the ln -sf? install-exec-hook: cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do rm -f $$i ; ln -sf check_tcp $$i ; done This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From kdebisschop at mail.debisschop.net Tue Nov 19 07:13:08 2002 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Tue Nov 19 07:13:08 2002 Subject: [Nagiosplug-devel] Re: Report on nagios-plugins-200211181100 for Solaris In-Reply-To: <53104E20A25CD411B556009027E50636064D4ED3@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4ED3@pnnemp02.pn.egg.com> Message-ID: Voon, Ton writes: > The man page for recv on SunOS 5.6: <> > I changed line 101 from: > result = recv (sd, &raw_server_time, sizeof (raw_server_time), 0); > to: > result = recv (sd, (void *)&raw_server_time, sizeof > (raw_server_time), 0); > and this seemed to compile fine, but I'm not sure if this is a good fix. I believe it is a perfectly fine fix. Thanks. -- Karl From kdebisschop at mail.debisschop.net Tue Nov 19 07:21:04 2002 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Tue Nov 19 07:21:04 2002 Subject: [Nagiosplug-devel] Re: problem with plugins/Makefile.am In-Reply-To: <53104E20A25CD411B556009027E50636064D4EDF@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D4EDF@pnnemp02.pn.egg.com> Message-ID: Voon, Ton writes: >> On Mon, 2002-11-18 at 12:36, Michael Haro wrote: >> > I updated from CVS, ran tools/setup and then configure and make >> > >> > make install failed with at the ln -sf stuff >> > >> > replacing >> > ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ >> > with >> > (cd $(DESTDIR)$(libexecdir) && ln -sf check_tcp $$i ) \ >> > >> > solved my problem. I'm not sure if this is a correct fix though. >> > >> > This is on Solaris 8 using gnu-make. >> > >> > Michael >> >> Thanks. I updated CVS with: >> >> install-exec-hook: >> cd $(DESTDIR)$(libexecdir) >> for i in $(check_tcp_programs) ; do ln -sf check_tcp $$i ; done >> >> which should have the same effect as your patch >> > -- > Karl DeBisschop > > I think this will not work because each makefile line is run in a separate > subshell. I've tested the following and it works okay: > > install-exec-hook: > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do ln > -sf check_tcp $$i ; done duh. Thanks. > Also, I've noticed that in SunOS 5.6 and SunOS 5.8: > $ cd /tmp > $ touch afile > $ ln -sf afile alink > $ ln -sf afile alink > ln: cannot create alink: File exists > > Which I'm sure is not correct behaviour. To overcome this, can the links be > hard links? I'd prefer to retain the symlinks so RPM and other packages can minimize installed footprint. Can't we do instead: for i in $(check_tcp_programs); do rm $$i; ln -sf check_tcp $$i; done > install-exec-hook: > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do ln > -f check_tcp $$i ; done > > Or add an rm before the ln -sf? > > install-exec-hook: > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do rm > -f $$i ; ln -sf check_tcp $$i ; done > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > From Ton.Voon at egg.com Tue Nov 19 07:25:02 2002 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Nov 19 07:25:02 2002 Subject: [Nagiosplug-devel] RE: problem with plugins/Makefile.am Message-ID: <53104E20A25CD411B556009027E50636064D4EE0@pnnemp02.pn.egg.com> I think symlinks are best too. install-exec-hook: cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; do rm -f $$i ; ln -sf check_tcp $$i ; done You need to add an rm -f to cater for the first install. > -----Original Message----- > From: Karl DeBisschop [SMTP:kdebisschop at mail.debisschop.net] > Sent: Tuesday, November 19, 2002 3:19 PM > To: Voon, Ton > Cc: 'Karl DeBisschop'; 'Michael Haro'; 'NagiosPlug Devel' > Subject: Re: problem with plugins/Makefile.am > > Voon, Ton writes: > > >> On Mon, 2002-11-18 at 12:36, Michael Haro wrote: > >> > I updated from CVS, ran tools/setup and then configure and make > >> > > >> > make install failed with at the ln -sf stuff > >> > > >> > replacing > >> > ln -sf $(DESTDIR)$(libexecdir)/check_tcp $$i; \ > >> > with > >> > (cd $(DESTDIR)$(libexecdir) && ln -sf check_tcp $$i ) \ > >> > > >> > solved my problem. I'm not sure if this is a correct fix though. > >> > > >> > This is on Solaris 8 using gnu-make. > >> > > >> > Michael > >> > >> Thanks. I updated CVS with: > >> > >> install-exec-hook: > >> cd $(DESTDIR)$(libexecdir) > >> for i in $(check_tcp_programs) ; do ln -sf check_tcp $$i ; done > >> > >> which should have the same effect as your patch > >> > > -- > > Karl DeBisschop > > > > I think this will not work because each makefile line is run in a > separate > > subshell. I've tested the following and it works okay: > > > > install-exec-hook: > > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; > do ln > > -sf check_tcp $$i ; done > > duh. Thanks. > > > Also, I've noticed that in SunOS 5.6 and SunOS 5.8: > > $ cd /tmp > > $ touch afile > > $ ln -sf afile alink > > $ ln -sf afile alink > > ln: cannot create alink: File exists > > > > Which I'm sure is not correct behaviour. To overcome this, can the links > be > > hard links? > > I'd prefer to retain the symlinks so RPM and other packages can minimize > installed footprint. > > Can't we do instead: > > for i in $(check_tcp_programs); do rm $$i; ln -sf check_tcp $$i; done > > > install-exec-hook: > > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; > do ln > > -f check_tcp $$i ; done > > > > Or add an rm before the ln -sf? > > > > install-exec-hook: > > cd $(DESTDIR)$(libexecdir) && for i in $(check_tcp_programs) ; > do rm > > -f $$i ; ln -sf check_tcp $$i ; done > > > This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From alexis.guillard at bt.com Wed Nov 20 07:13:02 2002 From: alexis.guillard at bt.com (alexis.guillard at bt.com) Date: Wed Nov 20 07:13:02 2002 Subject: [Nagiosplug-devel] patch to have check_http working with proxy Message-ID: <7497DCA1C240C042B28F6657ADFD8E096C5C3E@i2km11-ukbr.domain1.systemhost.net> Hi everyone, I wrote a patch (see attached documment) to have the plugging check_http using a proxy if environment 'http_proxy' or 'HTTP_PROXY' variable is defined. The diff has been done with the CVS of today. I hope this patch is going to be merge to the next version of nagios. Thank to let me know. Regards. Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: proxy_patch.diff Type: application/octet-stream Size: 3798 bytes Desc: not available URL: From krennmair at webdynamite.com Thu Nov 21 03:08:03 2002 From: krennmair at webdynamite.com (Andreas Krennmair) Date: Thu Nov 21 03:08:03 2002 Subject: [Nagiosplug-devel] patch for check_log.sh Message-ID: <1037876850.484.36.camel@wd3w> Hello! We had to modify the check_log plugin to make it work on our Linux systems. Has this module ever been tested? Anyway, a patch (unified diff against check_log.sh from nagiosplug-1.3.0 beta 1) is attached to this mail. Regards, Andreas Krennmair -- ________________________________________ Andreas Krennmair (Development) WebDynamite IT Solutions GmbH Landstra?e 49, A-4020 Linz, Austria http://www.webdynamite.com/ +43 / 732 / 777 810 - 0 (fixed) +43 / 732 / 777 810 - 50 (fax) ________________________________________ -------------- next part -------------- --- check_log Thu Nov 21 11:09:31 2002 +++ nagios/nagiosplug-1.3-beta1/plugins-scripts/check_log.sh Thu Feb 28 07:43:00 2002 @@ -62,8 +62,8 @@ ECHO="/bin/echo" GREP="/bin/grep" -DIFF="/usr/bin/diff" -TAIL="/usr/bin/tail" +DIFF="/bin/diff" +TAIL="/bin/tail" CAT="/bin/cat" RM="/bin/rm" @@ -183,12 +183,12 @@ # The temporary file that the script should use while # processing the log file. -if [ -x /bin/mktemp ]; then - tempdiff="`/bin/mktemp /tmp/check_log.XXXXXXXXXX`" +if [-x /bin/mktemp]; then + tempdiff="/bin/mktemp /tmp/check_log.XXXXXXXXXX" else - tempdiff="`/bin/date '+%H%M%S'`" - /bin/touch $tempdiff - /bin/chmod 600 $tempdiff + tempdiff="/tmp/check_log.`/bin/date '+%H%M%S'`" + /bin/touch $tempdiff + chmod 600 $tempdiff fi $DIFF $logfile $oldlog > $tempdiff @@ -209,4 +209,6 @@ $ECHO "($count) $lastentry" fi -exit $exitstatus +exit exitstatus + + From karl at debisschop.net Thu Nov 21 04:07:01 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 21 04:07:01 2002 Subject: [Nagiosplug-devel] patch for check_log.sh In-Reply-To: <1037876850.484.36.camel@wd3w> References: <1037876850.484.36.camel@wd3w> Message-ID: <1037880298.1116.9.camel@miles.debisschop.net> On Thu, 2002-11-21 at 06:07, Andreas Krennmair wrote: > Hello! > > We had to modify the check_log plugin to make it work on our Linux > systems. Has this module ever been tested? > > Anyway, a patch (unified diff against check_log.sh from nagiosplug-1.3.0 > beta 1) is attached to this mail. Please do your diffs against CVS. As far as I can see, athe consequetial changes in your patch have already been applied. Feel free to check me on that, however. Bear in in mind also that: DIFF="/bin/diff" TAIL="/bin/tail" gets changed to match your system by the configure/build process. For Linux: DIFF="/usr/bin/diff" TAIL="/usr/bin/tail" Thus, the change is not appropirate for a patch against the source. -- Karl DeBisschop From mark at zaneray.com Thu Nov 21 14:53:04 2002 From: mark at zaneray.com (Mark Morgan) Date: Thu Nov 21 14:53:04 2002 Subject: [Nagiosplug-devel] seg fault from check_procs on solaris 8 Message-ID: <3DDD639F.3090300@zaneray.com> I'm running nagios on solaris 8, and getting a seg fault on check_procs. I've traced it back to the fact that solaris is putting a return in the output of the ps command if terminal width isn't adequate for the length of the output. Is this a known problem, and if so, is anyone working on it? thanks, mm From karl at debisschop.net Thu Nov 21 15:16:12 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 21 15:16:12 2002 Subject: [Nagiosplug-devel] seg fault from check_procs on solaris 8 In-Reply-To: <3DDD639F.3090300@zaneray.com> References: <3DDD639F.3090300@zaneray.com> Message-ID: <1037920439.3190.58.camel@miles.debisschop.net> On Thu, 2002-11-21 at 17:52, Mark Morgan wrote: > I'm running nagios on solaris 8, and getting a seg fault on check_procs. > I've traced it back to the fact that solaris is putting a return in the > output of the ps command if terminal width isn't adequate for the length > of the output. Is this a known problem, and if so, is anyone working on it? Not know to me. -- Karl From karl at debisschop.net Thu Nov 21 16:33:02 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 21 16:33:02 2002 Subject: [Nagiosplug-devel] seg fault from check_procs on solaris 8 In-Reply-To: <3DDD639F.3090300@zaneray.com> References: <3DDD639F.3090300@zaneray.com> Message-ID: <1037925105.3190.62.camel@miles.debisschop.net> On Thu, 2002-11-21 at 17:52, Mark Morgan wrote: > I'm running nagios on solaris 8, and getting a seg fault on check_procs. > I've traced it back to the fact that solaris is putting a return in the > output of the ps command if terminal width isn't adequate for the length > of the output. Is this a known problem, and if so, is anyone working on it? Can you send some ps output that chokes check_procs? I'm not seeing where the problem might be, unless maybe thw line is getting wrapped after the command name and before the args? -- Karl From karl at debisschop.net Thu Nov 21 17:09:05 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Thu Nov 21 17:09:05 2002 Subject: [Nagiosplug-devel] seg fault from check_procs on solaris 8 In-Reply-To: <3DDD639F.3090300@zaneray.com> References: <3DDD639F.3090300@zaneray.com> Message-ID: <1037927232.2979.75.camel@miles.debisschop.net> On Thu, 2002-11-21 at 17:52, Mark Morgan wrote: > I'm running nagios on solaris 8, and getting a seg fault on check_procs. > I've traced it back to the fact that solaris is putting a return in the > output of the ps command if terminal width isn't adequate for the length > of the output. Is this a known problem, and if so, is anyone working on it? Unfortunately, the poster responded offline, so for anyone following this thread, I wanted to let you all know that the problem was fixed. In fact the fix was made early this week or lat last, and was already in CVS. If I can make these suggestions without sounding too rude, I have two comments: 1) try to keep conversations on the list so everyone can benefit. 2) before posting a bug, please try the CVS at sourceforge or the snapshots at http://www.debisschop.net/src/nagios/. Both of these practices conserve developer time, so more effort can be spent on fixing bugs. Thanks. -- Karl From noreply at sourceforge.net Thu Nov 21 20:18:02 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Thu Nov 21 20:18:02 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-641177 ] check_tcp fails to detecd some problems Message-ID: Patches item #641177, was opened at 2002-11-20 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=641177&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: cagri coltekin (coltekin) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp fails to detecd some problems Initial Comment: check_tcp uses same buffer for sending and receiving for send/expect strings. if remote service closes the connection without any data, check_tcp uses the same buffer for comparison, and if you expect to have same string, it fails to detect the problem. The small patch below works for me. It also ensures that NULL string is not passed to strip() (so strlen()) which core dumps on my (debian 3.0 with linux kernel 2.4.19, glibc 2.2.5) box at least. This is against nagiosplug-1.3-beta1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=641177&group_id=29880 From schlegel at riege.de Fri Nov 22 00:20:03 2002 From: schlegel at riege.de (Gunther Schlegel) Date: Fri Nov 22 00:20:03 2002 Subject: [Nagiosplug-devel] Patch for check_ups Message-ID: <1037953184.2114.170.camel@gauss.riege.de> Hi, we noticed that the check_ups script does not handle the "Replace Batteries" condition reported by some UPS systems. We have changed check_ups to report the warning state instead of ok and to display "replace batteries" instead of unknown. Source file and patch are attached. It compiled and works on our RedHat 7.3 netsaint server. regards, Gunther -- Gunther Schlegel Riege Software International GmbH Manager System Administration Mollsfeld 10 40670 Meerbusch, Germany Email: schlegel at riege.de Phone: +49-2159-9148-0 Fax: +49-2159-9148-11 --------------------------------------------------------------------- Disclaimer: You may grab my GPG key from http://www.keyserver.net . A nonproportional font is recommended for reading. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_ups.tgz Type: application/x-gzip Size: 5080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: From karl at debisschop.net Fri Nov 22 02:56:02 2002 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Nov 22 02:56:02 2002 Subject: [Nagiosplug-devel] Patch for check_ups In-Reply-To: <1037953184.2114.170.camel@gauss.riege.de> References: <1037953184.2114.170.camel@gauss.riege.de> Message-ID: <1037962459.2979.78.camel@miles.debisschop.net> On Fri, 2002-11-22 at 03:19, Gunther Schlegel wrote: > Hi, > > we noticed that the check_ups script does not handle the "Replace > Batteries" condition reported by some UPS systems. > > We have changed check_ups to report the warning state instead of ok and > to display "replace batteries" instead of unknown. > > Source file and patch are attached. It compiled and works on our RedHat > 7.3 netsaint server. > > regards, Gunther Thank. Patch is applied, plus a bunch of other (probably cosmetic) work. But I don't have a system I can test this on. I'd appreciate any feedback. -- Karl From torstei at linpro.no Fri Nov 22 04:08:04 2002 From: torstei at linpro.no (Torstein Tauno Svendsen) Date: Fri Nov 22 04:08:04 2002 Subject: [Nagiosplug-devel] Small patch for nrpe Message-ID: Shells that had been used to start the nrpe daemon would hang on exit (at least on solaris) because nrpe did not close it's file descriptors, attached patch for nrpe-1.5 solves this. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nrpe.diff URL: -------------- next part -------------- -- Torstein From noreply at sourceforge.net Fri Nov 22 06:45:02 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Fri Nov 22 06:45:02 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-642164 ] request for check_proxy Message-ID: Support Requests item #642164, was opened at 2002-11-21 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=642164&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: request for check_proxy Initial Comment: A way to use check_http (or equivalent in check_proxy) to request an url through a proxy, with proxy authentication support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=642164&group_id=29880 From noreply at sourceforge.net Fri Nov 22 06:45:02 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Fri Nov 22 06:45:02 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-642165 ] Request for more acurate timings Message-ID: Support Requests item #642165, was opened at 2002-11-21 23:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=642165&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Request for more acurate timings Initial Comment: Request for all plugins to report their response time in milli seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=642165&group_id=29880 From noreply at sourceforge.net Fri Nov 22 08:43:07 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Fri Nov 22 08:43:07 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-642352 ] accept environ for check_by_ssh / others Message-ID: Feature Requests item #642352, was opened at 2002-11-22 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=642352&group_id=29880 Category: None Group: Next Release (example) Status: Open Priority: 5 Submitted By: John Marquart (vaix) Assigned to: Nobody/Anonymous (nobody) Summary: accept environ for check_by_ssh / others Initial Comment: I came to realize that due to the use of spopen and the execve call, that the check_by_ssh script will ignore environmental variables. I think it would be very usefull to potentially allow environmental variables / a method for defining certain variables. For me, this came up, because I am using a kerberized (or more properly a gssapi hacked) ssh. I would like the ability to use the KRB5CCNAME environment variable so that I can define a credentials cache for nagios to use - and handle all check_by_ssh checks via gssapi authentication. I imagine that there are other hacks/uses of ssh which also depend on the env variables to be correctly set. Has anyone else come across problems w/ plugins that use the spopen function not being able to properly set environmental variables? Any solutions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=642352&group_id=29880 From mkloeffer at tycoint.com Wed Nov 27 04:16:02 2002 From: mkloeffer at tycoint.com (=?iso-8859-1?Q?Michael_Kl=F6ffer?=) Date: Wed Nov 27 04:16:02 2002 Subject: [Nagiosplug-devel] check_ntp Bug Message-ID: <000401c2960e$9dc0c500$7928020a@notemk> Hi, I just discovered a bug in check_ntp (not mainly, but...). check_ntp uses ntpdc to detect time differences on a host. When using ntpdc from a linux host against a OpenBSD timeserver you get the error message: nagios at nagioshost:/opt/nagios/libexec >check_ntp -H XX.XX.XX.XX server XX.XX.XX.XX, stratum 2, offset -0.027646, delay 0.02621 ntperr = 0 27 Nov 13:06:05 ntpdate[16598]: adjust time server XX.XX.XX.XX offset -0.027646 sec ntperr = 0 ***Server reports a format error in the received packet (shouldn't happen) UNKNOWN: Dispersion too high So I tried this manually, et voila: nagios at nagioshost:/opt/nagios/libexec >ntpdc -s XX.XX.XX.XX ***Server reports a format error in the received packet (shouldn't happen) But if you use ntpq : nagios at nagioshost:/opt/nagios/libexec >ntpq -c pe XX.XX.XX.XX remote refid st t when poll reach delay offset jitter ======================================================================== ====== +128.4.1.2 .GPS. 1 u 643 1024 377 104.428 17.515 36.599 +131.188.3.220 192.53.103.103 2 u 610 1024 377 16.268 16.840 3.375 +131.188.3.221 .DCFp. 1 u 630 1024 377 15.468 14.051 4.126 +130.149.17.21 .PPS. 1 u 472 1024 167 18.038 16.909 31.578 *192.53.103.103 .PTB. 1 u 190 1024 377 15.691 16.180 4.176 +129.69.1.153 .DCFp. 1 u 190 1024 377 9.221 13.958 3.472 +192.53.103.104 .PTB. 1 u 615 1024 377 16.242 17.285 2.929 LOCAL(0) LOCAL(0) 10 l 50 64 377 0.000 0.000 0.004 I fixed this by hacking check_ntp to check_ntp2. If interested, diffs are in the attachment. Bye, Michael. __________________________ Michael Kl?ffer Teamleiter Service S?d CKS SYSTEME GmbH & Co. KG tyco fire & security Brauerstr. 50 76135 Karlsruhe Telefon (0721) 2032-217 Telefax (0721) 2032-219 Mail mkloeffer at tycoint.com WWW www.cks-systeme.de __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ntp.diff Type: application/octet-stream Size: 4357 bytes Desc: not available URL: From james at cloud9.co.uk Wed Nov 27 08:24:01 2002 From: james at cloud9.co.uk (James Fidell) Date: Wed Nov 27 08:24:01 2002 Subject: [Nagiosplug-devel] check_dns problem Message-ID: <20021127162151.C4208@avarice.corp.cloud9.co.uk> When started, nslookup tries to look up the hostname of the server being used for queries. In the general case this is fine. However, if it is being used to do a lookup on a server which doesn't allow recursive queries and isn't authoritative for its own reverse address then the lookup times out and check_dns reports an error when there may be none. I've hacked check_dns.c to use "host" for the moment (since nslookup is deprecated anyway). Is there an alternative work-around for this problem (I guess check_dns should really do it's own DNS check rather than relying on any external application). James From james at cloud9.co.uk Wed Nov 27 09:47:06 2002 From: james at cloud9.co.uk (James Fidell) Date: Wed Nov 27 09:47:06 2002 Subject: [Nagiosplug-devel] beta2 check_mysql failure Message-ID: <20021127174518.E9254@avarice.corp.cloud9.co.uk> check_mysql from 1.3.0 beta2 dumps for core me in process_arguments. I believe the following is a correct patch: --- check_mysql.c.orig Wed Nov 27 17:41:56 2002 +++ check_mysql.c Wed Nov 27 17:41:59 2002 @@ -207,7 +207,7 @@ if (strlen(db) == 0 && argc > c) db = argv[c++]; - if (is_intnonneg (argv[c])) + if ( argc > c && is_intnonneg (argv[c])) db_port = atoi (argv[c++]); return validate_arguments (); James From Brian.Ipsen at andebakken.dk Wed Nov 27 10:38:03 2002 From: Brian.Ipsen at andebakken.dk (Brian Ipsen) Date: Wed Nov 27 10:38:03 2002 Subject: [Nagiosplug-devel] MSSQL plugin ? Message-ID: Hi! Has anyone done a plugin to check a MS SQL server ? I'm currently trying to put something together, which uses freetds 0.60. But since I'm no expert in either makefiles, the configure script etc, I'd really appreciate if someone could take care of that part once I have something, that seems to be working - maybe by including it in the plugins package once the code seems stable enough. Regards, /Brian Ipsen From jrozes at vinton.com Wed Nov 27 11:14:03 2002 From: jrozes at vinton.com (Jonathan Rozes) Date: Wed Nov 27 11:14:03 2002 Subject: [Nagiosplug-devel] MSSQL plugin ? Message-ID: <48B8D6ECC8C93E4E992AEB43EE8565DB040CDF@pdx-mail01.vinton.com> I cobbled a plugin together that uses sqsh (http://www.sqsh.org), which can be built using freetds. Here's a quick rundown of the setup: 1. Install and test sqsh. 2. Install the plugin included below in the plugin directory of your nagios installation and name it 'check_mssql'. 3. Create a file called '.sqshrc' in the nagios user's home directory with contents like so: \set username="USER" \set password="PASS" Where USER and PASS are the username and password needed to access the MS SQL server, respectively. Make sure the nagios user has permission to read the file (and probably nobody else unless you want to give away access to your SQL server). Using a read-only account is recommended. 4. Create a file called 'sqsh-NAME' (where NAME is the host_name used in your nagios config for this server) in some directory that the nagios user can access (like /usr/local/nagios/data or somesuch) with some SQL statements that constitute a simple check, like a SELECT from a small table in each database, like so: use mydatabase; select * from mytable; use myotherdatabase; select * from myothertable; 5. Setup a command entry in your config like so: define command{ command_name check_mssql command_line $USER1$/check_mssql -H $HOSTADDRESS$ -f /usr/local/nagios/data/sqsh-$HOSTNAME$ } You may want to add '-c' and '-w' arguments to change the warning and critical runtime thresholds as well. Run 'check_mssql -h' for complete usage instructions and default values. 6. Setup an appropriate service entry in your config. 7. Check your config, restart nagios and enjoy. The plugin is attached. I make no claims of portability, warranty, etc., so know what you're doing before doing it. Good luck, jonathan > -----Original Message----- > From: Brian Ipsen [mailto:Brian.Ipsen at andebakken.dk] > Sent: Wednesday, November 27, 2002 10:38 AM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] MSSQL plugin ? > > > Hi! > > Has anyone done a plugin to check a MS SQL server ? I'm > currently trying to > put something together, which uses freetds 0.60. But since > I'm no expert in > either makefiles, the configure script etc, I'd really > appreciate if someone > could take care of that part once I have something, that seems to be > working - maybe by including it in the plugins package once > the code seems > stable enough. > > Regards, > > /Brian Ipsen > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: check_mssql Type: application/octet-stream Size: 3562 bytes Desc: not available URL: From noreply at sourceforge.net Wed Nov 27 19:51:02 2002 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Wed Nov 27 19:51:02 2002 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-644783 ] check_procs: NULL in status on Solaris Message-ID: Patches item #644783, was opened at 2002-11-27 15:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=644783&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fabian Pehla (fpehla) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs: NULL in status on Solaris Initial Comment: Hello, after switching to asprintf, check_procs prints (NULL) in status lines on Solaris. Please find enclosed an appropriate patch to fix that. Best regards, Fabian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=644783&group_id=29880 From sghosh at sghosh.org Wed Nov 27 19:55:01 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Nov 27 19:55:01 2002 Subject: [Nagiosplug-devel] beta2 check_mysql failure In-Reply-To: <20021127174518.E9254@avarice.corp.cloud9.co.uk> Message-ID: thanks -sg On Wed, 27 Nov 2002, James Fidell wrote: > check_mysql from 1.3.0 beta2 dumps for core me in process_arguments. > I believe the following is a correct patch: > > --- check_mysql.c.orig Wed Nov 27 17:41:56 2002 > +++ check_mysql.c Wed Nov 27 17:41:59 2002 > @@ -207,7 +207,7 @@ > if (strlen(db) == 0 && argc > c) > db = argv[c++]; > > - if (is_intnonneg (argv[c])) > + if ( argc > c && is_intnonneg (argv[c])) > db_port = atoi (argv[c++]); > > return validate_arguments (); > > > James > > -- From sghosh at sghosh.org Wed Nov 27 19:57:04 2002 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Nov 27 19:57:04 2002 Subject: [Nagiosplug-devel] check_dns problem In-Reply-To: <20021127162151.C4208@avarice.corp.cloud9.co.uk> Message-ID: Plans are to switch from nslookup to host. I doubt whether we will actually do our own dns check (raw packets) anytime soon, unless there is some coding effort. -sg On Wed, 27 Nov 2002, James Fidell wrote: > When started, nslookup tries to look up the hostname of the server > being used for queries. In the general case this is fine. However, > if it is being used to do a lookup on a server which doesn't allow > recursive queries and isn't authoritative for its own reverse address > then the lookup times out and check_dns reports an error when there > may be none. > > I've hacked check_dns.c to use "host" for the moment (since nslookup > is deprecated anyway). Is there an alternative work-around for this > problem (I guess check_dns should really do it's own DNS check rather > than relying on any external application). > > James > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > --